Как создать веб‑приложение для учёта рефералов и адвокации

Что такое адвокация клиентов и рефералы: цели и сценарии

Адвокация клиентов (customer advocacy) — это ситуация, когда довольные пользователи добровольно помогают продукту: рекомендуют его знакомым, делятся опытом, оставляют отзывы, участвуют в кейсах или выступают на мероприятиях.

Рефералы — более узкий и формализованный слой адвокации: приглашения по ссылке/коду, где можно однозначно связать «кто пригласил» и «какой результат получился».

Какие задачи решает трекинг

Без системы учёта рекомендации быстро превращаются в разрозненные «истории»: кто-то написал в поддержку, кто-то привёл друга, кто-то оставил отзыв — и непонятно, что считать, кому и когда начислять бонус, а главное — что реально сработало.

Трекинг закрывает четыре практичные задачи:

• фиксирует события адвокации и реферальные действия в одном месте;
• честно связывает действие и результат (регистрация, покупка, продление);
• упрощает начисления и исключения (споры, отмены, возвраты);
• даёт прозрачную аналитику для решений, а не «ощущений».

Типичные сценарии

Самые частые кейсы, которые стоит поддержать в продукте:

• «Пригласил друга»: пользователь делится ссылкой/кодом, приглашённый регистрируется и выполняет условие (покупка, первая активность, достижение порога).
• «Оставил отзыв»: публикация на площадке с подтверждением (ссылка, скрин, модерация), иногда — только для пользователей с опытом использования.
• «Упомянул продукт»: пост/комментарий/выступление со ссылкой; часто требует ручной проверки, чтобы избежать накруток.

Кому нужен инструмент внутри компании

• Маркетингу — понимать, какие механики приводят качественных пользователей и где «проседает» воронка.
• Продажам и партнёрствам — видеть источники лидов, учитывать вклад амбассадоров, согласовывать условия.
• Поддержке — быстро отвечать на вопросы про начисления, статусы и спорные случаи.

Какие результаты можно измерять

Обычно измеряют: количество приглашений и активаций, конверсии по шагам (клик → регистрация → целевое действие), долю отмен/возвратов, стоимость бонусов, время до конверсии, качество привлечённых пользователей (повторные покупки/удержание), а также вклад каналов и отдельных адвокатов — без обещаний «роста в X раз».

Требования: события, конверсии и правила начислений

Прежде чем проектировать экраны и подключать аналитику, зафиксируйте «что именно мы считаем успехом». Иначе реферальная программа быстро превратится в поток спорных кейсов и ручных правок.

Что считать «рекомендацией»

Рекомендация — это не «кто-то рассказал другу», а проверяемый факт. Обычно это один из вариантов:

• переход по реферальной ссылке или использование промокода;
• приглашение, отправленное из личного кабинета (email/телефон/мессенджер);
• импорт приглашённых из CRM (например, менеджер указал источник «по рекомендации»).

Сразу решите, что делать с «серой зоной»: пользователь пришёл сам, но позже ввёл код; пришёл по ссылке, но зарегистрировался с другого устройства; промокод передали в общий чат. Для таких случаев важны правила приоритета и окно атрибуции (например, 7 или 30 дней).

«Успешная конверсия»: один термин — несколько уровней

Конверсия должна быть измеримой и привязанной к бизнес-ценности. Часто используют ступени:

• регистрация;
• запись на демо;
• первая покупка/оплата;
• повторная покупка (как признак качества привлечения).

Хорошая практика — разделить триггер начисления и подтверждение. Например, начисляем после первой оплаты, но подтверждаем после истечения периода возврата.

Список событий, которые нужно собирать

Минимальный набор событий для учёта рекомендаций:

• создание приглашения (выдача ссылки/кода);
• клик/переход по ссылке;
• регистрация приглашённого;
• ключевые бизнес-события: демо, первая покупка, повторная покупка;
• отмена/возврат/чарджбек;
• ручная корректировка (кем и почему).

Каждому событию нужен таймстемп, связка «пригласивший → приглашённый», а также статус обработки (ожидает/подтверждено/отменено).

Правила начисления бонусов и ограничения

Опишите правила так, чтобы их можно было реализовать без исключений «по договорённости»:

