Настройка Snapchat Conversions API - токен, match keys и качество сигнала
Что покрывает Conversions API Snap
Snapchat Conversions API - серверный приёмник Snap: события едут с вашего сервера к Snap по прямой интеграции, и Snap ставит его в один ряд со Snap Pixel и App Ads Kit SDK как равнозначные каналы измерения. Доставленные события открывают post-view и post-swipe репортинг кампаний, а в зависимости от полноты данных питают также custom audience targeting, оптимизацию кампаний и Dynamic Ads. Для арбитражной воронки, где конверсия случается на оффер-странице вне вашего контроля, это единственный канал, который доносит конверсию до Snap вообще - общая модель стандартная, это conversions API.
Референс Snap при этом без обиняков называет входной билет, на котором ломается большинство интеграций: событие без match key не попадает вообще. Дальше - документированный путь: токен, обязательные поля, хэширование, дедупликация и валидация.
Сгенерируйте long-lived токен в Business Manager
Аутентификация рекламодателя у Snap обходит полный OAuth-цикл: вы генерируете статический long-lived токен, который не истекает, прямо в интерфейсе Business Manager. Документированный путь: Business Manager, секция OAuth Apps, где появляется подраздел Conversions API Tokens - видимый только Organization Admin, - с кнопкой Generate Token. OAuth-поток существует для платформ, интегрирующихся от лица множества клиентов; одиночному рекламодателю со своей воронкой он не нужен.
Токен передаётся в заголовке запроса так же, как OAuth-токен: Authorization: Bearer <token>. Для мульти-аккаунтных связок в референсе есть правило scope: токен отправляет события только для pixel и app ID из той же организации, что и сам токен, - токен одной Org в паре с пикселем другой Org упадёт. Дисциплина хранения та же, что у других сетей: сервер, а не клиент, как и для любого CAPI-креденшела.
Передайте match key - или событие упадёт
Требование Snap прямое: хотя бы одно из следующего должно присутствовать, чтобы событие приняли вообще - hashed_email, hashed_phone_number, пара hashed_ip_address плюс user_agent или hashed_mobile_ad_id для app-рекламодателей. Запрос без них завершается ошибкой; это жёсткий гейт, отделяющий рабочие интеграции от молча сломанных. Когда данные доступны, Snap рекомендует передавать все параметры для улучшения производительности.
Помимо обязательного набора Snap ведёт рекомендованный список, повышающий match rate, - поля поверх обязательного. Два из них особенно важны для воронок с трекером. click_id берёт значение из параметра &ScCid= лендинг-URL, и Snap советует передавать вместе с ним полный URL в page_url - та же дисциплина поимки в момент клика, что в разборе fbclid и ttclid. А pixel_id обязателен для web и offline событий - так событие атрибутируется правильному источнику данных.
Типы событий - фиксированный enum: PURCHASE, START_CHECKOUT, ADD_CART, SIGN_UP, SUBSCRIBE, PAGE_VIEW, SEARCH и остальной документированный набор плюс пять слотов CUSTOM_EVENT_1 - CUSTOM_EVENT_5 для всего, чего в enum нет.
Сначала нормализация, потом SHA-256
Правило хэширования встречается в референсе Snap дважды, потому что именно здесь интеграции ломаются тихо: сначала нормализация, потом хэш. Сырые идентификаторы - plaintext email, телефон, IP, mobile ID - нормализуются до SHA-256, а выходной формат - строка lowercase hex. Собственный пример Snap проводит email целиком: [email protected] становится lowercase [email protected], что даёт фиксированный 64-символьный дайджест. Хэш IP считается от IP устройства - не сервера - и поддерживает IPv4 и IPv6.
Различия нормализации между сетями - место, где общий генератор payload начинает сбоить: общая дисциплина одинаковая, платформенные правила собраны в хэшировании user data для CAPI. Для Snap ориентируйтесь на примеры из официальной документации, а не переносите препроцессинг другой сети дословно.
Дедупликация между пикселем, SDK и API
Snap ожидает, что рекламодатель держит несколько интеграций сразу, и референс называет ключи координации. client_dedup_id должен совпадать в Snap Pixel, App Ads Kit и Conversions API для одного и того же события и действует в пределах 48 часов от первого появления - это механизм, останавливающий двойной счёт одной конверсии между каналами. Механика из той же семьи, что дедупликация пикселя и CAPI в экосистеме Meta: общий ключ, общее значение, все каналы активны.
Для идентичности на уровне транзакции поле transaction_id несёт order ID конверсии, и Snap помечает его как важное поле дедупликации - в воронке с трекером это естественно идентификатор транзакции трекера, который и пересылает слой доставки. Параметр event_tag добавляет свободный лейбл (вроде weekend sales) для кастомных наборов событий.
Валидация через Test Events и контроль часов
Механизм Test Event у Snap повторяет payload один в один: тест, который упал бы в продакшене, падает и в тесте, валидные поля молчат, ошибки показываются. Поверх жёстких ошибок референс Snap отмечает non-fatal предупреждения, появляющиеся в зависимости от валидности и качества переданных данных, - предупреждение обычно означает match key или деталь нормализации, работающие ниже своих возможностей; ценность та же, что у тестовых событий в экосистеме Meta.
По дедлайнам у Snap запас шире, чем у большинства сетей: timestamp события не может быть старше 37 дней, и хотя Snap принимает epoch в секундах или миллисекундах, рекомендованы миллисекунды. Воронка с трекером, батчащая постбеки, переживёт в этом окне многосуточный простой, - но match key, без которого событие падает с ошибкой, остаётся более жёстким ограничением.
Если не хотите держать пайплайн на себе, MOST доставляет постбеки трекера в Conversions API Snapchat вместе с Meta, TikTok, Reddit, Pinterest и OpenAI - с хэшированием, ретраями и дедупликацией, - а бесплатный Pixel Activator закрывает доставку в Snapchat для одного лендинга.