- Patryk Marek
- News
- 0 подобається
- 75 погляди
- 0 коментарі
Якщо події з PrestaShop не відповідають товарам у каталозі Meta, порівняйте повний ідентифікатор пропозиції зі значенням, що надсилається в content_ids. Важливі префікс, роздільник і номер комбінації. Для інтеграції ідентифікатори 812, ps_812-41 і ps_812_41 означають різні рядки, хоча людина може пов’язувати їх з тією самою карткою товару.

Цей посібник допомагає перевірити взаємодію товарного фіду та Pixel. Приклади є демонстраційними, без даних клієнтів. Вони не є знімком з рекламного акаунта і не підтверджують результати кампанії.
Каталог, Pixel і Conversions API виконують різні завдання
Каталог містить пропозиції: ідентифікатори, назви, зображення, ціни та наявність. Фід є одним зі способів передавання цих даних. Pixel надсилає події з браузера, наприклад перегляд товару або додавання до кошика. Conversions API дає змогу надсилати події з боку сервера.
Коректно завантажений каталог не доводить, що події посилаються на правильні пропозиції. Наявність події покупки, своєю чергою, не доводить, що кожен товар із цієї покупки має відповідність у каталозі. Спочатку визначте, яку частину з’єднання ви діагностуєте.
Також перевірте, чи переглядаєте правильний каталог і правильне джерело подій. За наявності кількох магазинів, старого Pixel або тестового фіду можна порівнювати технічно коректні дані, що походять із різних конфігурацій.
Приклад: один товар, дві комбінації
Припустімо, товар має ID 812 і комбінації 41 та 42. Фід експортує варіанти як окремі пропозиції з префіксом ps_ і дефісом. Отже, для першої комбінації ідентифікатор має вигляд ps_812-41.
| Місце | Комбінація 41 | Комбінація 42 | Що ви порівнюєте |
|---|---|---|---|
| PrestaShop | Товар 812, комбінація 41. | Товар 812, комбінація 42. | Ідентичність товару та вибраного варіанта. |
Фід: g:id | ps_812-41 | ps_812-42 | Ідентифікатор конкретної пропозиції в каталозі. |
Подія: content_ids | ["ps_812-41"] | ["ps_812-42"] | Чи вказує вона на пропозицію, що відповідає дії користувача. |
| Група в демонстраційному фіді | 812 | 812 | Спільну групу варіантів; вона не замінює автоматично ID пропозиції. |
Найпростіша перевірка полягає в копіюванні значень з обробленої пропозиції та події у два рядки. Порівняйте їх символ за символом. Не видаляйте «зайвий» префікс, доки не з’ясуєте, на що посилаються інші інтеграції.
Що перевірено в модулях PrestaDev?
У коді Facebook Pixel Pro 1.4.5 доступний вибір способу побудови ID та необов’язкового префікса. Один зі шляхів формує ID товару, поєднаний з ID комбінації через дефіс, інший використовує підкреслення. Також існують режими, що базуються на інших полях. Це конфігурація, яку потрібно порівнювати з фактичним експортом, а не вибирати лише за назвою.
Перевірений код фіду Meta 2.9.2 під час експорту комбінацій записує g:id у вигляді префікс + ID товару + дефіс + ID комбінації. Для цього налаштування варіант ps_812_41, що надсилається Pixel, не буде ідентичним до ps_812-41 у фіді. У цьому шляху фід записує спільний g:item_group_id як ID товару без префікса.
Це підтвердження способу побудови даних у зазначених версіях коду, а не доказ відповідності в конкретному акаунті Meta. Після зміни налаштувань усе одно потрібно перевірити згенерований файл, імпорт каталогу та реальну подію.
content_ids і content_type мають бути узгодженими
content_ids містить ідентифікатори, пов’язані з подією. content_type визначає спосіб посилання на товари або їхні групи. Не слід замінювати product на product_group лише для того, щоб зникло повідомлення: це змінює значення ідентифікаторів, на які посилається подія.
У розглянутому прикладі ми вибираємо конкретну пропозицію варіанта і content_type: "product". Спрощений набір даних для перегляду варіанта виглядає так:
{
"content_ids": ["ps_812-41"],
"content_type": "product",
"value": 129.00,
"currency": "PLN"
}
Це фрагмент даних демонстраційної події, а не повний код впровадження чи запит до API. Типи полів content_ids, content_type, value і currency можна перевірити в офіційному SDK Meta — CustomData. Під час діагностики конкретного акаунта також перевірте актуальні повідомлення Менеджера подій.
Після зміни варіанта виконайте нову спробу
Правильного ID під час першого відкриття сторінки недостатньо. Тема може змінювати варіант без перезавантаження документа. Інтеграція подій повинна використовувати дані, що відповідають поточній дії, замість того щоб залишатися на комбінації за замовчуванням.
- Виберіть товар щонайменше з двома комбінаціями, наявними у фіді.
- Запишіть їхні повні ідентифікатори з файлу та з каталогу після імпорту.
- Відкрийте товар у контрольованій тестовій сесії з правильними налаштуваннями згод.
- Перевірте дані події, що стосується першого варіанта.
- Змініть комбінацію і додайте вибраний варіант до кошика.
- Порівняйте ID, кількість, значення та валюту події з поточним кошиком.
- Перевірте, чи ту саму дію додатково не надсилає друга інсталяція Pixel, наприклад через інший модуль або менеджер тегів.
Не тлумачте відсутність події як помилку каталогу, доки не перевірите згоди, блокування скриптів і конфігурацію джерела подій. Передавання даних через сервер також потребує правильної конфігурації приватності; CAPI не слід розглядати як спосіб обходу рішення користувача.
Значення і валюта — це окрема перевірка
Ідентичний ID не підтверджує правильну суму. Для події товару перевірте ціну вибраної комбінації, а для покупки — узгоджене визначення значення всього замовлення. Не порівнюйте одну одиницю із сумою кошика або суму без ПДВ із сумою з ПДВ, не з’ясувавши, як працює впровадження.
Валюта має відповідати переданому значенню. Для магазину з кількома валютами виконайте окрему спробу після її зміни. Якщо дані походять із замовлення, порівнюйте їх із збереженим замовленням, а не з поточною каталожною ціною, зчитаною пізніше.
Відповідність товару та дедуплікація покупки
Дедуплікація розпізнає дві копії тієї самої події, надіслані з браузера і сервера. Вона не призначена для об’єднання варіантів товару. В офіційному SDK Meta описано, що для відповідних подій браузерний eventID має збігатися із серверним event_id, а в процесі також використовується назва події. Джерело: Meta — опис Event і setEventId.
| Ідентифікатор | Демонстраційний приклад | Що він має розпізнавати |
|---|---|---|
content_ids | ["ps_812-41"] | Товар або варіант, пов’язаний із дією. |
eventID / event_id | purchase_demo_1001 | Одну конкретну подію покупки, надіслану двома каналами. |
Постійний event_id, рівний ID товару, був би неправильним рішенням для різних покупок цього товару. Водночас узгоджені ідентифікатори події не виправлять помилковий content_ids. Перевіряйте ці дві речі окремо. Якщо ви також аналізуєте GA4, скористайтеся наявним посібником щодо вимірювання покупок.
З чого почати покращення інтеграції?
Виберіть один товар і збережіть три дані: ID у магазині, ID, імпортований до каталогу, і ID з події. Визначте формат, змініть правильне налаштування, оновіть потрібне джерело і повторіть спробу. Не змінюйте одночасно префікс, роздільник, спосіб експорту варіантів і кілька інсталяцій Pixel — це ускладнить визначення того, яке саме виправлення розв’язало проблему.
Перевірте відповідність формату ID в обох інтеграціях: Facebook Pixel Pro та XML-фід товарів для Meta. Їхня конфігурація має випливати з тієї самої моделі каталогу. Правильна відповідність є елементом якості даних, а не гарантією рентабельності реклами.
Змістову перевірку виконано: 13 вересня 2026 року. Перевірено код Facebook Pixel Pro 1.4.5, фіду Meta 2.9.2, а також публічні визначення в офіційному SDK Meta. Публікація або тестова покупка в рекламному акаунті клієнта не виконувалися.
Коментарі (0)