• одноразовая награда за приглашённого или несколько уровней;
• лимит: 1 награда на клиента (за одного приглашённого) или лимиты в месяц;
• запрет саморефералов и дубликатов (один человек — один аккаунт);
• условия доступа к награде (например, только после оплаты и без возврата 14 дней).

SLA по спорным случаям и отменам

Заранее задайте сроки и ответственность: сколько дней рассматриваем спор, кто принимает решение, какие доказательства принимаем.

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

Роли и пользовательские потоки в приложении

Чтобы реферальная программа работала предсказуемо, начните не с «красивых экранов», а с ролей и понятных действий для каждой роли. Это сразу задаёт структуру интерфейса, права доступа и список событий, которые нужно фиксировать.

Роли и что им нужно

Админ настраивает программу: правила начислений, статусы заявок, лимиты, антифрод‑порог, шаблоны сообщений. Ему важно видеть целостную картину и иметь право вручную исправлять спорные кейсы.

Менеджер (поддержка/аккаунт) работает с конкретными участниками: подтверждает спорные конверсии, отвечает на вопросы, обрабатывает заявки на выплаты. Ему нужен быстрый поиск и понятные причины отказов.

Амбассадор/клиент приглашает людей и отслеживает прогресс: сколько приглашений, какие из них засчитаны, какие награды доступны, что нужно сделать дальше.

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

Основные экраны

В MVP достаточно трёх зон:

• Кабинет участника: личная ссылка/код, статус приглашений, баланс/награды, история начислений.
• Панель администратора: настройки программы, управление ролями, ручные решения.
• Журнал событий: хронология кликов, регистраций, покупок, начислений и отмен (полезно и для поддержки).

MVP vs позже

Обязательно в MVP: роли и права, кабинет участника, базовая админка, журнал событий, простой статусный процесс «приглашение → конверсия → награда».

Можно отложить: многоуровневые рефералы, сложные сегменты, A/B правила, витрина призов, автоматическая модерация, расширенные отчёты (оставьте /blog/analytics как следующий шаг).

Путь пользователя: от ссылки до награды

Типовой поток выглядит так: амбассадор копирует реферальную ссылку → приглашённый переходит по ней → система создаёт «клик» и привязку к амбассадору → приглашённый регистрируется и выполняет целевое действие → конверсия получает статус (например, «на проверке», затем «подтверждена») → начисляется награда → участник видит обновление в кабинете и при необходимости запрашивает выплату.

Модель данных: что хранить, чтобы всё сходилось

Правильная модель данных — это способ избежать споров «кто кого пригласил», пересчётов бонусов задним числом и хаоса в поддержке. Ниже — минимальный набор сущностей, который позволяет уверенно считать конверсии, награды и выплаты.

Минимальные сущности

Пользователь (User) — тот, кто рекомендует, и тот, кого пригласили.

Реферал (Referral) — связь между «пригласившим» и «приглашённым» плюс контекст. Важно хранить не только referrer_user_id и referred_user_id, но и дату создания, канал, первичный источник и версию правил.

Событие (Event) — факты, на которых строятся начисления: регистрация, первая покупка, оплата подписки, возврат и т. п. События лучше делать неизменяемыми (append-only) с полями: type, occurred_at, user_id, external_id, amount/currency (если нужно).

Награда (Reward) — обещанная или начисленная выгода (бонус, скидка, деньги). Храните reward_type, value, status, ссылки на реферала/событие и основание начисления (правило).

Выплата (Payout) — «денежная» часть: запрос, подтверждение, платёж, отмена. Связывайте выплату с набором наград, чтобы прозрачно объяснять сумму.

Состояния реферала

Заложите конечный автомат:

• создан — приглашение зафиксировано;
• в ожидании — ждём квалифицирующее событие (например, оплату);
• подтверждён — условия выполнены, можно начислять;
• отклонён — не прошло проверку/нарушены правила.

Статус должен меняться только через бизнес-логику, а не «ручным апдейтом в базе».

Хранение источника

Чтобы честно атрибутировать, храните source_type и source_value:

• ссылка (referral link);
• промокод;
• ручное назначение (когда поддержка связывает пользователей).

Дополнительно полезны campaign_id, landing_url, utm_*, а также assigned_by (кто назначил вручную) и reason.

Аудит-лог изменений

Сделайте AuditLog для спорных кейсов и поддержки: кто и когда изменил статус, источник, сумму награды. Минимум: entity_type, entity_id, action, before, after, actor_user_id/actor_service, created_at. Это экономит часы разбирательств и помогает соблюдать внутренние регламенты.

