TikTok Events API ломается не на токене, а на пустых и кривых полях

TikTok Events API ломается не на токене, а на пустых и кривых полях

Для Events API важнее всего не «отправить событие», а собрать стабильный payload. Минимальный набор: event_name, event_time, event_id, user, properties. Если нет event_id — deduplication между pixel и server начнёт плавать. Если нет event_time в Unix seconds — часть событий уедет в валидацию. Если user пустой, TikTok всё равно примет запрос, но матчинг проседает.

Что обычно валится:
— email / phone без нормализации: lowercase, trim, E.164 для телефона;
— external_id без устойчивого внутреннего ID;
— ip и user_agent не из того запроса;
— contents без item_id или с пустым price;
— currency в формате не ISO 4217.

Для e-commerce payload лучше проверять по схеме до отправки: обязательные поля на purchase/add_to_cart, массив contents не пустой, value совпадает с суммой позиций, а event_id не переиспользуется между разными действиями. Для lead-событий ключевой риск — дубли event_time и одинаковый event_id из retry-логики.

Если строите серверную отправку через sGTM, валидацию делайте до HTTP request: schema check, нормализация user fields, контроль типов данных и retry только с тем же event_id. Тогда меньше мусора в логах и выше шанс, что события будут матчиться корректно.

Серверный трекинг выигрывает не магией, а дисциплиной поля за полем: сначала схема, потом транспорт.