Обзор

Используйте это руководство, если события отсутствуют, запросы завершаются ошибкой или данные в Менеджере рекламы расходятся с вашими учётными данными. Начните с одной завершённой покупки, отправленной заявки или другого действия. Зафиксируйте, что и когда произошло, затем выберите подходящий вопрос ниже.

Событие фиксирует действие, например покупку. Пиксель отправляет события из браузера посетителя, а API конверсий (CAPI) — с вашего сервера. Менеджер рекламы собирает эти события в источнике данных. Атрибуция определяет, к какому объявлению относится действие. Окно атрибуции задаёт срок после взаимодействия с рекламой, в течение которого действие может быть отнесено к ней.

Часто задаваемые вопросы

1. С чего начать?

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

Для первоначальной настройки см. Измерение конверсий и Отслеживание конверсий. Ваш разработчик может воспользоваться руководствами Пиксель, CAPI и Поддерживаемые события. Отправляйте запросы CAPI и храните ключи только на своём сервере.

Если интеграцией управляет партнёр, воспользуйтесь руководством по настройке партнёра по измерениям или руководством по настройке партнёра по мобильным измерениям. Для подключения HubSpot см. Настройка ChatGPT Реклама в HubSpot.

Если интеграция уже настроена, проверьте каждый этап:

• Был ли при выполнении действия отправлен запрос с событием?

• Запрос вернул ошибку или был принят?

• Можете ли вы подтвердить, что событие поступило в нужный источник данных?

• Было ли событие отнесено к объявлению в отчёте по кампании?

2. Пиксель установлен. Почему я не вижу покупок или лидов?

Пиксель может загружаться, но не отправлять нужное событие покупки или лида. Попросите разработчика проверить одно завершённое действие:

• Проверьте имя события, ID пикселя и страницу или функцию обратного вызова, которая его отправляет. Просмотр страницы — это не завершённая покупка.

• Убедитесь, что пиксель инициализируется до отправки события, в том числе при загрузке через менеджер тегов.

• Проверьте консоль браузера и сетевой запрос. Само по себе сообщение «Тег сработал» в менеджере тегов не подтверждает отправку события. В этом может помочь режим отладки пикселя.

• Проверьте, не помешали ли запросу выбранные пользователем настройки согласия, блокировка в браузере или политика безопасности сайта.

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

Если запрос не был отправлен, сначала устраните проблему на этом этапе. Ожидание данных в отчёте не поможет. Прежде чем добавлять другую интеграцию, воспользуйтесь руководством по устранению неполадок пикселя.

3. Что делать, если событие отклонено, время ожидания истекло или возвращается ошибка сервера?

Сохраните код ответа, точный текст ошибки, время запроса и ID события. Попросите разработчика проверить формат события, ID пикселя и ключ. Запросы с событиями CAPI используют ключ API конверсий для того же рекламного аккаунта. Запросы для настройки, управления и получения отчётов используют отдельный ключ API рекламодателя. Не отправляйте ключи API в службу поддержки.

При пакетной отправке через CAPI одно некорректное событие может привести к отклонению всего пакета.

CAPI требует исходное время действия в формате Unix в миллисекундах. Время события должно быть не старше 7 дней и не более чем на 10 минут в будущем. Это ограничение на отправку не связано с окном атрибуции. Не меняйте время старого события, чтобы оно прошло проверку.

При истечении времени ожидания или ошибке сервера может быть неясно, получено ли событие. Проверьте исходный запрос и все записи о получении. При повторной отправке того же действия сохраняйте исходные ID события и временную метку. С новым ID оно может быть воспринято как другое действие.

Не откладывайте выяснение причин отклонения или постоянных сбоев запросов. Ориентировочный срок появления данных в отчётах — 24–48 часов — не относится к этим ошибкам. Требования к запросам см. в разделе API конверсий.

4. Я вижу, что событие принято. Почему его нет в отчёте?

Принятие события не означает, что оно отнесено к объявлению. Проверьте, что именно подтверждает ответ и использовался ли в запросе нужный источник данных. В CAPI параметр validate_only со значением true проверяет события, но не сохраняет их.

Для нового события разработчик может проверить недавние события, если эта возможность доступна. Там отображается выборка недавних событий, а не полная история или результат атрибуции.

