Meta дедуплікує відповідні події веб-переглядача та сервера, якщо вони використовують ту саму назву події та ідентифікатор події. Згенеруйте ідентифікатор один раз під час ділової події, передайте його через обидва шляхи доставки та ніколи не створюйте непов’язані випадкові ідентифікатори в кожному тегу.
Що на практиці означає дедуплікація події meta capi за допомогою event_id
Для покупок вартість на основі замовлення є стабільною та піддається перевірці. Для подій перед покупкою створіть ідентифікатор до відправки браузера або сервера.
Правильний дизайн починається з бізнес-результату та даних, необхідних для його вимірювання. Ідентифікатори подій мають ідентифікувати один випадок, а не одного користувача. Повторне використання ідентифікатора для окремих покупок може пригнічувати законні конверсії.
Як повинен працювати потік даних
Збіги ідентифікаторів не виправляють суперечливі назви подій, мітки часу, валюти чи значення. Розглядайте обидва корисні навантаження як представлення однієї канонічної події.
Задокументуйте джерело, назву події, стабільні ідентифікатори, стан згоди, перетворення та відповідь призначення. Цей запис робить реалізацію придатною для перевірки та запобігає перетворенню налаштування платформи в недокументовану бізнес-логіку.
Ризики та типові помилки впровадження
Використовуйте менеджер подій Meta, щоб перевіряти охоплення браузера/сервера, повторювати попередження та отримані параметри замість того, щоб покладатися лише на попередній перегляд GTM.
Найдорожчі збої мовчазні: здається, що теги спрацьовують, а корисні навантаження дублюються, відхиляються, позбавляються ідентифікаторів або надсилаються без очікуваного стану згоди. Перевірте весь ланцюжок і збережіть докази з вихідної системи та цільової діагностики.
Вимірювання, конфіденційність і постійне право власності
Призначте власника для контракту про подію, веб-контейнера, серверного контейнера та кожної інтеграції постачальника. Визначте попередження, перегляд змін і шлях відкату, перш ніж налаштування стане залежним від виробництва.
Елементи керування конфіденційністю належать до архітектури. Мінімізуйте корисне навантаження, обмежте доступ, утримуйте документи та перевіряйте, що насправді отримує кожен пункт призначення. Обробка на стороні сервера забезпечує контроль лише тоді, коли команда активно її налаштовує та перевіряє.
Перевірте результат, а не лише конфігурацію
Зміна інтерфейсів платформи та поведінки браузера. Підтвердьте поточні вимоги в пов’язаній первинній документації, протестуйте репрезентативні реальні подорожі та зверніться за кваліфікованою порадою щодо конфіденційності для юрисдикцій, у яких ви працюєте.
Meta CAPI Дедуплікація подій за допомогою event_id: контрольний список реалізації
Використовуйте цю послідовність, щоб спланувати нову реалізацію або переглянути існуючу.
- 01
Дайте визначення канонічної господарської події
Запишіть очікуваний вхід, вихід, власника та критерій прийняття перед зміною тегів.
- 02
Створіть стабільний ідентифікатор події
Налаштуйте цей етап із стабільним іменуванням і мінімальними даними, необхідними для його задокументованого призначення.
- 03
Приєднайте його до події Pixel
Зберігайте ідентифікатор події, стан згоди та посилання на вихідну систему на всьому шляху доставки.
- 04
Передайте його в контейнер сервера
Використовуйте інструменти попереднього перегляду та перевірку мережі браузера, щоб порівняти спостережуване корисне навантаження з контрактом на подію.
- 05
Зіставте його в тег CAPI
Перевірте реакцію призначення та діагностику; локально запущений тег не є доказом успішної обробки.
- 06
Повторні спроби тестування та дублікати подання
Запишіть результати, звіртеся з правдивим джерелом і заплануйте повторне тестування після істотних змін платформи.
Побудуйте систему вимірювання, яку ви можете пояснити
Meta CAPI Дедуплікація подій із event_id найкраще працює, коли право власності на подію, ідентифікаційні дані, згода та призначення зіставлення явні. Реалізація має бути зрозумілою без зворотного проектування колекції тегів.
Почніть з одного критичного перетворення, перевірте його до кінця та розширте лише після узгодження корисного навантаження, діагностики та узгодження вихідної системи.
Meta CAPI Дедуплікація подій за допомогою event_id: поширені запитання
Чи можу я використовувати ідентифікатор замовлення як event_id?
Так для покупки, коли ідентифікатор замовлення доступний для обох шляхів і однозначно ідентифікує цю транзакцію.
Чому події все ще дублюються?
Переконайтеся, що корисні навантаження браузера та сервера використовують однакові ім’я події та ідентифікатор події та надходять у вікно обробки, яке підтримується платформою.
Як перевірити цю реалізацію?
Перевірте прийняту та відхилену згоду, нові та повторні сеанси, варіанти веб-переглядача та серверної частини, дублікати подання та остаточну відповідь від кожного пункту призначення.
Чи гарантує відстеження на стороні сервера більше конверсій?
Ні. Це може покращити контроль і доставку сигналу, але результати залежать від якості джерела, згоди, ідентифікаторів, правил платформи та правильного впровадження.