Постбэки, пиксели и теги-картинки: платить можно только по одному

О конверсии можно сообщить тремя способами: пиксель-картинкой, JavaScript-пикселем или server-to-server постбэком. Только постбэк держится достаточно надёжно, чтобы платить по нему комиссию, потому что ему не нужно, чтобы браузер игрока сотрудничал. Большинство интеграций, которые «не трекают», это вовсе не сломанные постбэки, а отсутствующие идентификаторы клика в записи игрока.

Звонок всегда приходит в неудобный час. У аффилейт-менеджера партнёр угрожает снять трафик, оператор клянётся, что интеграция живая, а дашборд показывает ноль. Кто-то присылает скриншот тега в футере страницы успешного депозита и спрашивает, почему это не работает.

Это не работает, потому что это тег в футере страницы.

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

Три способа сказать, что игрок сделал депозит

Пиксель-картинка. Самый старый. Ваша страница содержит изображение размером в один пиксель, источник которого это URL трекинговой платформы. Браузер пытается загрузить картинку, запрос уходит на платформу, и сам запрос и есть сообщение. Никакая картинка на самом деле не нужна, важен сам запрос. Требуется только HTML, поэтому он так долго выживал в шаблонных системах, где никто не хотел трогать JavaScript.

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

Server-to-server постбэк. Браузера нет вообще. Когда ваш бэкенд фиксирует нужное событие, он делает HTTP-запрос на URL, неся идентификатор, полученный при первом приходе игрока. Платёжный сервис подтверждает депозит, ваша система записывает транзакцию, и где-то на том же пути уходит запрос: этот игрок, это событие, эта сумма, эта валюта.

Вот и вся идея. Звучит менее умно, чем два других способа, и именно поэтому держится.

Почему два из трёх перестали быть надёжными

Единственной причины нет. Есть стопка причин, и каждая по отдельности была бы переживаема.

Safari и Firefox блокируют сторонние куки по умолчанию, а Firefox дополнительно блокирует запросы к доменам из своего списка трекеров. Chrome сторонние куки пока разрешает, поэтому в Chrome блокировка приходит от блокировщика рекламы, а не от браузера. Safari к тому же ограничивает срок жизни хранилища, записанного скриптом, в отдельных случаях до нескольких дней, а значит всё, что опирается на состояние, записанное в момент клика и читаемое в момент депозита, истекает быстрее, чем длится нормальное окно принятия решения. Поверх всего этого сидят блокировщики рекламы, распространённые ровно в той аудитории, которая читает сравнения перед регистрацией. Ничто из этого о себе не объявляет. Оператор видит, что страница отрисовывается нормально, и делает вывод, что интеграция работает.

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

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

Сценарии поломки, которые стоит знать

Никто не ломает интеграцию интересным способом. Почти всё объясняется одними и теми же шестью ошибками.

Срабатывание на загрузку страницы вместо события. Тег живёт на странице подтверждения депозита и срабатывает каждый раз, когда эту страницу открывают. Игрок обновляет её, возвращается через историю или попадает туда после неудачной попытки, и каждый раз это конверсия в вашей отчётности. Цифры раздуваются в ту сторону, которая выглядит хорошо, поэтому такое живёт долго, прежде чем кто-то задаст вопрос.

А оно точно серверное? Бэкенд-фреймворк, рендерящий шаблон, всё равно отдаёт тег, который должен выполнить браузер. Если запрос исходит с устройства игрока, это браузерная сторона, в каком бы файле это ни было написано. Проверка занимает минуту: заблокируйте скрипты в своём браузере и посмотрите, приходит ли событие.

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

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

Идемпотентность, точнее её отсутствие. Сети отваливаются по таймауту. Хорошо сделанный отправитель повторяет запрос, и это правильно. Если принимающая сторона не может понять, что вторая попытка это то же самое событие, ретрай превращается во вторую конверсию. Каждому событию нужен стабильный уникальный идентификатор с вашей стороны, одно и то же значение при каждой повторной отправке, чтобы дубликат распознали и отбросили, а не оплатили дважды.

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

Одна вещь, которая решает всё

Любая поломка выше чинится за вечер. Эта нет.

Когда игрок приходит по трекинговой ссылке, идентификатор из этой ссылки должен быть сохранён в записи игрока при регистрации. Не в сессии. Не в куке. В той строке вашей базы, которая представляет этот аккаунт, рядом с адресом почты, в той же транзакции, которая её создаёт.

Если этого не происходит, ничего дальше атрибутировать нельзя. Игрок депозитит через три недели, ваш бэкенд отправляет технически безупречный постбэк, и он не несёт идентификатора, потому что нести нечего. Никакая настройка постбэков это не чинит. Вы отлаживаете не проблему отчётности, а проблему регистрации, и правка лежит во флоу регистрации.

Две смежные привычки экономят много споров. Сохраняйте идентификатор, даже если значение выглядит странно, потому что вы храните токен, а не валидируете его. И храните его на всё время жизни аккаунта, а не тридцать дней, потому что CPA, платящий за квалифицирующий депозит, требует, чтобы связь всё ещё существовала в момент, когда депозит квалифицируется, а это может быть через месяцы после клика. Если у вас на стороне размыта терминология вокруг квалифицирующих и первых депозитов, глоссарий FTD, NGR, CPA, CPL и CPR стоит десяти минут до того, как вы напишете схему.

Как протестировать это до запуска трафика

Правильный тест интеграции скучен и занимает примерно час.

1. Кликните по реальной трекинговой ссылке и пройдите регистрацию как обычный игрок. Затем посмотрите запись игрока в своей базе и убедитесь, что идентификатор в ней есть. Если его нет, остановитесь, потому что всё дальше это театр.
2. Внесите реальные деньги. Небольшой суммы достаточно, хватит 20 EUR. Платежи в тестовом режиме часто пропускают ровно ту ветку кода, которая отправляет событие, и именно так интеграции проходят на стейджинге и падают в первый день.
3. Проверьте, что событие депозита пришло один раз, с правильной суммой и правильной валютой, после расчёта платежа, а не в момент его отправки.
4. Отправьте то же событие ещё раз намеренно. Оно должно быть распознано как дубликат и не посчитано дважды.
5. Повторите всё с телефона и ещё раз с депозитом в приложении, а не в браузере, если приложение у вас есть.

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

Что AFFILIFY ждёт от оператора

Справочник по интеграции лежит на affilify.partners/docs, там эндпоинт, названия параметров и принимаемые типы событий. Читайте там, а не в блоге, потому что актуальной мы держим именно ту страницу.

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

Две вещи стоит сказать прямо. Атрибуция на нашей стороне имеет многослойные запасные механизмы. Это страховка, а не план. Идентификатор, сохранённый при регистрации, это та часть, которую контролируете вы, поэтому присылайте его. И качество трафика оценивается постоянно, а значит часть конверсий удерживается на проверке, а не зачисляется сразу. Это не отказ, и партнёр видит статус, а не тихий пробел.

Оператор, который возвращает идентификатор, сообщает о рассчитанных событиях один раз и проверяется реальным депозитом за час, никогда не окажется в разговоре в одиннадцать вечера. В этом и вся амбиция.