События подписочных воронок: карта рекуррентной модели

События подписочных воронок решают задачу, которой не под силу один плоский Purchase: рекуррентная воронка производит денежные моменты снова и снова - старт триала, первый платёж, каждый ежемесячный ребилл, - и каждому моменту оптимизатор придаёт разный смысл. Правильная раскладка отличает пиксель, который считает подписчиков, от пикселя, который считает регистрации, пока churn тихо съедает бюджет. Этот гайд картографирует воронку целиком: какой этап становится каким событием, как ребиллы сохраняют идентичность без задвоения, где живут отмены и как далеко способна заглянуть платформенная атрибуция.

Цепочка доставки под этой картой - постбеки, статусы и их разрывы - территория гайда от постбека CPA сети до Conversions API; здесь на сцену выходит сама воронка.

У воронки четыре денежных момента, а не один

Жизненный цикл подписочного оффера глазами байера выглядит так:

Стандартный набор событий Meta нативно покрывает первые два: документированный справочник пикселя перечисляет StartTrial и Subscribe среди стандартных событий (Meta pixel reference), и те же имена едут по Conversions API как значения event_name. Events API TikTok несёт собственный стандартный набор с тем же подписочным этапом. Этапы после первого платежа - там, где обвязка становится интересной и где большинство связок молча останавливается.

Триал и подписка: два сигнала, а не два имени одного

Этап триала существует, потому что дёшево конвертит колеблющихся, и площадка должна видеть обе стороны этой сделки:

1. Стреляйте событием триала в момент старта. Это сигнал объёма - момент начала отношений с пользователем, без всяких денег. Как кастомная конверсия или просто событие, это способ судить кампании по квалифицированному входу, а не по сырым кликам.
2. Стреляйте Subscribe - с параметром value - в момент первого платежа. Это правда о приобретении: триал пережил обрыв churn и конвертнулся. Механика value здесь та же, что в любом платном флоу: выплата как value с currency в custom_data (параметры custom data).

Кампании, оптимизирующиеся на событиях триала, закупают объём, который может никогда не заплатить; кампании на Subscribe закупают подтверждённые деньги меньшим объёмом. У байеров с обоими событиями в достатке обычно оптимизация стоит на Subscribe, а StartTrial читается как диагностический слой - та же двухпоточная логика, что в COD аппрув рейт, где роль колл-центра играет обрыв churn.

Ребиллы: идентичность, value и свежий тайминг

Рекуррентная часть воронки - там дисциплина идентичности окупается:

1. Каждый ребилл получает собственную транзакционную идентичность. Параметр класса tid у Keitaro «записывает отдельные конверсии вместо перезаписи предыдущей» (postback URL) - ровно поведение, нужное ребиллам. Без него постбек третьего месяца перезапишет строку конверсии первого месяца, и история воронки схлопнется.
2. Каждый ребилл несёт своё value. Смена цены, скидки и апгрейды тарифов едут полем выплаты в постбеке; поля value и currency события следуют за ними (параметры custom data).
3. Ребиллы отправляются свежими. Окно приёма event_time площадки - семь дней у Conversions API Meta - измеряется от собственного таймстампа события до момента отправки, а таймстамп ребилла - момент списания. Отправляйте тем же днём, и тайминг не проблема: ребилл не наследует возраст исходного клика.

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

Отмены и неуспешные списания: где они живут

Подписки заканчиваются, и у окончания нет стандартного площадочного события:

• Отмена на продлении. Сеть просто перестаёт ребиллить - самый чистый случай. Поток конверсий трекера обрывается; уже отправленные события площадки остаются насчитанными.
• Рефанд или чарджбек посреди цикла. Параметр выплаты у Keitaro «поддерживает положительные и отрицательные значения», поэтому книги трекера корректируются; площадочная сторона хранит исходное событие - по правилам коррекций из гайда о выплате.
• Неуспешное списание и восстановление. Успешный даннинг-ретрай - новый ребилл с собственной идентичностью и value, а не перезапись провалившегося цикла.

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

Сборка воронки на площадке

Площадочная сборка:

1. Отправляйте каждый этап под решённым именем - стандартные StartTrial/Subscribe там, где стандартное событие подходит, кастомные имена для событий циклов.
2. Постройте кастомные конверсии по этапам, чтобы каждый появился в отчётности и, где уместно, в optimization dropdown (разбор кастомных конверсий).
3. Выберите цель оптимизации по марже: Subscribe для кампаний приобретения, события триала - только там, где конверсия триал-в-оплату достаточно высока, чтобы ей верить.
4. Кормите каждый этап стабильно - дисциплина прогрева из гайда о последовательности действует на событие, а не на пиксель целиком.

Верификация закрывает сборку: один тестовый пользователь через триал, первый платёж и сымитированный ребилл - каждый виден в Test Events и Events Manager примерно за 20 минут (get started), каждый со своим value в трекере.

События подписочных воронок: частые вопросы

Источники