Реферальна гейміфікація в мобільному додатку: бонуси за запрошення

Реферальна система в застосунку: де ламається механіка запрошень

Реферальна система приводить користувачів рівно до того моменту, поки ланцюжок «запрошення друга → встановлення із запрошення → нагорода» проходить без розривів. На практиці розриви є майже завжди, і кожен тихо з'їдає частку запрошень, яку потім ніхто не рахує. Розбираємо, де саме ламається механіка.

Перший збій — втрата зв'язку між переходом і встановленням. Людина відкриває посилання, потрапляє в магазин застосунків, ставить застосунок і запускає його вже без контексту запрошення: ознака не дожила до першого старту, встановлення не прив'язалося до того, хто запросив.

Обидва учасники залишаються без нагороди, а той, хто запрошує, робить висновок, що механіка не працює, і більше не кличе.

Другий збій — нарахування. Якщо нагорода видається не за встановлення, а за цільову дію всередині застосунку, її легко не дочекатися: умову сформульовано розмито, подія не долетіла, статус запрошення ніде подивитися.

Людина, яка покликала друга, не бачить, на якому кроці той зупинився, і гасне раніше, ніж ланцюжок доходить до винагороди.

Третій збій — накрутка бонусів. Самозапрошення із запасного акаунта, кілька пристроїв на одну людину, автоматизовані схеми перетворюють винагороду на витік, а бюджет — на подарунок тим, хто не збирався користуватися застосунком.

Закривається це не постфактум, а правилами: обмеження на ланцюжок нарахувань, звірка пристрою та профілю, пороги й затримка видачі.

Далі — про те, де ставити перевірку, щоб відсікти накрутку й не втратити чесні запрошення.

Реферальна система: варіанти механіки нарахування бонусів

Вибір механіки починається з трьох питань: хто отримує бонус, за яку дію і в який момент він спрацьовує. Одностороння й двостороння нагорода по-різному впливають на конверсію запрошеного, а поріг спрацьовування визначає, скільки накрутки переживе система без ручних розборів.

Поріг спрацьовування — головний важіль проти саморефералів: нарахування за фактом першого платежу або завершеного замовлення замість реєстрації відсікає порожні акаунти.

Плата за це — подовжений шлях до виплати, тому в інтерфейсі потрібен явний статус «бонус в очікуванні» із зазначенням, якої дії не вистачає.

Схеми комбінуються: рівні нагороди поверх порогу спрацьовування дають і мотивацію активним, і захист від порожніх реєстрацій.

Під час вибору ми рахуємо частку пар, що доходять до порогу, і кількість нарахувань на одного того, хто запрошує — за цими двома величинами відразу видно, де механіка впирається в обмеження, а де її можна підсилювати.

Як ми впроваджуємо механіку запрошень: етапи робіт

Роботи йдуть ітераціями, а не одним спринтом: спочатку фіксуємо, де саме в поточній воронці губляться запрошені, потім збираємо механіку й перевіряємо її на реальних сценаріях, а не на демо-стенді.

Кожен етап закінчується артефактом, який можна подивитися й оспорити, — так упровадження механіки не перетворюється на чорну скриньку.

1. Аудит воронки. Знімаємо поточні події: частка користувачів, які дійшли до надсилання запрошення, до встановлення за посиланням, до першої цільової дії. Знаходимо обриви й вирішуємо, де механіка дасть ефект, а де проблема в іншому місці.
2. Схема нарахувань. Формалізуємо модель: за яку дію нараховуємо, кому, із якою затримкою, що вважаємо кваліфікованим кроком, як рахуємо ліміти й відсікаємо самозапрошення та накрутку.
3. Проєктування зв'язків і журналу. Визначаємо, як пов'язуються той, хто запрошує, і запрошений, як операція захищається від повторного нарахування, як скасовується бонус у разі відкату замовлення, — усюди залишається незмінна історія нарахувань.
4. Реалізація в застосунку. Перехід за посиланням усередину застосунку, екрани прогресу й статусу нагороди, повідомлення, коректна робота без мережі: дія не губиться, а йде в чергу до відновлення зв'язку.
5. Перевірка сценаріїв. Проганяємо повторне встановлення, вхід з іншого пристрою, зміну акаунта, перший запуск без мережі, скасування платежу. Окремо — спроби обійти ліміти.
6. Спостережуваність і передача. Налаштовуємо покрокові метрики воронки й оповіщення про розбіжність у нарахуваннях, віддаємо документацію за схемою, доступи й інструкцію з ручних коригувань. Далі ваша команда веде механіку сама.

