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

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

ТЗ должно выявить недостающие условия до реализации: действие в приёмнике, событие источника и поля, которые их связывают. Используйте пять наборов ниже как чек-лист, затем проверьте требования каждой названной системы.

Что закрывают входные данные конверсионного пути

Way2 публикует этот же список как данные, которые заказчику нужно подготовить до обращения, и удобен он именно тем, что не называет ни одного секрета:

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

Граница у всего документа одна. Записи, которые ведёт путь, «do not promise attribution or bidding outcomes inside an ad platform», то есть обещание атрибуции в ТЗ противоречит его же назначению. Документ фиксирует исходные данные для сборки пути по согласованным полям. Результаты рекламного аукциона в его условия не входят.

Пять обязательных наборов и что каждый разблокирует

Пять строк таблицы задают входные данные конверсионного пути; маршрут и формат постбека требуют подробного описания. Маршрут в формулировке «у нас есть бот» полем не является: в реестре маршрута клик связывают с выданным для него invite, поэтому наблюдаемым полем на стороне бота становится событие вступления с invite_link; сырой идентификатор клика там не появляется, и именно эту связку ТЗ фиксирует до остального. Telegram повторяет доставку обновления, если webhook отвечает статусом вне диапазона 2xx, а затем прекращает попытки после разумного их числа; точное число здесь не задано. Учтите это поведение в ТЗ. Постбек в формулировке «мы шлём статус» форматом тоже не является. Вокруг subid и status живут идентификатор транзакции, выплата, валюта и до тридцати параметров обновления клика, и имена этих полей у трекеров различаются, так что именно состав поля решает, можно ли привязать сумму к нужному клику. Форма принимающего URL тоже опубликована: трекер задаёт её как IP/postback-key/postback?subid=REPLACE&status=REPLACE&payout=REPLACE, и в ТЗ этот пример лучше перенести дословно, не выводя собственный синтаксис подстановок.

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

# ТЗ по пути конверсии: передаём форму, а не значение
path_id: "tg-deposit-2026q3"
observed_from: "2026-09-10"
landing:
  url: "https://example-landing.test/of/2117"
  click_parameters_surviving_redirect: ["gclid", "subid"]
route:
  bot_owned_by: "customer"
  transport: "webhook"
  admin_in_channel: true
  subscribed_update_types: ["message", "my_chat_member", "chat_member"]
postback:
  source_system: "Keitaro"
  # задокументированная форма принимающего URL, значения подставляет отправитель;
  # форма со скобками {subid} относится к Postback Pixel на стороне страницы и, по документу, работает только на index.html или index.php
  url_shape: "https://tracker.test/<POSTBACK_KEY_WITHHELD>/postback?subid=REPLACE&status=REPLACE&payout=REPLACE&currency=REPLACE"
  click_field: "subid"
  status_field: "status"
  # итоговый список задаёт договор с партнёром; ниже задокументированные типы трекера, неизвестный статус без обучения игнорируется
  status_values_allowed_to_send: ["deposit", "rejected"]
correlation:
  # ключ согласуют во время картирования реального пути и переносят в ТЗ вместе с ним
  landing_click: "gclid или subid в том виде, в каком их сохранил лендинг"
  invite_issued: "уникальный invite, выданный для маршрута этого клика"
  mapping_stored_by: "какая система на стороне лендинга хранит связь идентификаторов привлечения с выданной пригласительной ссылкой; укажите её в ТЗ"
  join_event: "обновление chat_member: ChatMemberUpdated с invite_link"
  deposit_lookup: "какая система отвечает на запрос о том, чей это клик, в момент депозита"
  partner_call: "subid, возвращённый постбеком депозита"
  join_key_carried: "yes"
event_mapping:
  google_conversion_action_name: "<согласованное имя ConversionAction>"
  meta_event_name: "<согласованное имя события Meta>"
destinations:
  - platform: "google_ads"
    account: "123-456-7890"
    action_exists: true
    import_method: "server_click_upload"  # серверная загрузка конверсий по клику
    role: "primary"
credentials_policy:
  tokens_in_this_document: "none"
  handover: "отдельный отзываемый доступ на систему, выдаёт владелец"
  consent_statement: "разрешение передавать данные о конверсиях в каждое назначение подтвердил владелец"
acceptance:
  sent: "строка исходящего журнала с назначением и ответом"
  accepted: "ответ приёмника плюс его собственные счётчики"
  counted: "отчёт приёмника по названному действию и окну"
  not_in_scope: "атрибуция и результат торгов"

Учётные данные не включают в текст ТЗ

Опирайтесь на опубликованное правило приёмника, а не на общую осторожность. Документация трекера описывает адрес постбека как сочетание сервера, postback key, который используется для безопасности и аутентификации запросов, и конверсионных параметров. Рабочий URL постбека содержит учётные данные. Не вставляйте рабочий URL или ключ в тикет: в ТЗ указывайте только форму адреса с именованной заглушкой, а само значение передавайте по согласованному владельцем защищённому каналу.

Та же логика закрывает остальные углы пути. Токен бота аутентифицирует всё, что бот способен сделать, а в ТЗ нужны только транспорт и подписанные типы обновлений; если интеграции надо подтвердить, что webhook именно её, для этого документирован секретный токен в заголовке запроса, и это конфигурация, а не текст. Токены рекламных API принадлежат владельцу аккаунта и выдаются под конкретную интеграцию, а привычка не отдавать идентификатор и токен третьим лицам описана и для пикселей, см. гайд про ID пикселя и токен Conversions API. Для интеграции в инфраструктуре заказчика запишите, где будут храниться учётные данные, кто сможет их использовать и как отозвать доступ. Подтвердите эти границы в договоре.

Для импорта в Google Ads укажите, как задаётся согласие на передачу данных: через настройки по умолчанию на уровне аккаунта либо через поле согласия в каждой загружаемой конверсии или записи пользовательских данных. Это настройки передачи данных, которые нужно описать отдельно от учётных данных. Настройка S2S-постбека в Keitaro показывает, как выглядит состав параметров в реальной панели; в ТЗ укажите имена полей, заменив секретные значения заглушками.

Четыре строки приёмки вместо одной подписи

Единая подпись «события долетают» позже обходится заказчику спором, поэтому входные данные конверсионного пути делят её на четыре строки с отдельными ответственными. Служебный FAQ формулирует это разделение прямо.

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

Дефекты документа, их доказательства и следующий тест

Рядом лежат четыре артефакта, и ни один во входные данные конверсионного пути не входит. Контракт схемы событий описывает поля: обязательность ключей, семантику типов, поле дедупликации. Документ об архитектуре решает, кто отвечает за повтор и где передаётся ответственность между источником, маршрутизатором и приёмником. Вопрос «способен ли источник вообще что-то выдать» относится к разведке до ТЗ, а прогон одного события в несколько приёмников с отдельным чтением каждого ответа это приёмочный тест после него. Стоит подшить любой из них сюда, и документ перестаёт быть проверяемым, а это единственное его полезное свойство. Та же граница раскладывает и тесты из таблицы выше: каждый из них закрывается артефактом, который документ показывает до старта, а проверка, которой нужен живой сбой, относится к страницам ниже.

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

Источники