TikTok Events API ломает атрибуцию чаще не из-за трафика, а из-за кривой передачи событий

TikTok Events API ломает атрибуцию чаще не из-за трафика, а из-за кривой передачи событий

Ставить Events API нужно как S2S-канал, а не как «дополнение к пикселю». Базовые правила: передавай event_id для дедупликации, фиксируй timestamp в UTC, не режь source/medium/campaign, а IP и user-agent отправляй в исходном виде. Если сервер и браузер шлют одно и то же событие без связки, в отчетах получишь дубль и мусорный CPA.

Самые частые провалы: • невалидный access token и тихие 4xx в логах; • payload без обязательных полей, из-за чего событие принимается частично; • рассинхрон валюты и value между фронтом и сервером; • отсутствие ретраев на сетевые ошибки. События надо валидировать на своей стороне до отправки, иначе API-гейт просто съест трафик без сигнала в оптимизацию.

Для стабильной передачи держи отдельный endpoint под конверсии, очередь на повторную отправку и логирование ответа от API. Полезно сравнивать browser event и server event по одному order_id: если расхождение растет, сначала чистим схему данных, потом уже трогаем креативы и аудиторию.

Минимальный чек: одна схема именования событий, дедуп по event_id, тестовый поток с контрольным order_id, алерты на 4xx/5xx и ручная сверка postback-цепочки. Чистим логи, проверяем постбэки. Data-driven подход или работа вслепую — выбор за тобой.