Реферальные ссылки и промокоды: как выдавать и учитывать

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

Формат реферальной ссылки: короткий токен vs. читаемый код

У ссылки две задачи: не «пугать» пользователя и быть однозначно сопоставимой с пригласившим.

Короткий токен (например, /r/8f3Kp2) сложнее подбирать и проще сделать уникальным, но его нельзя продиктовать голосом.

Читаемый код (например, /r/IVAN-42) легче запомнить и переписать, но требуется защита от коллизий и проверка на нежелательные слова.

На практике часто делают гибрид: отображаемый пользователю код + внутренний неизменяемый ID.

Промокоды как альтернатива и когда они удобнее

Промокод полезен, когда:

• приглашение распространяют через печатные материалы, презентации, мероприятия;
• регистрация идёт через менеджера или форму без перехода по ссылке;
• нужно запускать «кампании» (например, код для партнёра/сообщества) и отделять их от личных рекомендаций.

Важно различать персональные промокоды (привязаны к конкретному участнику) и кампанийные (один код на источник). Правила начисления для них часто разные.

Переадресация на посадочную страницу и сбор параметров

Реферальная ссылка должна вести на промежуточный роут (например, /r/:code), который:

1. валидирует код/токен и статус программы;
2. ставит метку атрибуции (cookie/localStorage + запись на сервере);
3. делает 302-редирект на нужную посадочную (/signup, /pricing, /promo/...) с аккуратно сохранёнными параметрами.

Повторные клики и защита от перезаписи атрибуции

Самый частый спор — «кто пригласил»: первый клик или последний. Чтобы не провоцировать злоупотребления, задайте правило заранее (часто — first-touch с окном, например 30 дней).

Практика учёта:

• если метка уже есть и не истекла — не перезаписывать при повторных кликах;
• логировать повторные переходы как события, но не менять referrer_id;
• разрешать перезапись только в явных кейсах: пользователь сам ввёл другой промокод на чек-ауте, либо атрибуция отсутствует/просрочена.

Отслеживание и атрибуция: как честно связать приглашение и результат

Атрибуция — это правила, по которым вы решаете, чьё приглашение «засчиталось» и за что именно выдаётся награда. Если правила расплывчатые, вы получите споры, злоупотребления и недоверие к программе.

Модели атрибуции и окно действия

Чаще всего используют:

• Last click: награда уходит тому, чья ссылка/код были использованы последними перед регистрацией или покупкой. Подходит, если рефералы активно делятся ссылками в момент принятия решения.
• First click: награда закрепляется за первым источником. Уместно, если вы цените первичное знакомство и длинный цикл сделки.

Почти всегда нужна фиксация на окно — 30/60/90 дней. Это означает: если человек перешёл по приглашению сегодня, то любая целевая конверсия в ближайшие N дней может быть связана с пригласившим (по выбранной модели). Окно стоит хранить как часть правил программы, чтобы можно было менять его в новых версиях без пересчёта исторических данных.

Cookie/LocalStorage и серверная фиксация токена

На практике лучше делать два уровня:

1. Клиентский: сохранить ref_token в cookie или LocalStorage при переходе по ссылке.
2. Серверный: при регистрации/первом логине передать токен на сервер и закрепить его за пользователем в базе. После этого дальнейшие события (покупки, продления) уже не зависят от браузера.

Регистрация и покупка на разных устройствах

Частый кейс: кликнули со смартфона, купили на ноутбуке.

Рабочие варианты:

• Промокод как запасной канал атрибуции (вводится при покупке).
• Диплинк/магическая ссылка на вход: пользователь подтверждает email/телефон, и вы связываете покупку с ранее сохранённым токеном.
• Зачёт по аккаунту: если атрибуция закрепилась при регистрации, покупка на любом устройстве «догонит» реферала.

Отмены, возвраты и «порог» подтверждения награды

Награду лучше выдавать не сразу, а после подтверждения: например, прошло 14 дней без возврата или оплата не в статусе chargeback. Введите статусы: «начислено», «на холде», «подтверждено», «отменено». При возврате делайте сторно и сохраняйте причину — это пригодится и для поддержки, и для антифрода.

Антифрод и модерация: защита от злоупотреблений

