Огляд

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

Подія фіксує дію, наприклад покупку. Піксель надсилає події з браузера відвідувача, а Conversions API (CAPI) — з вашого сервера. Ads Manager збирає ці події в джерелі даних. Атрибуція визначає, якому оголошенню зараховується дія. Вікно атрибуції визначає, протягом якого часу після взаємодії з оголошенням дія може бути йому зарахована.

Поширені запитання

1. З чого почати?

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

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

Якщо вашою інтеграцією керує партнер, скористайтеся посібником із налаштування інтеграції з партнером із вимірювання або посібником із налаштування інтеграції з партнером із мобільного вимірювання. Щодо підключення HubSpot див. Налаштування ChatGPT Ads у HubSpot.

Якщо інтеграцію вже налаштовано, перевірте кожен етап:

• Чи було надіслано запит із подією після виконання дії?

• Чи повернув запит помилку, чи його було прийнято?

• Чи можете ви підтвердити, що потрібне джерело даних отримало подію?

• Чи було подію зараховано оголошенню у звіті кампанії?

2. Мій піксель установлено. Чому я не бачу покупок або заявок потенційних клієнтів?

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

• Перевірте назву події, ідентифікатор пікселя та сторінку або функцію зворотного виклику, яка її надсилає. Перегляд сторінки — це не завершена покупка.

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

• Перевірте консоль браузера та мережевий запит. Саме лише повідомлення менеджера тегів «спрацював» не підтверджує надсилання події. Може допомогти режим налагодження пікселя.

• Перевірте, чи не завадили запиту вибір відвідувача щодо згоди, блокування в браузері або політика безпеки вашого сайту.

• Перевірте сторінки для авторизованих користувачів, оформлення замовлення, сайти бронювання, переспрямування та вбудовані форми. Робота пікселя на цільовій сторінці не підтверджує відстеження в інших місцях.

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

3. Що робити, якщо подію відхилено, час очікування вичерпано або повернуто помилку сервера?

Збережіть код відповіді, точний текст помилки, час запиту й ідентифікатор події. Попросіть розробника перевірити формат події, ідентифікатор пікселя та ключ. Запити з подіями CAPI використовують ключ Conversions API для того самого рекламного облікового запису. Запити для налаштування, керування та звітності використовують окремий ключ Advertiser API. Не надсилайте ключі API до служби підтримки.

У пакетах CAPI одна некоректна подія може спричинити збій усього пакета.

CAPI потребує фактичного часу виконання дії у форматі Unix у мілісекундах. Час події має бути не раніше ніж 7 днів тому й не пізніше ніж через 10 хвилин від поточного моменту. Це обмеження на надсилання не пов’язане з вікном атрибуції. Не змінюйте час старої події, щоб вона пройшла перевірку.

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

Негайно з’ясуйте причину відхилення або постійного збою запитів. Орієнтовний термін появи даних у звітах — 24–48 годин — не стосується цих помилок. Вимоги до запитів наведено в посібнику Conversions API.

4. Я бачу, що подію прийнято. Чому її немає у звіті?

Прийняття події не означає, що її зараховано оголошенню. Перевірте, що саме підтверджує відповідь і чи використовувалося в запиті правильне джерело даних. У CAPI параметр validate_only зі значенням true перевіряє події, не зберігаючи їх.

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

Якщо ви не можете перевірити отримання, зверніться до служби підтримки та надайте початкову відповідь і приклад події. Повідомте, які перевірки ви виконали; з’ясовувати причину перед зверненням не потрібно.

Якщо отримання підтверджено, перейдіть до запитання 5. Не надсилайте подію повторно з новими ідентифікаторами лише тому, що звіт кампанії не змінився.

Атрибутовані конверсії можуть з’явитися приблизно через 24–48 годин, а підсумки за нещодавній період можуть змінюватися під час обробки. Це не гарантує, що кожна прийнята подія з’явиться у звіті, і не підтверджує її отримання. Див. Вимірювання результатів.

5. Події надходять. Чому кампанія досі показує нуль конверсій?

Перш ніж змінювати інтеграцію, перевірте:

• Чи підключено потрібне джерело даних до правильного облікового запису?

• Чи відповідає подія, яку ви надсилаєте, налаштуванню конверсії в кампанії? Для спеціальних подій перевірте спеціальний тип і точну назву події. Збігу відображуваної назви недостатньо.

• Чи було потрібну конверсію прив’язано до кампанії до виконання дії, яку ви перевіряєте?

• Чи передував дії клік або перегляд оголошення, що відповідає умовам атрибуції?

• Чи правильно вибрано кампанію, стовпець подій, дати та принцип визначення часу у звіті?

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

Перевіряйте браузерні та серверні події окремо. Ідентифікатор кліку або поле з даними клієнта, доступні пікселю, можуть бути відсутні в серверній події.

Вибрану ціль кампанії, оптимізованої для конверсій, не можна змінити після її створення. Щоб використати іншу ціль, створіть нову кампанію. Спеціальні події не можуть бути цілями оптимізації. Див. Кампанії, оптимізовані для конверсій.

Після усунення невідповідності в налаштуваннях перевірте нові дії, що відповідають умовам. Не припускайте, що ця зміна виправить попередні звіти. Правила зіставлення див. у статті Вимірювання конверсій.

6. Чому дані Ads Manager, нашого інструмента аналітики та CRM не збігаються?