Що передаємо вам після запуску: артефакти й регламенти

Реферальна механіка живе довше за реліз: змінюються ставки, з'являються спроби накрутки, підтримці потрібно закривати спірні нарахування.

Щоб кожна така правка не перетворювалася на терміновий випуск нової збірки, передаємо комплект артефактів — за ним зміни вносить ваша команда без нашої участі.

• Регламент нарахувань. Ставки й ліміти для того, хто запрошує, і запрошеного, умови перерахунку в разі повернення замовлення, пороги спрацьовування антифроду та сценарії ручного коригування балансу.
• Схема даних. Зв'язки «користувач — запрошення — подія — нарахування»: ключі, індекси, місця зберігання статусів. За нею видно, звідки взявся баланс і де шукати розбіжність.
• Матриця доступів. Ролі в панелі керування: підтримка бачить історію, але не нараховує; маркетинг править умови акції; інженер — конфігурацію. Список видається з описом і порядком зняття прав у разі звільнення співробітника.
• Документація. Опис подій, які запускають бонус, формат обміну із серверною частиною та поведінка системи, коли зовнішній сервіс недоступний.
• Порядок правок. Що змінюється налаштуванням без оновлення застосунку, а що потребує випуску збірки — з урахуванням правил майданчиків розміщення (App Store, Google Play).
• Журнал і відкат. Логи нарахувань з ідентифікатором операції, інструкція зі скасування помилкового бонусу й відновлення балансу без ручної правки даних.

Приймання — не показ екранів, а розбір із вашими інженерами: вони самі змінюють ставку й відкочують тестове нарахування. Після цього супровід можна вести своїми силами або залишити нам — це вирішується за фактом, а не за домовленістю заздалегідь.

Кейс: зростання запрошень і утримання за етапами воронки

У застосунку мережі фітнес-клубів «Атлет» реферальна механіка жила окремим екраном: користувач надсилав посилання, запрошений реєструвався, обидва отримували знижку на наступне продовження.

Через три місяці частка тих, хто запрошував, трималася на 8%, а конверсія запрошеного в перше відвідування — на 12%: реєструвалися «на майбутнє» й до залу не доходили.

Переробили не розмір бонусу, а шлях: запрошення вбудували в момент закриття тижневої мети, а нагороду прив'язали до спільної активності пари, а не до реєстрації.

Де додалося

Частка користувачів, які надіслали хоча б одне запрошення за місяць, зросла з 8% до 23%, конверсія запрошеного в цільову дію — з 12% до 31%.

Утримання на 30-й день у запрошених виявилося вищим за середнє по застосунку: 27% проти 18% по базі — людина приходить у парі з тим, хто вже тримає ритм тренувань.

Повернення «заснулих» підтягнулося з 6% до 11%: нагадування про незакритий спільний прогрес працювало помітно краще за одиночне повідомлення.

Де гіпотеза не вистрелила

Нагорода за сам факт надсилання посилання дала сплеск запрошень удвічі, але конверсію в перше заняття завалила — приходили «за знижкою», а не тренуватися.

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

Окремо вимкнули показ реферального блоку новим користувачам у першу добу — він відволікав від проходження стартового сценарію й знижував частку тих, хто дійшов до розкладу.

