Де взяти базовий код, які події описати, як перевірити їх до запуску й чому звіт ніколи не збігається з CRM на сто відсотків.
Піксель — це не перемикач «увімкнути» і не одна подія на весь сайт. Це набір сигналів, прив'язаних до конкретних кроків користувача, і помилка на будь-якому кроці зупиняє роботу всієї системи: подія не викликається, код стоїть не там, шаблон сайту оновився і обробник зник. Нижче — порядок дій від створення пікселя до читання звітів, з перевірками, які роблять до запуску кампанії, а не після першого злитого бюджету. І без обіцянок, що ви бачитимете всі сто відсотків конверсій — частину сигналів не покаже жоден інструмент.
Піксель — це фрагмент JavaScript, який завантажується на сторінках сайту й описує дії відвідувача в термінах, зрозумілих рекламній системі. Без нього TikTok бачить лише показ і клік: що людина зробила після переходу, платформа не знає. З ним з'являється другий шар даних — яка саме дія відбулась і скільки вона коштувала.
Задач рівно дві, і плутати їх не варто. Перша — вимірювання: ви бачите, скільки заявок або покупок приніс конкретний креатив. Друга — оптимізація: коли кампанія націлена на подію, система шукає людей, схожих на тих, хто вже цю подію виконав. Друга задача без першої не працює: якщо подія не передається, система не має на що орієнтуватися й тихо з'їжджає до оптимізації на кліки. Піксель створюється в Events Manager і має власний ідентифікатор, що прив'язує події до акаунта.
Вебпіксель не побачить дію в застосунку — для цього існує окремий SDK. Замовлення з телефону, з CRM або з офлайн-точки теж передають окремо. Це межа роботи пікселя, яку варто врахувати ще на етапі планування обліку.
Код живе в Events Manager: розділ вебподій, створення пікселя, далі — інструкція з підключення. Система показує саме той фрагмент, який відповідає вашому пікселю, копіювати його з чужого сайту або з форуму немає сенсу: ідентифікатор буде чужий.
<head> і на всіх сторінках сайту, включно зі сторінками подяки та формами.Якщо сайт збирається на конструкторі, код вставляють у налаштування «глобальні скрипти» або в шаблон усіх сторінок. Для перевірки достатньо відкрити вихідний код сторінки та переконатися, що фрагмент присутній, а в звіті за кілька хвилин з'явилася подія перегляду. Порядок створення й типові збої розібрані окремо — включно з випадками, коли код стоїть, але події не реєструються.
Стандартні події мають фіксовані назви, і їх варто використовувати замість власних — система вже розуміє їхній зміст. Найуживаніший набір для сайту: перегляд сторінки товару, пошук, додавання в кошик, початок оформлення, покупка, відправка форми, підписка, контакт із бізнесом. Повний перелік завжди актуальніший у самому Events Manager, ніж у будь-якій статті: назви й доступність залежать від типу акаунта та мети кампанії.
Для покупки й кошика передають суму та валюту, для товару — ідентифікатор і тип контенту, за потреби — кількість. Без суми система не зможе порахувати цінність конверсії, і ви не побачите, який товар чи сегмент дає гроші, а який лише заявки.
Власна подія потрібна там, де немає стандартного відповідника: завершений квіз, запис на консультацію, розрахунок вартості. Назва задається вами, тому є два правила гігієни: одна назва означає одну дію (не варто вішати «форма» на три різні форми без розділення параметром), і зміна змісту події після того, як вона роками використовувалась як мета оптимізації, зіпсує історію в звітах. Рідкісні власні події краще працюють для аналітики та ретаргетингу, а бюджетні рішення — на частих діях: докладніше в розділі про роботу з цільовими подіями й конверсіями.
Test Events показує події в реальному часі: натискаєте кнопку на сайті й одразу бачите, яка подія відправилась, з якими параметрами й чи прийнята вона. Це основний спосіб перевірити налаштування до запуску кампанії; для серверних подій існує окремий код тестової події, який додають на час перевірки й потім прибирають.
Порядок розбору: спершу підтвердіть, що базовий код є на сторінці, потім перевірте дію з телефона й лише тоді переходьте до обробників у коді. Більшість «зниклих» подій — це перші два пункти.
Орієнтир: перед кожним оновленням сайту проходьте основні кроки воронки в Test Events — зазвичай це займає 10–15 хвилин і ловить помилку до того, як на неї витратиться бюджет. Перевіряти показники через тиждень за звітом дорожче.
З появою App Tracking Transparency застосунки отримують доступ до даних про користувача лише за його явною згодою. Для реклами це означає: частина подій надходить із затримкою, частина — у вигляді модельної оцінки, а частина не надходить зовсім. Масштаб залежить від застосунку, країни користувача й того, скільки людей дають згоду.
Універсальної цифри втрат не існує — вона відрізняється за нішами, часткою iOS у конкретній аудиторії, географією й категорією продукту. Тому твердження на кшталт «ви втрачаєте рівно чверть даних» — чиясь оцінка, а не норма.
Що з цим робити практично: не вимикати показ на iOS-аудиторію — там реальні покупці, а облік нестабільний; тримати однакове вікно атрибуції у звітах платформи та в CRM, щоб порівнювати зіставне; дублювати ключові події з боку сервера, коли є така можливість; звіряти підсумок замовлень, а не окремі події. Розбіжність між платформою й обліком неминуча — важливо, наскільки вона стабільна від тижня до тижня.
Подія без прив'язки до каналу не має цінності для рішень: важливо не просто «була покупка», а якому показу її зарахувати. Це визначає вікно атрибуції — проміжок між взаємодією з рекламою та дією, а також те, чи зараховується конверсія після кліку, після перегляду або за обома сценаріями. Перелік доступних вікон залежить від типу кампанії — актуальний набір дивлять у налаштуваннях звіту.
Робочий підхід простий: одне вікно атрибуції для всіх звітів, UTM-мітки на всіх рівнях — кампанія, група, оголошення, і звірка з CRM за замовленнями, а не за подіями. Довідник метрик і принципи побудови звітів зібрані в розділі про аналітику й атрибуцію рекламних даних — він корисний тим, що показує, на якому етапі воронки втрачаються гроші.
<head> на всіх сторінках.Для переходу в месенджер вебпіксель не бачить, що сталося після кліку: розмова відбувається поза сайтом, тому подію «заявка» він не зафіксує. Варіанти два — вести трафік на сторінку з формою, де подія спрацьовує, або передавати конверсії через Events API з боку CRM. Такі кампанії зручніше оцінювати за кількістю звернень у CRM, а не за конверсіями в Ads Manager.
Найчастіша причина — обробник прив'язаний до селектора або теми з попередньої версії сайту. Після оновлення шаблону кнопка змінює клас, подія не викликається, хоча базовий код на місці. Друга причина — кошик працює через AJAX, і подію треба викликати після відповіді сервера. Перевіряйте через Test Events у момент натискання, а не через години за звітом.
Так, для цього є офіційний шаблон тега TikTok у галереї GTM. Це зручно, коли код треба поставити без розробника, а події прив'язати до тригерів. Обмеження теж є: якщо контейнер завантажується після базового коду або із затримкою через consent-налаштування, частина подій не встигає передатися. Перевіряйте, що тег базового пікселя стоїть на всіх сторінках, а подієві теги не дублюють код із HTML.
Менше даних — очікуваний наслідок: дозвіл на відстеження дають лише частина користувачів, решта подій доходить із затримкою або з поправкою на моделювання. Частка залежить від ніші, аудиторії й формулювання запиту на дозвіл, тому універсального відсотка для порівняння немає. Що робити: не вимикати показ на iOS-аудиторію, тримати однакове вікно атрибуції в звітах і CRM, дублювати ключові події через Events API і звіряти кількість замовлень, а не окремі події.
TikTok не публікує єдиного порогу для всіх ніш і цілей: потрібна кількість залежить від мети кампанії, географії та бюджету, а система показує поруч із подією, чи достатньо даних для вибору її як цілі оптимізації. Орієнтир — не будувати оптимізацію на події, яка трапляється кілька разів на тиждень: спершу ведіть трафік на частішу дію, а рідкісну залиште для звітності. Статус перевіряйте в Events Manager.
Якщо події вже налаштовані, але звіти не сходяться з обліком — почніть із перевірки базового коду й Test Events, а не з нової кампанії.
Перевірити налаштування пікселяДжерела: довідкові матеріали TikTok Business Help Center щодо пікселя, подій і Test Events; офіційна документація TikTok Pixel та Events API; документація Apple щодо запиту на відстеження (App Tracking Transparency). Орієнтири в тексті позначені словом «орієнтир» і залежать від ніші, бюджету, географії та якості рекламних матеріалів. Гарантій щодо обсягу даних або результату кампаній немає: частина сигналів не передається з технічних причин, і жодне налаштування не дає стовідсоткової збіжності платформи з CRM. Матеріал описує загальні принципи роботи з TikTok Pixel і не є фінансовою чи юридичною консультацією.