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

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

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

Ситуация: конверсия случается там, куда у вас нет доступа

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

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

Вся ситуация поэтому сводится к одному вопросу: что вы способны снять на принадлежащих вам участках воронки и насколько надёжно способны переслать дальше?

Что вы на самом деле контролируете: ссылки, трекер, сервер

Даже с нулевым доступом к лендингу три точки воронки полностью ваши:

1. Сам клик. Ваше объявление ведёт на ссылку трекера (или прелендинг, который вы хостите), поэтому click ID площадки - fbclid, ttclid, rdt_cid - приходит на страницу, которой владеете вы. Трекер сохраняет клик с этим идентификатором до всякого редиректа.
2. Редирект на оффер. Трекер дописывает к URL оффера собственный sub ID, а сеть обязуется вернуть этот sub ID эхом в постбеке. Именно этот контракт делает возможным матчинг потом.
3. Инфраструктура доставки. Когда постбек сети объявляет конверсию, он приземляется в вашем трекере - а пересылка события площадке оттуда уже ваша интеграция, ваша автоматизация, ваш код.

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

Путь доставки по шагам

Полный путь от оплаченного клика до события на стороне площадки:

1. Пользователь кликает объявление. Площадка добавляет click ID; трекер записывает клик, идентификатор, IP и user agent.
2. Трекер перенаправляет пользователя на оффер, дописывая sub ID к URL оффера.
3. Где-то на странице рекламодателя пользователь конвертится. Подтверждение действия сети передаёт рекламодатель.
4. Сеть отправляет S2S-постбек трекеру, возвращая sub ID и детали конверсии - статус и выплату в том числе.
5. Трекер матчит постбек с сохранённым кликом и доставляет конверсию рекламной площадке серверным событием - через интеграцию трекера или автоматизацию, действующую от его имени.

Keitaro документирует оба конца этого пути: S2S-постбек, принимающий объявление сети, - с {external_id} под click ID и {conversion_revenue} под выплату - и встроенную интеграцию, пересылающую сматченные конверсии в Conversions API Meta (интеграция Facebook Conversions у Keitaro). Механика каждого хопа в общем виде - в полном гайде по арбитражному трекингу.

Одно свойство этого пути важнее остальных: после клика он целиком серверный (server-to-server). Ни один браузер на пути не принадлежит моменту конверсии, поэтому ничто не зависит от того, загрузит ли лендинг ваши скрипты - ваши скрипты он не грузит никогда.

Что площадка требует от серверного события

Серверное событие - это структурированный POST, и каждая площадка документирует свой минимальный набор полей. Требования Meta к website-событиям проговорены прямо: событие обязано нести action_source, event_source_url и client_user_agent, а non-web события требуют только action_source (Conversions API parameters). event_time может отстоять от момента отправки максимум на семь дней в прошлое, и одно протухшее событие валит весь запрос (using the API).

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1790000000,
      "event_source_url": "https://your-tracker.example/offer/47",
      "event_id": "postback-88412",
      "action_source": "website",
      "user_data": {
        "client_ip_address": "203.0.113.24",
        "client_user_agent": "<user-agent-of-the-original-click>",
        "fbc": "fb.1.1790000000.IwAR0abc"
      },
      "custom_data": {
        "currency": "USD",
        "value": 49.99
      }
    }
  ]
}

Два поля в примере заслуживают внимания именно в ситуации без доступа. event_source_url не может указывать на чекаут рекламодателя - санкционированного знания о нём у вас нет, - поэтому байеры указывают собственный URL оффера или редирект трекера. А fbc в payload существует только потому, что трекер снял fbclid в момент клика: Meta документирует, что значение куки _fbc собирается из URL-параметра fbclid, когда браузер куку не поставил (fbp and fbc parameters).

У Reddit Conversions API принимает серверные события в течение семи дней от конверсии и дедуплицирует с пикселем по conversion ID; гайд прямой интеграции лежит в документации API Reddit. Серверный аналог TikTok - Events API, занимающий в воронке TikTok ту же роль.

Чего вы лишаетесь без домена лендинга

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

Компенсирует всё, что снято в момент клика на вашей стороне:

Практическое следствие видно в Event Match Quality у Meta: события с click ID, IP и user agent набирают рабочие оценки, а события с одним таймстампом сползают к низу шкалы (About Event Match Quality). Наш глоссарий про ключ матчинга и статья про качество событий разбирают поля по каждой площадке.

Мета-специфика отчёта арбитражных конверсий под кастомными именами событий - отдельный глубокий разбор: кастомные конверсии Facebook CAPI для арбитражных офферов.

Площадка за площадкой: куда уезжает событие

Ситуация не зависит от площадки; поверхность доставки - зависит.

Выбор канала доставки - нативная интеграция трекера против отдельной автоматизации против ручного POST - сравнивается в гайде постбеки против Conversions API. Коротко: интеграция трекера держит обвязку в одном месте, а слой автоматизации поверх добавляет ретраи, дедуп и правила value по офферам, которых одним трекером обычно не закрыть.

Проверка связки до масштабирования

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

1. Стрельните тестовым кликом и пройдите воронку до реальной или сымитированной сетью конверсии.
2. Убедитесь, что постбек дошёл до трекера с непустым sub ID - S2S-лог Keitaro показывает, какой subid инициировал отправку и что ответил источник.
3. Убедитесь, что серверное событие дошло до площадки: Test Events у Meta показывает прибытия почти в реальном времени, а в Events Manager события становятся видны примерно за 20 минут (get started with the Conversions API).
4. Проверьте сигналы качества матчинга события в Events Manager и почините тощие - обычно это отсутствующий click ID или user agent - до повышения бюджета.

Для бесплатных одиночных тестов Meta-ноги Pixel Activator стреляет тестовыми событиями с одним датасет-ID и токеном. Режимы отказа между шагами разбирает чеклист поиска неисправностей постбеков.

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

Источники