Реферальная программа быстро начинает «притягивать» не только новых клиентов, но и попытки получить бонусы обходными путями. Если антифрод не продуман, вы будете либо переплачивать, либо слишком жёстко «резать» честных участников.

Хорошая стратегия — сочетать автоматические правила, лимиты и ручную модерацию для спорных кейсов.

Базовые правила антифрода

Самые частые сценарии злоупотреблений стоит закрывать простыми, понятными правилами:

• Саморефералы: один и тот же человек регистрируется по собственной ссылке. Сигналы: совпадение устройства, IP/подсети, cookie/advertising id, платёжных реквизитов, адреса доставки.
• Массовые регистрации: «фермы» аккаунтов, созданные за короткий период. Сигналы: всплеск регистраций с одного диапазона IP, одинаковые паттерны email/телефонов, нулевая активность, одинаковые user-agent.
• Подозрительные домены (если используете email): одноразовые почтовые сервисы, домены без MX-записей, странные TLD. Лучше не блокировать всех подряд, а переводить в «на проверке».

Лимиты, которые спасают бюджет

Лимиты должны быть прозрачными и измеримыми:

• по участнику: например, не более N подтверждённых приглашений в месяц;
• по методу идентификации (если применимо): по телефону, карте/платёжному профилю, устройству;
• по периоду: задержка начисления до выполнения условия (оплата, завершение пробного периода, отсутствие возврата).

Важно: лимиты — это не наказание, а защита. Их лучше хранить как настраиваемые параметры, чтобы быстро менять без релиза.

Ручная модерация и статусы

Добавьте промежуточные статусы для событий/начислений:

• черновик/зафиксировано (клик или регистрация есть, но условия не выполнены);
• на проверке (сработали правила риска);
• подтверждено (разрешено начислять);
• отклонено (с указанием причины и кода правила).

Модератору нужны: история действий, сигналы риска, связки (пригласивший → приглашённый), и кнопки «подтвердить/отклонить/запросить данные».

Как сообщать причину отказа простым языком

Сообщение участнику должно быть коротким и без технических деталей:

• «Начисление не выполнено: приглашённый аккаунт не прошёл проверку условий программы».
• «Бонус не начислен, потому что приглашение связано с вашим же профилем (самоприглашение)».
• «Начисление на проверке. Обычно это занимает до 24 часов».

Добавьте ссылку на правила (/referrals/rules) и канал поддержки (/support), а внутри системы храните детальную причину (rule_id, сигналы), чтобы служба поддержки отвечала последовательно.

Награды и выплаты: логика, статусы и учёт

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

Типы наград и как их учитывать

Чаще всего встречаются:

• Скидки (одноразовые или подписочные): удобно хранить как купон/право на скидку с датой окончания.
• Бонусные баллы: лучше вести как внутреннюю валюту с курсом и ограничениями списания.
• Подарки: фиксируйте себестоимость, доставку и статус выдачи.
• Денежные выплаты: требуют максимальной прозрачности по документам и реквизитам.

Для каждого типа награды определите, можно ли её отменить при возврате, и как вы пересчитываете бонус при частичной оплате.

Кошелёк (баланс) и история операций

У пользователя должен быть баланс и лента операций, как в банке: начисление, удержание, списание, корректировка. Каждая операция — отдельная запись с суммой, валютой/типом, основанием (событие, заказ, пользователь), а также «снимком» правила (чтобы при изменении условий старые начисления оставались объяснимыми).

Пороги, расписание и статусы выплат

Для денег и крупных бонусов задают порог выплаты (например, от 1 000 ₽) и расписание (раз в неделю/месяц). Типичный набор статусов: ожидает подтверждения → доступно к выплате → в обработке → выплачено или отклонено/отменено.

Выгрузки для бухгалтерии и ручные корректировки

Сделайте выгрузки (CSV/XLSX) по периодам: получатель, сумма, назначение, статус, реквизиты, дата.

Обязательно поддержите ручные корректировки (доначислить/снять) с причиной и автором действия — это инструмент для разруливания спорных кейсов без «правок в базе».

Аналитика и отчёты: что смотреть каждый день и раз в месяц

Аналитика в реферальной программе нужна не только «для красивых графиков». Она помогает быстро замечать перекосы (трафик есть — наград нет, или наоборот) и держать под контролем экономику: сколько стоит привлечение с учётом бонусов и операционных расходов.

