Реферальная программа для игроков — приведи друга

MAATRIX GAMES

Половина новых игроков на нормальном сервере приходит не с топ-мониторингов и не из рекламы, а по совету друга. Проблема в том, что без учёта это невидимый канал — вы не знаете, кто кого привёл, не можете никого за это отблагодарить и не понимаете, работает ли сарафан вообще. Реферальная программа закрывает это: даёт каждому игроку свою ссылку или код, считает, кто по ней пришёл, и выдаёт награду обеим сторонам. Дальше — как это собрать технически, не изобретая велосипед и не открыв дыру для читеров с альт-аккаунтами.

Как работает механика: коды, ссылки, начисление

Базовая схема одинаковая для любого движка — Minecraft, Rust, FiveM, что угодно с базой данных под капотом:

1. Игрок получает уникальный код (или ссылку вида play.yourserver.com?ref=CODE) — обычно короткий алфавитно-цифровой идентификатор, привязанный к его аккаунту.
2. Новый игрок при первом входе вводит код командой или переходит по ссылке, которая прокидывает параметр в форму заявки/whitelist.
3. Сервер фиксирует связку «пригласивший → приглашённый» в базе.
4. Награда выдаётся не сразу, а по условию — новый игрок должен продержаться на сервере какое-то время (например, набрать 2-3 часа онлайна за 7 дней) или дойти до определённого прогресса. Мгновенная выдача за сам факт регистрации — это то, что чаще всего и накручивают.

Для командных серверов (Minecraft, Rust) код обычно вводится в игровом чате командой вроде /ref CODE, для FiveM и RP-проектов — на этапе анкеты или whitelist-заявки в Discord, где всё равно есть текстовое поле. Ссылку с параметром ?ref= проще всего использовать на форме заявки на сайте, а не в самой игре — так код не потеряется при копировании и его видно в логах формы.

Технически: генерация кодов и хранение в MySQL

Код удобнее не хранить как случайную строку без смысла, а выводить из ID игрока — тогда не нужна отдельная таблица соответствий, и код всегда воспроизводим:

import hashlib

def make_ref_code(player_uuid: str) -> str:
    h = hashlib.sha1(player_uuid.encode()).hexdigest()
    return h[:8].upper()  # например, "A3F9C1B2"

Дальше нужна таблица для связей и статусов — большинство игровых плагинов (EssentialsX, Vault-совместимые экономические плагины на Minecraft, Oxide/uMod на Rust) и так работают с MySQL, так что реферальную таблицу проще добавить рядом:

CREATE TABLE referrals (
    id INT AUTO_INCREMENT PRIMARY KEY,
    referrer_uuid VARCHAR(36) NOT NULL,
    referred_uuid VARCHAR(36) NOT NULL UNIQUE,
    referred_ip_hash CHAR(64) NOT NULL,
    referrer_ip_hash CHAR(64) NOT NULL,
    joined_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    playtime_seconds INT DEFAULT 0,
    status ENUM('pending', 'confirmed', 'rejected') DEFAULT 'pending',
    reward_given_at DATETIME NULL
);

referred_uuid UNIQUE сразу закрывает базовый случай — один аккаунт нельзя засчитать рефералом дважды. IP хранится не в открытом виде, а хешем (SHA-256 от IP + соль) — этого достаточно для сравнения совпадений, и не тянет за собой лишние вопросы к хранению персональных данных (это стоит продумать заранее — детали в статье про хранение личных данных игроков и приватность). Если на сервере уже настроена своя база под плагины, дока по её базовой настройке есть в статье про MySQL для игровых плагинов.

На стороне игры код просто пишет в эту таблицу через плагин: для Minecraft — небольшой Java/Kotlin плагин или Skript-скрипт, вызывающий SQL-запрос при первом входе игрока с параметром; для Rust — Oxide/uMod C#-плагин, обрабатывающий OnPlayerConnected и проверяющий, вводил ли игрок код через чат-команду /ref CODE. Готовых плагинов именно под реферальную механику в публичных маркетах немного и они не всегда поддерживаются — рабочий вариант почти всегда самописный, благо логика простая.

Награды: что давать рефереру и приглашённому

Здесь легко скатиться в pay2win, если награда — игровое преимущество, которое нельзя получить иначе. Рабочие варианты, которые не ломают баланс:

