Как работают конверсии в гембле

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

Классическая модель: один лид на всю воронку

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

• Регистрация. Создаётся лид со статусом ожидание / новый.
• Получение первого депозита. Лид переводится в статус холд.
• Подтверждение депозита. Лид переводится в статус апрув.
• Блокировка пользователя или отмена. Лид переводится в статус треш / отмена.

Преимущества:

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

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

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

Если используется полноценная платформа AlterCPA Pro или Cloud, а не трекер, ситуация частично решается. Платформа умеет показывать несколько дат: получения лида, отправки в CRM, апрува или отмены, выкупа или возврата. Даже кап там можно считать по выбранной метке времени — поступлению лида, отправке рекламодателю, апруву или закрытию сделки.
Однако в обычном трекере, будь то AlterCPA Red, One или Lite, дата у лида одна: дата поступления, и при смене статуса она не меняется. Поэтому для вертикалей вроде гемблинга, где между созданием лида и его апрувом могут пройти недели, применяется другой подход.

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

Что ж делать с гемблой? Переходить на модель с целями! Идея простая: под каждый тип конверсии — отдельная цепочка. Простейший пример — регистрация и депозит.
Когда пользователь регистрируется:

• Создаётся лид.
• Цель лида — reg, регистрация.
• Статус — ожидание или апрув.

Когда тот же пользователь вносит FTD:

• Создаётся новый лид.
• У него новый внешний идентификатор.
• Цель лида — dep, депозит.
• Дата лида — дата фактического депозита.

Весь фокус — в том самом новом внешнем идентификаторе. В постбеке это параметр uid, например uid=depXXX с ID платежа. Без уникального uid депозит по тому же клику не создаст новый лид, а просто обновит лид регистрации — и здравствуй, классическая модель со смещёнными балансами.
Преимущества такого подхода:

• Точнее считаются конверсии. Каждая падает в свою дату: reg — в день регистрации, dep — в день депозита, и прошлые месяцы больше не дорастают задним числом.
• Корректно считаются капы. Депозиты идут в зачёт по своей реальной дате, а кап в пути умеет «кушать» только нужную цель: если он выдан по депозитам, считаются только они, регистрации игнорируются.
• Можно точно видеть дневной приход депозитов. Дата лида совпадает с датой платежа, так что статистика по дням показывает, сколько депозитов пришло именно в этот день.
• Статусы никуда не деваются. И регистрация, и депозит приходят лидом в статусе ожидание и после подтверждения переводятся в апрув, а депозитам доступен и привычный холд.
• Деньги видны раздельно: для тех, что висят в холде, и для уже подтверждённых есть свои колонки — как их включить, покажу в практической части.

Ревшара. При работе по RS используется именно этот, второй подход: регистрация — отдельный лид, и каждый платёж — тоже отдельный лид со своей датой, суммой и статусом (в uid тут удобно передавать ID платежа). Так перед глазами вся история клиента — все его платежи и точная динамика дохода.
Для учёта сумм пригодятся два параметра постбека — оба накопительные:

• addcost — прибавляет сумму депозита к уже существующему лиду: каждый новый деп плюсуется к накопленному, тогда как обычный cost просто перезаписал бы сумму. Лайфхак: на каждый платёж плюсовать сумму депозита к тому первому лиду с целью reg и держать в нём полную сумму по игроку.
• addprice — так же прибавляет доход, то есть выплату по лиду. Пригодится на ревшаре, где выплата с одного и того же клиента копится постепенно, а не приходит одной суммой.

Группировка данных по клиенту. Когда на одного игрока приходится несколько лидов — регистрация, депозиты и так далее — данные удобно группировать по ID клиента (Customer ID), который передаёт партнёрка. Для него в трекере есть отдельная метка: ID игрока приходит в постбеке параметром customer. Сгруппируете статистику по клику — получите огромную таблицу на тысячи кликов, где данные есть лишь в небольшой части строк. А по ID клиента каждая строка — конкретный игрок: его регистрация, все депозиты и вся статистика по нему. Полная картина взаимодействия пользователя с системой — как на ладони.
Короче говоря, модель с целями уже сама по себе заметно улучшает точность вашей собственной статистики. А если рекламодатель ещё и отдаёт суммы платежей, на своей стороне можно следить за качеством трафика и вынимать кучу полезных данных для апдейта связки — и RS будет считаться по-божески.

Настраиваем на практике

Воодушевились разными методами учёта конверсий? Теперь пора сделать всё собственными лапками в трекере или платформе.

Сперва лайт-левел

Заходим в раздел «Статистика» и смотрим на панельку навигации. Есть там кнопочка с циркумпунктом. Гуглим, что такое циркумпункт, восторгаемся новым знаниям, и жмём на неё — она там самая последняя. Перед нами откроются настройки целей.
Обычно там уже есть регистрация с кодом reg и депозит с кодом dep — их достаточно просто включить галочками. Код цели — это та штука, которую трекер будет ждать от вас в постбеке в поле goal, а название указывайте удобное вам, оно для красоты. Сохраняем, идём дальше.
Ищем в панельке кнопочку с двумя шестерёнками. Что такое шестерёнки, гуглить не надо? Откроется настройка колонок. Там будет страшно, я вас предупредил.

• Убираем все галочки от CR и до CPC, они вам не пригодятся.
• Ставим галочки «CR» и «Всего лидов» для цели «Регистрация».
• Для цели «Депозит» ставим: EPC, EPL, апрув среди всех, всего, холд, апрув, а из денежных — общий заработок, холд, оплачено.
• Если считаете не только отчисления, но и суммы депов через cost — добавляем галочки «Общий чек» и «Средний чек».

Сохраняем — и получаем новую красивую статистику. То же самое повторяем в разделе «Аналитика», только цели там включать уже не нужно: они у вас теперь и так активны. А если вдруг пяти целей окажется мало (в Lite, напомню, потолка нет), пишите в личку — расскажу про секретную константу XTRACK_GOALS.

Переходим на уровень профи — настройки платформы

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

• Заводим в платформе офферы с целями, глубоко скурив этот мануал. При создании оффера берите шаблон «Внешний» или «RevShare» — цели он добавит сам.
• Отправляемся в «Управление — Настройки — Справочники — Блоки статистики по целям» — там и заведём группы целей.
• Добавляем цель «Регистрация» и лезем в правку. Тут указываем английское название Registration и цель reg — точно так же цель должна называться и в офферах. Видимость — у всех, галочки — количество и конверсия.
• Добавляем цель «Депозит» и снова в правку. Указываем название на английском и цель — dep. Если в офферах та же цель называется иначе, эти названия — в «Псевдонимы», к примеру deposit, ftd. Галочек тут пригодится уже больше: количество в статусах «Общие», «Ожидание», «Холд», «Апрув» и «Отмена» или «Треш». Из показателей — EPC и Апрув. Финансы — все три: холд, выплата и общий.
• Переходим в «Управление — Настройки — Расширенные» и в блоке «Колонки таблицы статистики» перекидываем показатели, количества и суммы по лидам из «Включено у всех» в «Доступно всем, по умолчанию скрыто».

Вуаля — у вас красивая статистика с разбивкой по целям даже на платформе!
Выражаю скромную надежду, что всё это было понятно. А если нет — не беда. Велкам в чатик, там всё обкумекаем и облялякаем: t.me/altercpatalk