Чим відрізняється бонус за встановлення від бонусу за покупку?

Різниця між цими схемами — не в розмірі винагороди, а в моменті нарахування. Бонус за встановлення нараховується на першому запуску застосунку: пристрій свіжий, акаунт не значиться в базі вже зарахованих.

Бонус за покупку чекає на підтверджену платіжну подію, і до цього моменту в балансі того, хто запросив, не відображається.

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

Покупка потребує реального платежу — підробка коштує дорожче за сам бонус, тому накрутка втрачає сенс.

Відкладене нарахування — те, що найчастіше обирають на практиці.

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

Технічно це означає, що кожне нарахування має стан і ключ, за яким повторний запуск перевірки не нарахує двічі, а скасування платежу відкочує бонус і перераховує рівень того, хто запросив.

Вибір між схемами — це вибір між шириною воронки й обсягом перевірки. Бонус за встановлення дає більше запрошень і потребує фільтрів від накрутки; бонус за покупку відсікає сміття сам, але приводить менше людей.

Відкладене нарахування дозволяє тримати обидва ефекти, якщо стани й відкати описані в моделі даних до запуску.

Часті питання перед запуском запрошень

До моменту оцінки зазвичай спливають одні й ті самі сумніви: що дозволяють магазини застосунків, як відрізнити живе запрошення від накрутки і що буде з механікою після наступного релізу. Нижче — короткі відповіді, щоб на старті не залишилося неясних місць.

Чи не порушує це правила магазинів застосунків?

Механіку проєктуємо в межах правил: винагорода йде за дії всередині застосунку, умови описані відкрито, виплати не обходять внутрішні покупки. Формулювання екранів і оферти звіряємо до публікації — це знімає основну причину відхилення збірки на перевірці.

Що якщо запрошений видалить і встановить застосунок заново?

Повторне встановлення не вважається новим запрошенням: зв'язка «пристрій — акаунт» зберігається на стороні сервісу, другий бонус не нарахується. Якщо посилання отримали, а застосунок поставили пізніше, запрошення зберігається й спрацьовує під час першої авторизації.

Чи доведеться випускати оновлення заради зміни умов?

Розміри бонусів, ліміти й правила нарахування винесені в налаштування сервісу — їх змінюють без випуску нової версії в магазині. Оновлення застосунку потрібне лише для нових екранів або зміненої логіки інтерфейсу.

Обговоримо задачу й повернемося з планом впровадження

Щоб оцінка обсягу була предметною, а план упровадження — реалістичним, до розмови достатньо підготувати кілька ввідних. Формальне технічне завдання не потрібне: вистачить того, що вже є під рукою в продукту й підтримки.

• Які дії користувача вважаються запрошенням: встановлення за посиланням, вхід за кодом, перша покупка — від цього залежить логіка нарахування.
• Де зараз обліковуються запрошення: власна база, облікова система чи таблиці, і чи можна вивантажити звідти історію.
• Як виглядає нагорода — бали, знижка, безкоштовний період, внутрішня валюта — і хто її нараховує.
• Правила захисту від зловживань: ліміт запрошень з одного пристрою, перевірка одноразових номерів, ручний розбір спірних нарахувань.
• Що вже фіксує аналітика: чи можна пов'язати факт запрошення з подальшою активністю запрошеного.
• Обмеження щодо релізів: коли планується оновлення застосунку і які перевірки магазинів потрібно пройти.
• Хто з вашого боку ухвалює рішення за правилами нарахування й розбирає спірні випадки.

Після розмови ми повернемося з оцінкою обсягу робіт, планом упровадження за етапами й пропозицією щодо пілоту: запускаємо механіку на обмеженій групі, звіряємо метрики з очікуваннями й лише потім розкочуємо на всіх.

Супровід після релізу включає контроль нарахувань, відсікання зловживань і доопрацювання правил за фактичними даними.

Опишіть задачу — повернемося з оцінкою та планом.