Если награда — это донат-валюта или скидки, тема пересекается с юридическими нюансами доната в целом: как оформлять, что писать в правилах, чтобы не попасть под азартные игры или закон о рекламе, разобрано в статье про юридические аспекты донатов в России. Идея та же самая: реферальная награда — это, по сути, разновидность донат-системы, просто триггер не платёж, а приглашение. Полезно свериться и с общими принципами построения программы лояльности для постоянных игроков — реферальную механику логично встраивать в неё же, а не городить отдельную систему баллов.

Защита от альтов и самореференса

Это главная головная боль реферальных программ — без защиты через день у вас будет топ рефереров, состоящий из одного человека с двадцатью альт-аккаунтами. Меры, которые реально снижают накрутку (ни одна не даёт 100% гарантии, но вместе работают неплохо):

• Хеш IP при регистрации. Если referrer_ip_hash и referred_ip_hash совпадают — заявка не отклоняется автоматически (люди правда играют с друзьями из одной квартиры или общаги), но помечается на ручную проверку.
• Минимальный онлайн перед начислением. Награда выдаётся не за вход, а за подтверждённые часы игры — например, 3 часа за 7 дней. Альт-аккаунт, который зашёл на 2 минуты ради галочки, награду не получит.
• Возраст Steam/Microsoft-аккаунта. Для Steam-игр (Rust, ARK, CS2 и т.д.) можно дёргать Steam Web API и проверять timecreated — свежесозданные аккаунты массово подозрительны, хотя сами по себе поводом для бана не являются.
• Лимит на количество рефералов в сутки/неделю с одного аккаунта. Реальный игрок редко приводит больше 2-3 друзей за раз; резкий скачок — сигнал проверить вручную.
• Задержка выплаты + ручная модерация топа. Простое и рабочее решение: держите очередь status = 'pending' и раз в неделю пробегайте её глазами перед тем как перевести в confirmed.

Массовая проверка и бан подозрительных аккаунтов, если накрутка всё же прошла, делается тем же инструментарием, что и обычная модерация — см. массовый бан игроков: скрипты и инструменты. Стопроцентной защиты от VPN и мульти-аккаунтов не существует ни у одного проекта, и это стоит принять как данность — задача не исключить абьюз полностью, а сделать его дороже награды.

Интеграция с Discord: команды и автоматизация

У большинства сообществ основной трафик приглашений идёт не в игре, а через Discord — ссылку скидывают в личку или постят в чате. Отдельный бот-модуль под это удобнее делать через discord.py (или discord.js, если инфраструктура на Node), с командой, которая генерирует персональную ссылку и пишет её пользователю:

@bot.tree.command(name="ref", description="Получить свою реферальную ссылку")
async def ref(interaction: discord.Interaction):
    code = make_ref_code(str(interaction.user.id))
    link = f"https://play.yourserver.com/join?ref={code}"
    await interaction.response.send_message(
        f"Твоя ссылка: {link}\nНаграда придёт, когда друг наиграет 3 часа за неделю.",
        ephemeral=True
    )

Бот же может выдавать роль «Рефовод» после N подтверждённых приглашений и постить в канал-лог, когда реферал переходит в статус confirmed — это делает прогресс видимым и подстёгивает соревновательность без дополнительной панели. Если бот на сервере уже отвечает за рестарты или статус, логично дописать команду именно в него, а не заводить отдельного — общие практики по такой автоматизации есть в статье про Discord-бота для управления игровым сервером.

Аналитика: как понять, что программа работает

Мало запустить механику — нужно раз в месяц смотреть на цифры и решать, стоит ли она того. Минимальный набор метрик:

• Конверсия приглашения: сколько кодов было использовано / сколько выдано ссылок. Если конверсия ниже 10%, вероятно, награда неинтересна или процесс регистрации по ссылке слишком запутан.
• Retention приглашённых vs обычных новичков: приглашённые друзьями обычно задерживаются дольше — если разницы нет, программа не выполняет свою главную функцию (удержание), а просто раздаёт награды.
• Стоимость привлечения: сумма выданных наград / число подтверждённых рефералов. Сравните с тем, сколько стоит платное привлечение через рекламу на серверлистах — обычно рефералка выходит в разы дешевле.
• Доля отклонённых заявок (status = 'rejected'): резкий рост — сигнал, что кто-то нашёл дыру в защите раньше, чем вы её закрыли.

Общие подходы к тому, какие метрики вообще стоит трекать по игрокам и как их читать, подробнее разобраны в статье про удержание игроков: метрики и аналитика. Реферальную статистику удобно выгружать туда же, где уже считается остальная аналитика сервера, а не держать в отдельной табличке, до которой руки доходят раз в квартал.

Частые вопросы