FTD кастомное событие: депозиты как сигнал оптимизации

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

Общая механика цепочки доставки - в гайде от постбека CPA сети до Conversions API; здесь - депозитная обвязка.

Что считается FTD и почему регистрация - не оно

Вертикали, живущие на депозитах, различают два момента: первый депозит (FTD), доказывающий реального платящего пользователя, и повторные депозиты, доказывающие удержание. У площадок нет понятия «первый» - они считают события. Различие - бизнес-логика, и единственная система с достаточной историей для её применения - ваш трекер: он хранит клик и видит каждую конверсию, которую отчитывает сеть.

Обвязка поэтому распадается на два решения. Первое: трекер должен получать депозиты отдельным статусом - постбек-контракт это уже поддерживает: документированный список статусов Keitaro включает deposit рядом с lead, sale и rejected (документация постбеков Keitaro). Второе: «первый» вычисляется на стороне трекера, по пользователю - обычные маркеры это user ID, который сеть возвращает в sub ID полях, или логика по строкам конверсий аккаунта. Каков бы ни был маркер, вычислите его один раз в трекере и дайте слою доставки читать ответ.

Выбор события: стандартное, кастомное или кастомная конверсия

Серверные события Meta несут event_name, который контролируете вы, и имена вне стандартного набора площадка считает кастомными событиями (параметры серверных событий). Для депозита это даёт три легитимные формы:

Стандартный путь даёт оптимизатору максимум, но тратит имя Purchase - в котором в том же пикселе могут ехать деньги других офферов, замыливая картину. Кастомный путь держит депозиты чисто разделёнными и, через построенную поверх кастомную конверсию, всё равно становится целью оптимизации в ad set; корпусный разбор арбитражных кастомных конверсий документирует этот путь по шагам. Многие байеры гоняют обе формы: Purchase для подтверждённых денег на уровне пикселя и FTD кастомное событие для вертикального сигнала.

Events API TikTok играет ту же роль на стороне TikTok: серверные события с управляемыми вами именами, питающие тот же выбор кастомное-против-стандартного.

Обвязка FTD через трекер

Конкретная труба:

1. Постбек сети объявляет конверсию со статусом deposit - или вертикальным эквивалентом - и выплатой, которую реально внёс пользователь.
2. Трекер записывает конверсию на строку клика, причём транзакционный параметр различает множественные депозиты: параметр класса tid у Keitaro «записывает отдельные конверсии вместо перезаписи предыдущей» - ровно то, что нужно повторным депозитам (postback URL).
3. Логика первого депозита - опирающаяся на идентичность конверсии, сохранённую трекером, - помечает самый ранний депозит пользователя; повторные депозиты живут собственными строками.
4. Слой доставки пересылает: FTD как именованное событие, повторные депозиты как свои - каждый с суммой депозита как value и кодом валюты (параметры custom data).

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

Value, тайминг и объём депозитных событий

Три платформенных правила лепят депозитный поток:

1. Value. Сумма депозита кладётся в custom_data.value с валютой - та же дисциплина «выплата как value» из гайда о выплате, без клэкбэк-сложности, которой большинство депозитных потоков избегает: сам депозит и есть подтверждённый денежный факт.
2. Тайминг. event_time может отстоять максимум на семь дней в прошлое, и одно протухшее событие валит весь запрос (using the API). Подтверждения депозитов обычно быстрые, что делает FTD-потоки естественно дружелюбными к окну.
3. Объём. Оптимизации нужен стабильный приток именованного события - это дисциплина прогрева, а не переключатель: кормите событие стабильно до масштабирования на нём (прогрев пикселя).

Холд-вопрос здесь редко кусается - депозит подтверждён в момент создания, - но офферы с ребиллами и кард-верификацией добавляют собственную задержку подтверждения, и тогда статусная логика из гайда про холд применяется без изменений.

Проверка депозитного потока

Прежде чем доверять сигналу:

1. Вызовите или сымитируйте реальный депозит через ссылку кампании - тестовые постбеки сетей не несут настоящего subid, о чём предупреждает документация postback troubleshooting.
2. Убедитесь, что строка конверсии в трекере получила статус депозита, value и транзакционную идентичность.
3. Смотрите площадочную сторону: Test Events у Meta показывает именованное событие по прибытии, а Events Manager отражает его примерно за 20 минут (get started).
4. Набрав объём, постройте кастомную конверсию и убедитесь, что она появилась в optimization dropdown ad set'а, прежде чем вешать на неё кампанию.

Для бесплатных одиночных тестов Meta-ноги Pixel Activator шлёт именованные тестовые события с одним датасет-ID и токеном.

FTD кастомное событие: частые вопросы

Источники