Ключевые метрики, которые должны быть на виду

На ежедневном дашборде обычно достаточно 6–10 показателей:

• Приглашения: сколько отправлено/создано ссылок и промокодов, сколько кликов и уникальных посетителей.
• Конверсии: регистрация, подтверждение контактов, первая покупка/активация — по вашей бизнес‑логике.
• Квалифицированные конверсии: сколько событий прошло правила начислений (например, «оплата не менее X», «без возврата 14 дней»).
• Награды: начислено/в ожидании/отклонено, средний размер награды.
• CPA / стоимость награды: сколько в среднем стоит одна квалифицированная конверсия с учётом бонусов (и отдельно — только бонусы).
• Удержание: возвращаемость приглашённых пользователей (например, D7/D30) и доля повторных покупок.

Воронка по шагам: клик → регистрация → квалификация → награда

Стройте воронку строго в том порядке, как пользователь проходит путь. Важно видеть потери между шагами и их причину:

• клик есть, регистрации нет → проблемы с лендингом/оффером/UTM;
• регистрация есть, квалификации нет → слишком жёсткие правила или не тот трафик;
• квалификация есть, наград нет → задержки модерации, фрод‑фильтры, ошибки интеграции с биллингом.

Хорошая практика — показывать рядом время до шага (median time-to-register, time-to-qualify, time-to-reward). Это помогает планировать ожидания партнёров и нагрузку поддержки.

Срезы, без которых отчёты бесполезны

Минимальный набор разрезов: канал, кампания, продукт/тариф, регион, менеджер/аккаунт (если рефералы привязаны к продажам). Так вы поймёте, где программа окупается, а где «съедает» бюджет.

Экспорт и регулярная отчётность

Сделайте экспорт CSV для сырых таблиц (с датами, статусами, суммами, источниками) и шаблоны регулярных отчётов: ежедневный короткий (операционный) и ежемесячный (финансовый и продуктовый).

Планирование можно вынести в раздел /reports, где выбираются период, срезы и получатели рассылки.

Интеграции: CRM, биллинг и коммуникации

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

Что обычно интегрируют

CRM — чтобы подтягивать карточки клиентов, статусы лидов/сделок и связывать реферала с реальным покупателем. Это помогает отвечать на вопросы «кто кого пригласил» и «на каком этапе конверсия». Полезно также выгружать в CRM события реферальной активности (выдана ссылка, приглашённый зарегистрировался, начислена награда).

Биллинг и платёжные системы — чтобы начислять бонусы только за подтверждённые оплаты, подписки, продления и возвраты. Если вы начисляете награду после 14 дней без возврата, именно биллинг даст сигнал, что условие выполнено.

Коммуникации (email/SMS/мессенджеры, пуши) — чтобы отправлять приглашения, напоминания, статусы наград и уведомления о проверке. Лучше, когда сообщения уходят из привычного сервиса рассылок, а реферальное приложение лишь управляет контентом и триггерами.

Обмен данными: вебхуки, API и синхронизации

Практичный подход:

• Webhooks для событий «оплата прошла», «подписка активирована/отменена», «возврат оформлен» — это почти всегда критично для честных начислений.
• API-запросы для точечной проверки статуса (например, при споре по начислению).
• Периодическая синхронизация (cron) как страховка: раз в час/день подтягивать изменения, если вебхук потерялся.

Как избегать дублей: идемпотентность и уникальные идентификаторы

Внешние системы часто присылают одно и то же событие несколько раз. Решение — хранить idempotency key (например, provider_event_id) и отклонять повторную обработку.

Также заранее договоритесь о сквозных идентификаторах: user_id (в вашем приложении), crm_contact_id, billing_customer_id, payment_id. Чем меньше «склеек» по email/телефону, тем меньше ошибок и ручной работы.

Минимум для старта и что добавить позже

Для MVP достаточно: вебхуков из биллинга + базовой синхронизации с CRM + отправки уведомлений через один канал.

Дальше по мере роста добавляйте: двустороннюю запись в CRM, расширенную сегментацию для рассылок, витрину статусов наград для поддержки и экспорт в BI (если стандартных отчётов станет мало).

Приватность и безопасность: что предусмотреть заранее

Реферальное приложение почти всегда работает с персональными данными: e-mail/телефон приглашённого, идентификаторы устройств, платежные статусы, переписка поддержки. Если заложить приватность и безопасность в самом начале, вы избежите «пожарных» переделок после первого инцидента или запроса от пользователя.

