Помилки Facebook conversion API і як їх виправити

Налаштування Facebook conversion API може вас заплутати. Але після того, як ви зробили колосальну роботу з переміщення відстеження FB на сервер і сподіваєтеся, що все гаразд, ви можете увійти до свого менеджера подій наступного дня і побачити червоні та жовті попередження про події, надіслані з сервера.

Я багато разів стикався з цією проблемою під час налаштування FB CAPI для клієнтів. Тому я вирішив створити статтю з деякими корисними порадами. У цьому блозі я опишу найпопулярніші помилки та попередження Facebook conversion API. Крім того, поділюсь деякими порадами, як їх виправити.

Як перевірити, чи є помилки в Facebook pixel або Conversion APIСкопіюйте посилання на цей розділ

Інструмент тестування подій Facebook (Facebook's Events Testing Tool) – це новий потужний інструмент, який дозволяє налагоджувати та вирішувати проблеми з вашими пікселями FB або подіями сервера. Якщо є помилки, вони відображатимуться на вкладці «Діагностика» на панелі інструментів, щоб ви могли детальніше їх переглянути.

Помилки, позначені червоним кольором, зазвичай вимагають вашої швидкої реакції, і їх слід негайно виправити. Жовті помилки є некритичними попередженнями, на які слід звернути увагу та врешті-решт розглянути.

Facebook дозволяє позначати проблеми як вирішені або ігнорувати їх. Якщо ви позначите помилку як вирішену, і ця помилка повторюється, Facebook відобразить її знову через 3 дні. Для порівняння, ігноровані проблеми потрапляють до розділу Ігноровані та залишаються там.

Коли ви лагодите будь-які проблеми з відстеженням FB, я пропоную позначити їх як вирішені. Таким чином, ви повідомите Facebook про те, що проблеми вирішено, і ви повідомите платформу, якщо ці проблеми повторяться.

Які є найпопулярніші помилки Facebook pixel та conversion API і як їх виправити?Скопіюйте посилання на цей розділ

1. New Domains Sending DataСкопіюйте посилання на цей розділ

Ви можете побачити всі домени, які надсилають дані на ваш піксель Facebook. Якщо FB помітить трафік з нового субдомену або домену, платформа надішле вам це попередження. Ви можете занести домени в білий або чорний список. За допомогою цієї функції ви можете блокувати трафік зі своїх тестових сайтів або технічних URL-адрес.

Швидше за все, ви також побачите трафік з gtm-msr.appspot.com. Це може статися, коли ви запускаєте контейнер для налагодження/публікування або користувачі приходять на ваш сайт із вимкненим js (деякі боти).

Щоб створити списки дозволів або блокування домену (allow or block lists), відкрийте events tool у Business Manager -> Натисніть settings -> Прокрутіть униз до Traffic Permissions.

2. Event Missing Some Deduplication ParametersСкопіюйте посилання на цей розділ

Це друга за популярністю помилка Facebook CAPI з мого досвіду. Ця помилка означає, що ви не надсилаєте деякі ключі дедуплікації для подій сервера. Facebook використовує такі ключі дедуплікації: event name, event ID, _fbp та external ID. 

З мого досвіду, параметри ідентифікатора події спричиняють цю помилку в 80% випадків. Перевірте, чи надсилаєте ви ідентифікатор події для пікселя Facebook і Facebook conversion API. Цей ідентифікатор події має бути однаковим для події браузера та сервера. У цьому випадку FB побачить ту саму назву події та ідентифікатор події та почне дедуплікацію.

Наприклад, для подій PageView надішліть той самий ідентифікатор події та назву події з пікселя Facebook і FB CAPI.

Щоб перевірити ідентифікатор події, відкрийте інструмент тестування подій Facebook (Facebook event testing tool). Якщо все налаштовано правильно, ви повинні побачити щось схоже на скріншот. Таким чином FB показує, що він записав події PageView як з браузера, так і з сервера. Ці події мали однаковий ідентифікатор події. Тому вони обробляли події браузера та дедуплікували події сервера.

Але може бути й інша ситуація, коли ви бачите події браузера та сервера, які запускаються випадковим чином. У цьому випадку перевірте ідентифікатор події FB. Швидше за все, ідентифікатори подій не ідентичні. Говорячи про це, ви можете використовувати нашу кастомну змінну (variable) для веб-контейнера, щоб налаштувати ідентифікатор події Facebook.

У нас також є стаття про те, як налаштувати дедуплікацію подій у Facebook.

Іноді ця помилка може бути викликана тим, що ви не видалили тестовий ідентифікатор Facebook і не опублікували теги FB CAPI у робочому середовищі. Я рекомендую налаштувати ідентифікатор тесту як змінну таблиці пошуку, яка працює лише в режимі налагодження, щоб вирішити цю проблему.

3. Server Sending Invalid Match Key Parameters for PageView EventСкопіюйте посилання на цей розділ

Тут Facebook хоче повідомити вас, що значення, які ви надсилаєте із сервера, не є унікальними або відформатовані неправильно. Наприклад, ви можете надіслати user IP, який містить символи, а не тільки цифри. Або, можливо, ви просто вибрали неправильну змінну (variable), наприклад надіслали номер телефону в поле електронної пошти.

Щоб перевірити, що не так, відкрийте режим попереднього перегляду Google Tag Manager на стороні сервера і веб-контейнера (звичайно, якщо ви використовували GTM для налаштування Facebook conversion API). Ви повинні побачити, які параметри користувача були надіслані до Facebook і чи були вони відформатовані правильно. Перевірте подію, натисніть на тег у режимі налагодження та виберіть значення.

Ця помилка також може означати, що ви, можливо, забули включити параметр або він неправильно відформатований.

Наприклад, у мене був клієнт, який хотів надіслати країну користувача, місто на основі IP-адреси. Facebook очікує побачити фактичні адреси користувачів, які вони вводять на сайті, а не ті, які ви автоматично витягли з IP-адреси. Це налаштування також надіслало помилку щодо недійсних параметрів ключа.

Або, можливо, ви намагалися читерити та надіслати одне й те саме ім’я користувача для всіх подій, щоб підвищити якість.

4. Potentially Violating Personal Data Sent to FacebookСкопіюйте посилання на цей розділ

Ця помилка зазвичай стосується подій браузера і означає, що Facebook виявив дані користувача в URL-адресі. Деякі CMS та інші інструменти, як-от Calendly або PayPal, надсилають дані користувача в URL-адресі після того, як вони зареєструвалися або зробили покупку.

Цю помилку важко виправити, і це завдання ваших розробників. Вони повинні покращити параметри запиту URL-адреси та видалити всю інформацію про користувача з URL-адреси. Крім того, ви можете дотримуватись інструкцій із цієї публікації GitHub і спробувати вирішити проблему всередині GTM. Інший спосіб – переключитися лише на відстеження Facebook на стороні сервера. Таким чином ви можете змінити URL-адресу, перш ніж надсилати її на Facebook.

5. Increase event match QualityСкопіюйте посилання на цей розділ

Для кожної події на сервері, яку ви надсилаєте на FB, буде оцінка якості відповідності події. Ця оцінка залежить від кількості даних користувачів, які ви надсилаєте у FB.

Якщо ви використовуєте спеціальний субдомен для свого сервера тегів, до FB CAPI надсилаються лише IP-адреса користувача, ідентифікатор браузера, _fbp та _fbc. Якщо ви надсилаєте лише ці параметри користувача, якість відповідності буде приблизно 4 з 10.

Щоб мати високу оцінку якості, дуже важливо надіслати якомога більше параметрів. FB використовує ці дані, щоб зіставити користувачів на вашому сайті з тими, які є в їхній базі даних. Але перш ніж це зробити, вам слід перевірити, чи відповідає відправка даних користувача у FB правилам політики конфіденційності, зазначеним на вашому сайті, та іншим нормам. Але технічно добре надсилати більше параметрів. Це означає, що дані про аудиторію та конверсії будуть точнішими, алгоритми Facebook матимуть точніші дані про ваших користувачів, а кампанії будуть ефективніші.

Як можна підвищити показник якості матчу події? Відповідь проста: потрібно надіслати більше даних користувача. Але реалізація залишається складним процесом. Ось як це працює: я почну з перевірки, чи реалізовано рівень даних на вашому сайті та чи є всі дані користувача. Наприклад, якщо користувач може увійти на ваш сайт, вам потрібно перевірити, чи дані користувача надсилаються на рівень даних (data layer), коли користувачі входять в систему.

Якщо рівень даних не реалізовано, призначте своїм розробникам це завдання.

Після цього переконайтеся, що ви передали всі параметри користувача з Інтернету в серверний контейнер.

Ще одна річ, яка допоможе вам підвищити якість відповідності, — це нова функція тегу даних. Ми додали можливість зберігати дані користувача. Наприклад, якщо користувач надіслав контактну форму на сайті, ви можете використовувати тег даних, щоб зберігати дані користувача в локальному сховищі, а потім використовувати їх на інших сторінках. Детальніше про цю функцію можна прочитати тут.

6. Same Event ID Received for Many Event InstancesСкопіюйте посилання на цей розділ

Якщо ви відстежуєте події Facebook як із браузера, так і з сервера, Facebook вимагає від вас надсилати унікальний ідентифікатор події для кожної події. Для відповідних подій назва події пікселя Facebook має збігатися з назвою події сервера. Те саме для ідентифікатора події, ті самі події з пікселя FB мають відповідати подіям сервера FB. Саме тоді відбувається дедуплікація.

Ця помилка виникає, коли ви надсилаєте той самий ідентифікатор події для багатьох подій. Наприклад, користувач перейшов на сторінку продукту. Це означає, що на цій сторінці повинні запускатися дві події: PageView і ViewContent. Ви повинні надіслати унікальний ідентифікатор події для кожної з подій. Це означає, що події та ідентифікатори подій у FB мають виглядати так:

Незважаючи на те, що ці події запускаються на одній сторінці та можуть використовувати той самий активатор у веб- та серверному контейнері Google Tag Manager, вам слід надіслати унікальний ідентифікатор події для обох.

Той самий ідентифікатор події, отриманий для багатьох екземплярів події, відбудеться, якщо у вас буде така ситуація:

У цьому прикладі ми надсилаємо eventID 69 для подій PageView і ViewContent. Але Facebook очікує побачити унікальний eventID для цих двох подій.

Рішення: додайте ідентифікатор тесту Facebook, відкрийте режим попереднього перегляду веб- та серверних контейнерів і перевірте налаштування. Після того, як ви дізнаєтеся, коли виникає ця помилка, ми можемо зробити більше, щоб вирішити проблему.

Ми створили кастомну змінну, яка генерує унікальний ідентифікатор події. Я пропоную використовувати цю змінну (variable) для налаштування дедуплікації подій FB. Ви можете додати ім’я події до цієї змінної, щоб переконатися, що eventID є унікальним. У цьому випадку, навіть якщо ваші події використовуватимуть той самий тригер, eventID буде унікальним, оскільки він складається з event_name_eventID. Ви можете прочитати більше про дедуплікацію подій Facebook у цій статті.

ВисновокСкопіюйте посилання на цей розділ

Налаштування Facebook conversion API може здатися складним, а іноді й заплутаним. Але це варте часу та зусиль. Після того, як ви виконаєте всю важку роботу з перенесення відстеження FB на сервер, якість відстеження та аудиторія покращиться.

Однак ви можете зіткнутися з деякими проблемами, якщо в цьому новому процесі інтеграції є помилки. Простіше кажучи, ви можете побачити червоні та жовті попередження в менеджері подій.

Хороша новина полягає в тому, що більшість цих проблем не такі складні, як може здатися, і їх не дорого виправити. Сподіваюся, ця стаття допоможе вам розібратися з найпоширенішими помилками та попередженнями Facebook conversion API.