Порівнюйте однакові дії за однаковими правилами звітності. Ваша CRM може враховувати кожну покупку, а рекламний звіт — лише покупки, зараховані відповідній платформі. Різні платформи можуть по-різному атрибутувати ту саму покупку.

В Ads Manager показник Конверсії об’єднує конверсії після кліку та відповідні конверсії після перегляду, якщо вікно звітності для конверсій після перегляду становить 1 день. Якщо вікно після перегляду становить 0 днів, враховуються лише конверсії після кліку. Під час порівняння звітів використовуйте однакове налаштування.

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

Якщо позначення джерел трафіку різняться, перевірте URL-адресу цільової сторінки та параметри відстеження, використані під час цього відвідування. Поточні налаштування кампанії можуть відрізнятися від попередніх.

Порівняйте:

• Обліковий запис, кампанію, тип події, фільтри та рівень звітності.

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

• Налаштування конверсій після кліку й після перегляду та конкретний вибраний показник або стовпець.

• Нещодавні затримки обробки, обробку дублікатів, згоду та доступні дані для зіставлення.

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

• Для вартісних показників — валюту, одиниці вимірювання та те, чи порівнюються цілі замовлення, чи окремі товари.

Для доходу порівняйте податки, доставку, знижки та збори. Переконайтеся, що браузерна й серверна копії надсилають однакову вартість замовлення. Показники Продажі за створеними замовленнями і ROAS за створеними замовленнями враховують лише атрибутовані події order_created.

Імпортовані дані про активність із GA4 містять події з усіх джерел трафіку вибраного ресурсу. Ці підсумкові показники не є конверсіями, атрибутованими кампанії. Див. Підключення Google Analytics 4 до OpenAI Ads Manager.

Для порівнянь через API зафіксуйте кінцеву точку та явно задайте параметри звітності. Якщо налаштування не вказано, воно може не збігатися з налаштуванням в Ads Manager. Звіти також можуть містити різні події: деякі охоплюють цілі кампанії, але не інші відстежувані дії. Відсутність події в одному зі звітів не доводить, що її ніколи не було отримано.

Для порівняння CSV використовуйте однакові налаштування та зберігайте експортовані файли без змін. Відомості про подання в Ads Manager див. у статті Вимірювання результатів, а про параметри API — у посібнику Звітність.

7. Чи буде покупку зараховано двічі, якщо використовувати піксель і CAPI?

Щоб одну дію не було зараховано двічі, використовуйте однакові ідентифікатор пікселя, назву події та ідентифікатор події в її браузерній і серверній копіях. Поле ідентифікатора події має назву id у CAPI та event_id у пікселі. Також використовуйте однакову назву спеціальної події з обох боків.

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

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

8. Ми використовуємо Shopify. Чи потрібна нам ще одна інтеграція?

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

Якщо ви також використовуєте власні теги, код на сторінці оформлення замовлення або серверний засіб надсилання, перевірте, чи не надсилають вони ті самі події. Конфігурації Shopify можуть використовувати різні поєднання браузерного та серверного відстеження. Див. Налаштування ChatGPT Ads для Shopify.

9. Як враховувати згоду та проводити тестування?

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

Згода на вимірювання та opt_out мають різне призначення. Параметр opt_out стосується персоналізації; він не зупиняє всі запити вимірювання. Попросіть розробника перевірити врахування згоди як у браузерній, так і в серверній інтеграціях.

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

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

10. Чи означає низька або недоступна оцінка якості подій, що відстеження не працює?

Сама по собі — ні. Якість подій оцінюється за інформацією, отриманою з джерела даних. Вона не показує, скільки конверсій було зараховано оголошенням. Лише за низькою або недоступною оцінкою не можна визначити, чи працює відстеження.

Переконайтеся, що нещодавні реальні дії фіксуються правильно, а потім з’ясуйте причину попередження. Не надсилайте зайві події чи вигадані ідентифікатори, щоб підвищити оцінку. Відомості про перевірки та терміни оновлення див. у статті Якість подій: як її зрозуміти та покращити.

11. Які відомості слід надати під час звернення до служби підтримки?

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

• Ідентифікатор рекламного облікового запису, ідентифікатор пікселя або джерело даних, а також ідентифікатори кампанії та оголошення, яких стосується проблема.

• Тип інтеграції та точну назву події, зокрема назву спеціальної події, якщо вона використовується.

• Один або два приклади ідентифікаторів наявних подій і часові позначки дій із зазначенням часового поясу.

• У разі збоїв запитів або непідтвердженого отримання: код відповіді, точний текст помилки, час запиту, повернутий ідентифікатор запиту або CF-Ray, якщо є, та тіло запиту чи фрагмент журналу з вилученими конфіденційними даними.

• У разі розбіжностей у звітах: діапазон дат, принцип визначення часу у звіті, налаштування атрибуції, вибрані стовпці, експорт у CSV та порівняння даних з однаковим охопленням.

• Відповідні знімки екрана та відомості про нещодавні зміни налаштувань, зокрема окрему сторінку оформлення замовлення чи партнерську інтеграцію.

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

Вилучіть із вкладень ключі API, заголовки авторизації, паролі, файли cookie та зайві відомості про клієнтів. Негайно повідомляйте про помилки або раптову зупинку інтеграції, яка раніше працювала. Не чекайте, доки мине термін появи даних у звітах.