Постбэк

Происхождение и история

К 2020 году в документации CAKE была описана серверная рекламная схема: сохранить переданную при переходе метку, затем вернуть её в postback-запросе после целевого действия. Она позволяла сопоставлять переход и результат без опоры на сохранённый в браузере cookie — небольшой фрагмент данных сайта. Документ фиксирует существовавший способ работы, а не его изобретение. ^[9]

В мобильной рекламе развивалось и другое применение постбэка: отчёт с управляемой задержкой и ограниченным составом сведений. Это документированный пример Apple, а не обязательный этап развития каждой серверной интеграции. В докладе WWDC 2020 о SKAdNetwork — системе измерения установок приложений — Apple объясняла отправку отчёта рекламной сети после завершения таймера. Отправляло его устройство пользователя. Получатель проверял подпись Apple, а некоторые дополнительные поля могли отсутствовать из соображений конфиденциальности. ^[6]

На WWDC 2022 Apple анонсировала для SKAdNetwork 4 переход от одного постбэка к трём, связанным с отдельными периодами после установки. Это позволяло сообщать о последующей активности, а не только о раннем результате. ^[7] Таким образом, менялись содержание и периодичность самих отчётов. Несколько сообщений могли означать разные периоды наблюдения, а не повторную доставку одной записи. Эти исторические решения нельзя переносить на нынешние серверные интеграции других поставщиков.

Суть и механизм

В серверной схеме TUNE при клике рекламодателю передаётся идентификатор сеанса — условная метка, связывающая этапы взаимодействия. Рекламодатель сохраняет её, а при конверсии, то есть учитываемом целевом действии, возвращает системе для проверки. ^[8] В этой последовательности уведомление помогает соединить действие с ранее зарегистрированным переходом.

Учебный пример: человек пришёл по рекламе и зарегистрировался на сайте курса. Переход получил метку C7, регистрация — отдельный номер E42. Сервер отправил партнёру тип события и согласованные идентификаторы. Если отправка E42 повторилась, новой регистрации не возникло. Если тот же человек позднее купил курс, покупка получила собственный номер E43. Нельзя удалять её только потому, что метка перехода осталась C7.

Это различие важно при настройке полей: в AppMetrica click_id обозначает клик или показ, а не каждое последующее действие. ^[2] Поэтому в учебной схеме номер события служит для устранения повторов, а метка перехода — для связи с рекламой. Названия и смысл реальных полей нужно брать из документации участников обмена.

Атрибуция — распределение учтённых результатов между рекламными взаимодействиями по заданным правилам. AppsFlyer описывает её именно как модель правил. Окно атрибуции ограничивает время между взаимодействием и событием, в пределах которого их ещё сопоставляют. ^[4] Например, в учебной модели можно засчитывать регистрацию после допустимого клика, но отклонять слишком позднюю. Постбэк сообщает результат такого решения; само решение не доказывает, что человек без рекламы никогда бы не зарегистрировался.

Виды и классификации

Удобно различать сообщения по тому, о каком действии они сообщают. Следующая группировка редакционная; перечисленные события взяты из документации AppMetrica, а не объявлены универсальным стандартом. ^[2]

Такая таблица помогает согласовать словарь обмена. Если одна сторона называет «покупкой» создание заказа, а другая — его оплату, одинаковое название поля не устранит расхождение. Это учебный пример ошибки согласования, а не описание поведения AppMetrica.

Как применяется на практике

Российский пример — AppMetrica. Параметры исходной ссылки можно подставлять в адрес или тело отправляемого запроса с помощью макросов, то есть обозначений, заменяемых значениями. Система считает отправку успешной при ответе HTTP 200 OK; при другом ответе выполняет повторные попытки по собственной политике. ^[2] Здесь HTTP — протокол обмена запросами и ответами, а число 200 — код ответа приёмника.

Для сравнения полезна документация Stripe о webhook — уведомлении обработчика об изменении, например платёжном событии. Stripe рекомендует быстро вернуть успешный ответ группы 2xx до сложных последующих операций. Также предусмотрена проверка подписи сообщения с использованием содержимого запроса, специального заголовка и секрета получателя. ^[3] Это конкретный пример разделения доставки, проверки происхождения и дальнейшей обработки. Заголовок или алгоритм Stripe не становится обязательным для рекламной системы лишь потому, что обе отправляют уведомления.

Как измерить или проверить

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

Учебный пример: отправитель зарегистрировал 100 подходящих событий и сделал 120 попыток. Приёмник записал 116 запросов, содержащих 96 различных номеров событий. Значит, в его журнале 20 повторных записей сверх первых поступлений, а четыре ожидаемых события к моменту сверки отсутствуют. Это не означает, что недоставленных попыток тоже четыре: судьбу каждой попытки проверяют отдельно.

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

Здесь U — число разных ожидаемых событий, найденных у приёмника, E — число всех событий, подлежащих отправке в выбранной группе. Повторы в числитель не входят. При отсутствии ожидаемых событий знаменатель равен нулю, поэтому показатель не рассчитывают. Это предложенная метрика полноты доставки, а не показатель эффективности рекламы или доля оплаченных заказов.

Для защиты от повторного учёта Stripe рекомендует запоминать идентификаторы уже обработанных событий; отдельно оговаривает случаи разных объектов уведомления об одном бизнес-событии. ^[3] Практический вывод: ключ устранения дублей согласуют по смыслу данных, а не выбирают только по удобному названию поля.

Ошибки и ограничения

Главная ошибка — соединить в одном числе возникшие события, отправленные запросы и принятые к оплате результаты. В рассмотренных системах это разные этапы. ^{[2, 3]} Успешная доставка сообщения с ошибочной суммой сама по себе не исправляет сумму; это простое следствие разделения передачи и проверки содержания.

Другая ошибка — считать любое повторное сообщение дублем. В историческом примере Apple несколько постбэков описывали разные периоды. ^[7] Обратная ошибка — принимать каждую повторную доставку одного события за новую конверсию. Сначала нужно установить, какую запись и какой период представляет уведомление.

Сроки повторов, допустимые ответы и способы проверки происхождения следует сверять с конкретной документацией. Правила AppMetrica и Stripe выше приведены раздельно именно потому, что выполняют разные договорённости обмена. ^{[2, 3]}

Правовой аспект

В России технический идентификатор нельзя автоматически считать неперсональными данными. По статье 3 пункту 1 закона № 152-ФЗ учитывается и косвенная определимость человека; передача таких сведений входит в обработку по пункту 3. Следовательно, правовая оценка зависит от состава данных и возможности связать их с человеком, а не от названия поля. ^[5]

Согласие — одно из оснований обработки, названных в статье 6 части 1 пункте 1; пункт 2 предусматривает иное основание при выполнении установленных законом задач. Это не общее разрешение передавать рекламные данные без согласия. Применимость основания к конкретному обмену требует отдельной юридической оценки. Использована редакция закона от 26.07.2026; серверная форма запроса сама по себе такого основания не создаёт. ^[5]

Частые вопросы

Связанные термины

• atributsiya
• cpa-set
• konversiya
• piksel-otslezhivaniya
• ad-fraud