Огляд
Скористайтеся цим посібником, якщо події відсутні, запити завершуються помилками або дані Ads Manager не збігаються з вашими обліковими даними. Почніть з однієї завершеної покупки, надісланої заявки або іншої дії. Зафіксуйте, що й коли сталося, а потім виберіть відповідне запитання нижче.
Подія фіксує дію, наприклад покупку. Піксель надсилає події з браузера відвідувача, а Conversions API (CAPI) — з вашого сервера. Ads Manager збирає ці події в джерелі даних. Атрибуція визначає, якому оголошенню зараховується дія. Вікно атрибуції визначає, протягом якого часу після взаємодії з оголошенням дія може бути зарахована.
Поширені запитання
1. З чого почати?
Визначте, яку дію ви хочете відстежувати, що надсилає дані про неї та які рекламний обліковий запис і ID пікселя використовуються. Ви можете використовувати піксель, CAPI, партнерську інтеграцію або їх поєднання. Для CAPI потрібен ID пікселя, навіть якщо ви не встановили піксель у браузері.
Для початкового налаштування див. Вимірювання конверсій і Відстеження конверсій. Ваш розробник може скористатися посібниками Піксель, CAPI і Підтримувані події. Виконуйте запити CAPI та зберігайте ключі на своєму сервері.
Якщо вашою інтеграцією керує партнер, скористайтеся посібником із налаштування партнера з вимірювання або посібником із налаштування партнера з мобільного вимірювання. Щоб підключити HubSpot, див. Налаштування ChatGPT Ads у HubSpot.
Якщо інтеграцію вже налаштовано, перевірте кожен етап:
Чи було надіслано запит із подією внаслідок дії?
Запит повернув помилку чи його було прийнято?
Чи можете ви підтвердити, що потрібне джерело даних отримало подію?
Чи було подію зараховано оголошенню у звіті кампанії?
2. Піксель установлено. Чому я не бачу покупок або лідів?
Піксель може завантажуватися, але не надсилати потрібну подію покупки або ліда. Попросіть розробника перевірити одну завершену дію:
Перевірте назву події, ID пікселя та сторінку або функцію зворотного виклику, що надсилає подію. Перегляд сторінки — це не завершена покупка.
Переконайтеся, що піксель ініціалізується перед надсиланням події, зокрема коли його завантажує менеджер тегів.
Перевірте консоль браузера та мережевий запит. Саме лише повідомлення «спрацювало» в менеджері тегів не підтверджує, що подію надіслано. Може допомогти режим налагодження пікселя.
Перевірте, чи не завадили запиту налаштування згоди, блокування в браузері або політика безпеки вашого сайту.
Перевірте сторінки для авторизованих користувачів, оформлення замовлення, сайти бронювання, переспрямування та вбудовані форми. Якщо піксель працює на цільовій сторінці, це не підтверджує, що відстеження працює деінде.
Якщо запит не було надіслано, спершу виправте проблему на цьому етапі. Очікування оновлення звітів не допоможе. Перш ніж додавати ще одну інтеграцію, скористайтеся посібником з усунення несправностей пікселя.
3. Що робити, якщо подію відхилено, час очікування минув або повертається помилка сервера?
Збережіть код відповіді, точний текст помилки, час запиту та ID події. Попросіть розробника перевірити формат події, ID пікселя та ключ. Запити з подіями CAPI використовують ключ Conversions API для того самого рекламного облікового запису. Запити для налаштування, керування та звітності використовують окремий ключ Advertiser API. Не надсилайте ключі API до служби підтримки.
У пакетах CAPI одна некоректна подія може спричинити збій усього пакета.
CAPI вимагає вказувати початковий час дії у форматі Unix у мілісекундах. Час події має бути в межах останніх 7 днів і не більш ніж на 10 хвилин у майбутньому. Це обмеження на надсилання не пов’язане з вікном атрибуції. Не змінюйте час давньої події, щоб вона пройшла перевірку.
Після завершення часу очікування або помилки сервера може бути незрозуміло, чи надійшла подія. Перевірте початковий запит і всі записи про отримання. Якщо повторно надсилаєте ту саму дію, збережіть початкові ID події та позначку часу. З новим ID її можуть сприйняти як іншу дію.
Негайно з’ясуйте причину відхилення або постійних помилок запитів. Орієнтовний строк оновлення звітів у 24–48 годин не стосується цих помилок. Вимоги до запитів див. у посібнику Conversions API.
4. Я бачу, що подію прийнято. Чому її немає у звіті?
Прийняття події не означає, що її зараховано оголошенню. Перевірте, що саме підтверджує відповідь і чи використано в запиті правильне джерело даних. У CAPI параметр validate_only зі значенням true перевіряє події, не зберігаючи їх.
Щоб перевірити нову подію, розробник може переглянути нещодавні події, якщо ця функція доступна. Тут відображається вибірка нещодавніх подій, а не повна історія чи результат атрибуції.
Якщо ви не можете перевірити отримання, зверніться до служби підтримки й надайте початкову відповідь і приклад події. Повідомте, які перевірки ви виконали. Не обов’язково спочатку з’ясовувати причину.
Якщо отримання підтверджено, перейдіть до запитання 5. Не надсилайте подію повторно з новими ID лише тому, що звіт кампанії не змінився.
Атрибутовані конверсії можуть з’явитися приблизно за 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 пікселя, назву та ID події в її браузерній і серверній копіях. Поле ID події має назву id у CAPI та event_id у пікселі. Також використовуйте однакову назву спеціальної події з обох боків.
Зберігайте той самий ID, коли повторно надсилаєте дію; для кожної окремої дії використовуйте новий ID. Перевірте, чи немає дублікатів тегів, повторних завантажень сторінки або викликів функцій зворотного виклику, а також партнерських інтеграцій, які вже можуть надсилати подію.
Не надсилайте дублікат, щоб змінити вартість або дані для зіставлення в початковій події. Перш ніж намагатися щось виправити, перевірте описану в документації поведінку. Див. Дедуплікація браузерних і серверних подій.
8. Ми використовуємо Shopify. Чи потрібна нам ще одна інтеграція?
Перш ніж додавати ще одну інтеграцію, перевірте підключення Shopify. Перевірте підключені рекламний обліковий запис і піксель, а потім з’ясуйте, які події застосунок надсилає для вашого магазину.
Якщо ви також використовуєте власні теги, код на сторінці оформлення замовлення або серверний механізм надсилання, перевірте, чи не надсилають вони ті самі події. У Shopify можна використовувати різні поєднання браузерного та серверного відстеження. Див. Налаштування ChatGPT Ads для Shopify.
9. Як працювати зі згодою та тестуванням?
Надсилайте лише ті дані, якими вам дозволено ділитися, і поважайте вибір відвідувачів щодо згоди. Ваш розробник має дотримуватися вказівок інтеграції щодо згоди та підтримуваних даних для зіставлення, зокрема вимог до нормалізації та хешування. Не прибирайте засоби керування згодою, щоб збільшити кількість конверсій у звітах або покращити оцінку.
Згода на вимірювання та opt_out мають різне призначення. Параметр opt_out стосується персоналізації; він не зупиняє всі запити вимірювання. Попросіть розробника перевірити обробку згоди як у браузерних, так і в серверних інтеграціях.
Запишіть час, назву та ID однієї тестової дії. Перевірте, чи було її надіслано, чи пройшла вона перевірку та чи була отримана. Успішне тестування реалізації не свідчить про те, що оголошення відповідає умовам зарахування конверсії.
Параметр validate_only у CAPI перевіряє події, не зберігаючи їх. Режим налагодження пікселя записує активність у журнал, але не виключає тестові події зі звітів. Позначайте тести у своїх записах і не вигадуйте покупки та не змінюйте час подій заради потрібного результату.
10. Чи означає низька або недоступна оцінка якості подій, що відстеження не працює?
Саме по собі — ні. Якість подій оцінюється за інформацією, отриманою з джерела даних. Вона не показує, скільки конверсій було зараховано оголошенням. Лише за низькою або недоступною оцінкою не можна визначити, чи працює відстеження.
Перевірте, чи правильно фіксуються нещодавні реальні дії, а потім з’ясуйте причину попередження. Не надсилайте зайві події або вигадані ідентифікатори, щоб підвищити оцінку. Про перевірки та строки оновлення див. Що таке якість подій і як її покращити.
11. Що вказати у зверненні до служби підтримки?
Розкажіть, чого ви очікували, що сталося, коли це почалося та що ви перевірили. Надайте наявну інформацію з цього списку:
ID рекламного облікового запису, ID пікселя або джерело даних, а також ідентифікатори кампаній і оголошень, яких стосується проблема.
Тип інтеграції та точну назву події, зокрема назву спеціальної події, якщо є.
Один-два наявні ID подій як приклади та позначки часу дій із часовим поясом.
У разі помилок запитів або невпевненості в отриманні: код відповіді, точний текст помилки, час запиту, повернутий ID запиту або CF-Ray, якщо є, і тіло запиту або уривок журналу з вилученими конфіденційними даними.
У разі розбіжностей у звітах: діапазон дат, часову основу звітності, налаштування атрибуції, вибрані стовпці, експорт CSV і порівняння даних з однаковим охопленням.
Відповідні знімки екрана та нещодавні зміни в налаштуваннях, зокрема окреме оформлення замовлення або партнерську інтеграцію.
Повідомте, чи ви підтвердили надсилання, прийняття або отримання події, чи лише перевірили звіт. Ви можете звернутися по допомогу, навіть якщо не можете виконати ці перевірки.
Вилучіть із вкладень ключі API, заголовки авторизації, паролі, файли cookie та зайві дані клієнтів. Негайно повідомляйте про помилки або раптову зупинку інтеграції, яка раніше працювала. Не чекайте завершення строку оновлення звітів.