Если проверить получение не удаётся, обратитесь в службу поддержки и приложите исходный ответ и пример события. Расскажите, какие проверки вы выполнили; выяснять причину до обращения не нужно.

Если получение подтверждено, перейдите к вопросу 5. Не отправляйте событие повторно с новыми ID только потому, что отчёт по кампании не изменился.

Атрибутированные конверсии могут появиться примерно через 24–48 часов, а итоговые значения за последнее время могут меняться в ходе обработки. Этот срок не гарантирует, что каждое принятое событие появится в отчёте, и не подтверждает его получение. См. Оценка результатов.

5. События поступают. Почему в кампании по-прежнему ноль конверсий?

Прежде чем менять интеграцию, проверьте:

• Подключён ли нужный источник данных к правильному аккаунту?

• Соответствует ли отправляемое событие настройке конверсии в кампании? Для пользовательских событий проверьте пользовательский тип и точное имя события. Совпадения отображаемого названия недостаточно.

• Была ли нужная конверсия привязана к кампании до проверяемого действия?

• Произошло ли действие после клика по объявлению или его просмотра, который соответствует настройкам атрибуции?

• Правильно ли выбраны кампания, столбец события, даты и принцип учёта времени в отчёте?

Данные для сопоставления помогают связать событие с объявлением, но не гарантируют атрибуцию. Сохраняйте настоящий идентификатор клика OpenAI, oppref, на протяжении посещения и включайте его в серверные события, если он доступен. Никогда не придумывайте идентификатор и не используйте идентификатор другого посетителя.

Проверяйте браузерные и серверные события отдельно. Идентификатор клика или поле с данными клиента, доступные пикселю, могут отсутствовать в серверном событии.

Выбранную цель кампании с оптимизацией по конверсиям нельзя изменить после её создания. Чтобы использовать другую цель, создайте новую кампанию. Пользовательские события не могут быть целями оптимизации. См. Кампании с оптимизацией по конверсиям.

Устранив несоответствие в настройках, проверьте новые действия, отвечающие условиям атрибуции. Не рассчитывайте, что изменение исправит прежние отчёты. Правила сопоставления см. в разделе Измерение конверсий.

6. Почему данные в Менеджере рекламы, нашем инструменте аналитики и CRM расходятся?

Сравнивайте одни и те же действия при одинаковых правилах формирования отчётов. Ваша CRM может учитывать все покупки, а рекламный отчёт — только покупки, отнесённые к этой платформе. Разные платформы могут по-разному атрибутировать одну и ту же покупку.

В Менеджере рекламы показатель Конверсии объединяет конверсии после клика и подходящие конверсии после просмотра, если окно учёта конверсий после просмотра составляет 1 день. При окне просмотра в 0 дней учитываются только конверсии после клика. При сравнении отчётов используйте одинаковую настройку.

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

Если источники трафика обозначены по-разному, проверьте URL целевой страницы и параметры отслеживания для этого посещения. Текущие настройки кампании могут отличаться от прежних.

Сравните:

• Аккаунт, кампанию, тип события, фильтры и уровень детализации отчёта.

• Диапазон дат, часовой пояс и то, относятся ли даты к взаимодействию с рекламой или к самой конверсии.

• Настройки конверсий после клика и после просмотра, а также конкретный выбранный показатель или столбец.

• Недавние задержки обработки, обработку дубликатов, согласия пользователей и доступные данные для сопоставления.

• Моделируемые конверсии, если они доступны: они могут отличаться от непосредственно зарегистрированных транзакций.

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

При сравнении выручки учитывайте налоги, доставку, скидки и комиссии. Убедитесь, что браузерная и серверная копии передают одинаковую стоимость заказа. Показатели Продажи по созданным заказам и ROAS по созданным заказам учитывают только атрибутированные события order_created.

Импортированные данные об активности из GA4 включают события из всех источников трафика выбранного ресурса. Эти итоговые значения не являются конверсиями, отнесёнными к кампании. См. Подключение Google Analytics 4 к Менеджеру рекламы OpenAI.

При сравнении с данными API зафиксируйте конечную точку и явно задайте параметры отчётности. Если параметр не задан, его значение может отличаться от используемого в Менеджере рекламы. Отчёты также могут включать разные события: некоторые охватывают цели кампании, но не другие отслеживаемые действия. Отсутствие события в одном отчёте не доказывает, что оно не было получено.

