Матрица параметров конверсий для платформ: одно событие, шесть сетей

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

Когда вы маршрутите одну конверсию в Meta, TikTok, Reddit, Snapchat, Pinterest и Google Ads, каждая сеть принимает её независимо и дедуплицирует независимо. Meta не спрашивает TikTok, засчитана ли покупка; каждая платформа схлопывает дубли внутри своей отчётности по ключу, собранному из параметров, которые вы передали. Подвох: имя параметра, правила матчинга и окно дедупликации у каждой сети свои.

Типичный сбой знаком всем, кто льёт на несколько сетей: один и тот же заказ улетает в Meta и Snap с ID, приложенным только к одной из них, - одна сеть насчитывает конверсию дважды, вторая дедуплицирует то, что должна была засчитать. Матрица параметров конверсий решает это как задачу маршрутизации: один канонический ID конверсии, переведённый в поле, которое ждёт каждая сеть.

Концептуальная модель - в дедупликации по event ID; этот гайд - карта полей.

Матрица

Видны два паттерна. Meta, TikTok и Pinterest сошлись на одном имени поля - event_id - что позволяет кормить их из одного payload. Reddit назвал ключ по тому, что тот идентифицирует: рекомендованный метод conversion_id, а без общего ID - фолбэк на сессионный дедуп. Snapchat разделил заботу: универсальный client_dedup_id для любого события в окне 48 часов и transaction_id только для покупок с гораздо большим окном в 30 дней. Google стоит вне паттерна событийного потока: его transaction ID применяется к конверсиям, которые вы импортируете или корректируете, и документирован как способ минимизации дублей. Путь настройки Reddit, включая объекты payload, - в настройке Reddit Conversions API; сторона отказов всех сетей собрана в кодах ошибок CAPI.

Двухпараметровая система Snap

Документация Conversions API Snap прямо называет два рекомендуемых параметра. client_dedup_id работает для любого события и открывает окно дедупликации в 48 часов; это любая строка, если она уникальна для события и одинакова во всех трекерах, сообщающих о нём - Snap прямо называет Pixel, CAPI и MMP. transaction_id доступен только для событий покупки и открывает окно в 30 дней; на покупке их можно комбинировать.

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

Один ID конверсии, который работает везде

Устойчивый пайплайн держит один источник правды: трекер или бэкенд уже назначает уникальный ID заказа или лида. Это значение становится каноническим ID конверсии, а слой доставки маппит его под каждую сеть:

Канонический ID: order-8842
  -> Meta:      event_id = "order-8842"     (+ тот же event_name в обоих каналах)
  -> TikTok:    event_id = "order-8842"
  -> Pinterest: event_id = "order-8842"
  -> Reddit:    conversion_id = "order-8842"
  -> Snap:      client_dedup_id = "order-8842", transaction_id = "order-8842"
  -> Google:    transaction_id / order ID = "order-8842" (импорт и корректировки)

Две дисциплины держат схему честной. Первая - стабильность: канонический ID назначается один раз, в момент конверсии, и никогда не перегенерируется - переотправка со свежим ID превращает одну конверсию в две в каждой сети. Вторая - симметрия каналов: где бы браузерный тег и серверный вызов ни сообщали об одном событии, оба обязаны нести идентичный ID; в этом весь механизм дедупликации Facebook Pixel и CAPI и её TikTok-версии в доставке TikTok Events API из трекеров.

Клик-идентификаторы живут по той же кроссплатформенной логике, но с другими именами - fbclid у Meta (сохраняется в куке _fbc), ttclid у TikTok, rdt_cid у Reddit, ScCid у Snap - и едут отдельно от ключей дедупликации. А вот _fbp - не клик-идентификатор: это идентификатор браузера, а не клика. Про серверный контекст всей матрицы см. серверный трекинг против браузерных пикселей и гайд по server-side tracking для перфоманса.

Автоматизация матрицы

Матрица - ровно тот набор правил, который люди рано или поздно перестают применять: запускается новый лендинг, кто-то забывает про Snap client_dedup_id, и отчётность этой сети тихо раздувается. Ровно для этого сделан MOST: один постбек на входе - корректные параметры каждой сети на выходе, с ретраями и дедупликацией по каждой сети. Для одиночного лендинга и ручного воркфлоу ту же логику параметров без кода применяет Pixel Activator.

Прежде чем довериться любой автоматизации, валидируйте по сетям: Meta Test Events для Meta, Events Manager test events для TikTok и привычка сверки из чеклиста по постбекам для остальных.

Sources