Интернет-магазин кофе в Алматы из уроков про шлюз Conversions API и Meta Conversions API запускает рекламу в TikTok: короткие ролики о том, как варить кофе дома (магазин и цифры в уроке условные). Разработчик, который уже отправляет оплаченные заказы из CRM в Meta, получает задачу сделать то же для TikTok. Первая мысль - скопировать код и поменять адрес. Логика действительно та же, но имена полей, хеш телефона и место ключа в коде пикселя у TikTok свои, и при копировании ломается именно это.
O77: оформление и полная оплата
Кофемашина за 240 000 ₸; одна покупка после полной оплаты
Пятница, 9 октября
Оформление и предоплата 50 000 ₸
Пиксель отправляет CourierOrder
Понедельник, 12 октября, 15:00
Курьер принял доплату через Kaspi QR
CRM отмечает полную оплату
Серверное событие
Purchase на 240 000 ₸
Браузерной копии покупки нет
Магазин выбрал одну покупку на полную сумму, когда заказ оплачен целиком.
Что такое TikTok Events API
TikTok Events API (в русском интерфейсе «API событий») - серверный канал в TikTok. Ваш сервер отправляет события POST-запросом на https://business-api.tiktok.com/open_api/v1.3/event/track/ с токеном доступа, без участия браузера. Пиксель TikTok работает на странице и видит только то, что случилось, пока она открыта.
Для сайтов TikTok советует ставить Events API вместе с пикселем, а не вместо него (об Events API). TikTok объясняет это тем, что пиксель теряет часть событий из-за сбоев связи и особенностей браузеров, а сервер их восполняет. У магазина есть и вторая причина: оплату курьеру через несколько дней после заказа браузер не видит вовсе.
Пиксель создают в TikTok Ads Manager: «Инструменты» → «Менеджер событий» → «Подключить источник данных» → «Веб-сайт», затем партнёрская интеграция или ручная настройка (настройка и проверка пикселя). Токен доступа для Events API генерируют в настройках пикселя (руководство по Events API для сайта). Хранят его только на сервере.
Какие события отправлять
TikTok различает регистр: purchase и Purchase для него разные события. Поэтому имя копируют из списка стандартных событий буква в букву (поддерживаемые события). Для магазина кофе план такой:
| Что произошло | Событие TikTok | Кто отправляет |
|---|---|---|
| Открыл карточку кофе | ViewContent | пиксель |
| Добавил в корзину | AddToCart | пиксель |
| Начал оформление | InitiateCheckout | пиксель |
| Оплатил картой на сайте | Purchase | пиксель и сервер, с одним event_id |
| Оформил заказ с оплатой курьеру | CourierOrder, своё событие | пиксель |
| Заплатил курьеру | Purchase | только сервер |
CourierOrder - то же собственное событие, что магазин завёл для Meta в уроке про шлюз. Свои события TikTok показывает в отчётах и использует для аудиторий, но оптимизировать кампанию на них нельзя (собственные события). Для оформленного, но не оплаченного заказа у TikTok есть стандартное PlaceAnOrder, но его выводят из употребления: поддержка до 2027 года, и для новых настроек TikTok его не советует (обновлённые стандартные события).
В той же статье TikTok объявил два переименования: CompletePayment стал Purchase, а SubmitForm стал Lead. Старые имена продолжают работать, TikTok сам переводит их в новые, а в новом пикселе советует писать новые. Справочный центр в списке стандартных событий до сих пор подписывает форму как SubmitForm (стандартные события), а документация Events API называет её Lead. Если вы собираете лиды, а не продажи, берите Lead.
Заказ O42 и заказ O77
Покупка в магазине - полная оплата заказа, и это правило одно для Meta и TikTok. Разберём два заказа.
O42 на 15 000 ₸ оплачен картой на сайте. Покупатель видит страницу «Спасибо», и пиксель отправляет Purchase. Через минуту CRM ставит заказу статус «оплачен», и сервер отправляет тот же Purchase. Две копии одной покупки, их нужно склеить.
O77 - кофемашина за 240 000 ₸: 50 000 ₸ предоплаты на сайте, остальное курьеру при получении. Из двух вариантов урока про Conversions API магазин выбрал первый: одна покупка на полную сумму, когда заказ оплачен целиком. Для TikTok правило то же. В пятницу, 9 октября, при оформлении пиксель отправил CourierOrder. В понедельник, 12 октября, в 15:00 курьер принял доплату через Kaspi QR, CRM перевела заказ в «оплачен», и сервер отправил Purchase на 240 000 ₸. Браузерной копии у этой покупки нет и не должно быть: страницу заказа покупатель закрыл ещё в пятницу.
Дедупликация: event и event_id
TikTok склеивает копии, у которых совпадают три вещи: пиксель, имя события (event) и event_id. Первую полученную копию он оставляет, а следующие с теми же ключами отбрасывает, если они пришли в течение 48 часов. Если копия пришла в первые 5 минут, TikTok ещё и переносит из неё недостающие данные в первую, например email (дедупликация событий). Разные события через пиксель и сервер склеивать не нужно: AddToCart из браузера и Purchase с сервера - не копии друг друга (о дедупликации).
В пикселе TikTok event_id передают третьим аргументом:
У Meta ключ стоит в четвёртом аргументе и называется eventID. Разработчик, который переносит код по памяти, легко отправит в TikTok объект с ключом не в том месте. Ключом служит номер заказа, а не ID клиента, и повтор после тайм-аута идёт с тем же ключом, по тем же причинам, что и в Meta Conversions API. Для TikTok всё то же самое.
Без event_id TikTok пробует склеить копии по cookie _ttp, но только в окне 5 минут и только отбрасывая серверную копию. Серверный Purchase, пришедший через полчаса после браузерного, такую склейку не пройдёт, так что на неё не рассчитывайте.
Запрос с сервера
Вот серверная отправка заказа O77:
event_time - момент доплаты курьеру в Unix-секундах по UTC: 12 октября, 10:00 UTC, то есть 15:00 по Алматы. event_id - номер заказа, как и в Meta. Отличия от запроса в Meta видны сразу: event вместо event_name, user вместо user_data, properties вместо custom_data, а пиксель указан в теле запроса. В одном запросе можно отправить до 1 000 событий, но TikTok советует отправлять каждое сразу, без накопления.
Хеширование и данные для сопоставления
Чтобы связать покупку с рекламой, TikTok сопоставляет её с пользователем по нескольким ключам (сопоставление в Events API):
ttclid- идентификатор клика, который TikTok добавляет к адресу страницы при переходе с рекламы. Действует столько же, сколько окно атрибуции по кликам в настройках атрибуции.ttp- значение cookie_ttp, которую ставит пиксель, если в его настройках включены собственные cookies.email,phoneиexternal_id- только хешем SHA-256.ipиuser_agent- без хеширования. Пиксель передаёт их сам, а в Events API их нужно добавить вручную.
Правила нормализации (руководство по Events API для сайта): у email убрать пробелы по краям и перевести в нижний регистр, телефон привести к формату E.164 с плюсом и кодом страны, и только потом хешировать. Email aigerim@example.com даёт тот же хеш, что ушёл в Meta. С телефоном иначе: Meta просит только цифры, 77011234567, а TikTok ждёт +77011234567, и хеши у этих строк совершенно разные. Сравнительная таблица правил Meta, Google и TikTok есть в уроке про хеширование контактов.
Оплата курьеру приходит через несколько дней после заказа, и в момент отправки у сервера нет ни браузера, ни cookie. Поэтому ttclid, _ttp, IP и user agent записывают в заказ при оформлении, как _fbp и _fbc для Meta. IP сервера вместо IP покупателя подставлять нельзя: все покупки окажутся сделанными с одного устройства. Отказ от рекламных cookies останавливает и эту отправку.
В настройках пикселя TikTok советует включить собственные cookies и автоматическое расширенное сопоставление, Automatic Advanced Matching (руководство по Events API для сайта). Без первого не будет _ttp. Второе позволяет пикселю самому находить email и телефон в полях оформления заказа и отправлять их хешем, прямо из браузера (автоматическое расширенное сопоставление).
Проверка: тестовые события и счётчики
До запуска отправьте O42 в тестовом режиме (проверка настройки Events API):
- В Менеджере событий откройте пиксель и вкладку «Тестовые события».
- В разделе для серверных событий скопируйте тестовый код.
- Добавьте в тело запроса поле
test_event_codeс этим кодом и отправьте его. - Найдите событие в активности тестовых событий: ошибки в запросе TikTok покажет там же.
Перед запуском в рабочем режиме поле test_event_code из запросов убирают.
После запуска на странице пикселя видно, сколько событий пришло только из браузера, только с сервера и из обоих источников (мониторинг в Менеджере событий). Событие, пришедшее по обоим каналам, там считается один раз (дедупликация событий). Возьмём неделю из урока про шлюз, те же 140 заказов, но с исправленным пикселем: 112 оплачены картой на сайте, 28 оформлены с оплатой курьеру, 21 из них оплачен, 7 отказались у двери.
| Событие | Сколько должно быть за неделю |
|---|---|
Purchase всего | 133 |
Purchase только из браузера | 0 |
CourierOrder | 28 |
Покупок 112 + 21 = 133, и все они должны прийти с сервера. Если кто-то из покупателей отказался от рекламных cookies, вычтите его заказы: их не отправляет ни пиксель, ни сервер. Часть карточных оплат может оказаться в «только с сервера»: у покупателя стоял блокировщик или он закрыл вкладку до «Спасибо», ради этого сервер и нужен. А вот Purchase только из браузера означает, что сервер какую-то оплату не отправил: ищите её в очереди отправки. Если же покупок больше 133, копии не склеились, и первым делом сравните event_id в пикселе и на сервере.
Партнёрская интеграция, GTM или свой сервер
TikTok предлагает три пути: интеграцию с платформой магазина, интеграцию через партнёра по данным и прямую интеграцию по API (партнёрские интеграции).
- Платформа магазина. Shopify, WooCommerce, Wix, OpenCart, PrestaShop и ещё несколько платформ подключают пиксель и Events API без кода. Для WordPress без WooCommerce в списке только пиксель. Этого хватает, если все покупки оплачиваются на сайте и платформа знает их статус.
- Google Tag Manager и другие партнёры по данным. Через GTM ставят и пиксель, и Events API, а Stape есть в списке TikTok среди компаний, которые помогают с настройкой. Если в серверный контейнер GTM пишет только браузер, оплату курьеру он не увидит, как не видел её шлюз Meta.
- Свой сервер. Нужен, когда факт рождается в CRM или бэкенде. Это случай магазина кофе: оплаты курьеру видит только CRM. Разработчик добавляет TikTok вторым получателем в ту же очередь отправки, что уже работает для Meta, по схеме из урока про S2S-трекинг оплаты.
Пути можно сочетать, но тогда перед запуском выпишите всех отправителей Purchase в пиксель TikTok. Если плагин магазина уже шлёт серверный Purchase, а ваш сервер отправит свой с другим event_id, покупка задвоится.
Задание: Events API на своём проекте
Выполнено 0 из 7
Вопрос для проверки. Разработчик взял функцию хеширования из кода для Meta и отправляет в TikTok тот же хеш телефона. Запросы проходят без ошибок. Что не так?
Хеш обратно в номер не превращается, и TikTok не может понять, что номер перед хешированием записали без плюса. Поэтому ошибки не будет. Но TikTok ищет совпадение с номерами в формате E.164, и хеш от 77011234567 не совпадёт ни с одним. Покупки по-прежнему приходят, только сопоставляются по email, ttclid и _ttp, а телефон не помогает ни разу. Найти такую ошибку можно только в коде или прогнав тестовый номер через функцию и сравнив хеш с таблицей в уроке про хеширование. Исправление в одну строку: для TikTok перед хешированием добавить к номеру плюс.
Видео: подключение Events API
Инструкция Stape на английском: настройка через серверный GTM. Имена событий перед повторением сверьте со списком выше.