Для сравнения CSV используйте одинаковые настройки и сохраняйте экспортированные файлы без изменений. О представлениях в Менеджере рекламы см. Оценка результатов, а о параметрах API — Отчётность.

7. Не будет ли покупка учтена дважды при использовании пикселя и CAPI?

Чтобы одно действие не учитывалось дважды, используйте одинаковые ID пикселя, имя и ID события в его браузерной и серверной копиях. Поле идентификатора события называется id в CAPI и event_id в пикселе. Имя пользовательского события также должно совпадать с обеих сторон.

При повторной отправке действия сохраняйте тот же ID; для каждого нового действия используйте новый ID. Проверьте, нет ли дублирующихся тегов, повторных загрузок страницы или вызовов обратного вызова, а также партнёрских интеграций, которые уже могут отправлять это событие.

Не отправляйте дубликат, чтобы изменить ценность исходного события или данные для сопоставления. Прежде чем вносить исправления, изучите описанное в документации поведение. См. Дедупликация браузерных и серверных событий.

8. Мы используем Shopify. Нужна ли нам ещё одна интеграция?

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

Если вы также используете собственные теги, код при оформлении заказа или серверную отправку, проверьте, не отправляют ли они те же события. В конфигурациях Shopify могут использоваться разные сочетания браузерного и серверного отслеживания. См. Настройка ChatGPT Реклама для Shopify.

9. Как учитывать согласие пользователей и проводить тестирование?

Отправляйте только те данные, которыми вам разрешено делиться, и соблюдайте выбор посетителей в отношении согласия. Разработчик должен следовать рекомендациям интеграции по обработке согласий и поддерживаемым данным для сопоставления, включая необходимые нормализацию и хеширование. Не убирайте механизмы управления согласием ради увеличения числа конверсий в отчётах или улучшения оценки.

Согласие на измерения и opt_out служат разным целям. Параметр opt_out касается персонализации; он не останавливает все запросы на измерение. Попросите разработчика проверить обработку согласий как в браузерных, так и в серверных интеграциях.

Запишите время, имя и ID одного тестового действия. Проверьте, было ли оно отправлено, прошло ли проверку и было ли получено. Успешный тест реализации не означает, что действие может быть отнесено к объявлению.

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

10. Означает ли низкая или недоступная оценка качества событий, что отслеживание не работает?

Само по себе — нет. Оценка качества событий характеризует данные, полученные от источника. Она не показывает, сколько конверсий было отнесено к рекламе. По одной лишь низкой или недоступной оценке нельзя определить, работает ли отслеживание.

Убедитесь, что недавние реальные действия фиксируются корректно, затем выясните причину предупреждения. Не отправляйте лишние события или вымышленные идентификаторы, чтобы повысить оценку. О проверках и сроках обновления см. Как оценить и улучшить качество событий.

11. Что указать при обращении в службу поддержки?

Расскажите, какого результата вы ожидали, что произошло, когда началась проблема и что вы уже проверили. Укажите всё, что у вас есть из этого списка:

• ID рекламного аккаунта, ID пикселя или источник данных, а также идентификаторы кампаний и объявлений, которых касается проблема.

• Тип интеграции и точное имя события, в том числе пользовательского.

• Один-два примера ID существующих событий и временные метки действий с указанием часового пояса.

• При сбоях запросов или сомнениях в получении: код ответа, точный текст ошибки, время запроса, возвращённый ID запроса или CF-Ray, а также тело запроса или фрагмент журнала с удалёнными конфиденциальными данными.

• При расхождениях в отчётах: диапазон дат, принцип учёта времени в отчёте, настройки атрибуции, выбранные столбцы, экспорт в CSV и сравнение данных с одинаковым охватом.

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

Сообщите, подтвердили ли вы отправку, принятие или получение события либо только проверили отчёт. Вы можете обратиться за помощью, даже если не удалось выполнить эти проверки.

Удалите из вложений ключи API, заголовки авторизации, пароли, файлы cookie и лишние сведения о клиентах. Сразу сообщайте об ошибках или внезапной остановке ранее работавшей интеграции. Не ждите, пока истечёт срок появления данных в отчётах.