Согласия, уведомления и хранение персональных данных

Собирайте только то, что нужно для расчёта начислений и атрибуции. Для каждого типа данных заранее определите основание обработки: согласие, договор, законный интерес.

Убедитесь, что пользователь понимает:

• какие данные вы храните и зачем (например, «для учёта приглашений и начисления бонусов»);
• кому и когда отправляются уведомления (пригласившему и приглашённому);
• как отозвать согласие и что произойдёт с бонусами при отзыве.

Технически полезно разделять «идентификацию» и «аналитику»: хранить контакты отдельно, минимизировать доступ к ним и по возможности использовать хеши/псевдонимы в отчётах.

Разделение доступа по ролям и журнал действий

Внутри админки задайте роли: поддержка (просмотр), менеджер программы (правки правил), финансы (выплаты), администратор (доступ ко всему). Любое изменение начислений, статусов, реквизитов должно попадать в журнал действий: кто, когда, что изменил, старое/новое значение, причина.

Сроки хранения и удаление данных по запросу

Заранее установите сроки хранения (например, 12–36 месяцев после последней активности) и автоматические политики удаления/анонимизации. Поддержите сценарии: «выгрузка данных» и «удаление по запросу» (включая резервные копии — с понятным сроком их ротации).

Безопасность ссылок: срок жизни токенов, защита от подбора

Реферальная ссылка — это токен доступа, а не «просто URL». Используйте длинные случайные значения, храните их в базе в виде хеша, задавайте срок жизни и возможность перевыпуска.

Добавьте защиту от перебора и утечек: rate limit на активации, ограничение по IP/устройству при подозрительных паттернах, привязку токена к кампании/каналу, а для критичных операций — подтверждение через одноразовый код.

Стек, запуск и развитие: от MVP до масштабирования

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

Выбор стека под команду

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

Практичный набор компонентов:

• Backend: любой знакомый фреймворк (например, Node.js/Nest, Python/Django, Ruby on Rails, PHP/Laravel).
• База данных: PostgreSQL (удобно для связей «пригласивший → приглашённый → награда»).
• Очереди/фоновые задачи: для начислений и отправки уведомлений (например, RabbitMQ/SQS/Redis Queue).
• Аналитика событий: можно начать с логов + таблиц, а затем подключить DWH/BI.

Если вам нужно быстро проверить гипотезу и собрать рабочий MVP без тяжёлого цикла разработки, рассмотрите TakProsto.AI — платформу для vibe-coding, ориентированную на российский рынок. В ней можно собрать веб‑приложение для учёта рефералов (кабинет участника, админку, журнал событий, простые интеграции) через чат: с режимом планирования, снапшотами и откатами, деплоем и хостингом, кастомными доменами и экспортом исходников. Типовой стек, с которым это удобно делать, — React на фронтенде и Go + PostgreSQL на бэкенде; для мобильного клиента — Flutter. Есть тарифы free/pro/business/enterprise, а также программы реферальных ссылок и «earn credits» за контент.

План релиза: пилот → обратная связь → расширение

1. Пилот на одном сценарии (например, «приглашение → регистрация → первая покупка»), с ручной модерацией спорных случаев.

2. Сбор обратной связи: где пользователи теряются, какие условия воспринимаются как нечестные, какие отчёты нужны поддержке.

3. Расширение правил: несколько типов наград, ограничения по времени, разные условия для сегментов.

Тестирование, которое экономит деньги

Помимо юнит‑тестов, важнее всего интеграционные сценарии атрибуции: переход по ссылке, повторный визит, смена устройства, конфликт промокода и ссылки, отмена заказа, возвраты. Добавьте «контрольные» тестовые аккаунты и регрессионный набор кейсов для релизов.

Дорожная карта развития

Когда MVP стабилен, логичные шаги:

• Многоуровневые рефералы (2–3 уровня) с чёткими лимитами и прозрачными условиями.
• A/B‑тесты: разные офферы, тексты, сроки действия бонусов.
• Локализация: валюты, языки, налоговые/юридические нюансы, шаблоны коммуникаций под регионы.

Так вы растёте не «вширь», а в сторону управляемости: меньше ручных разборов, больше доверия и прогнозируемая экономика программы.