Диагностика

Вот рекомендуемый алгоритм действий для проверки корректности загруженных данных о мероприятиях и аудитории, а также для выявления проблем с данными.

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

  2. Проверьте общий статус каждого запроса. Успешный запрос имеет Status с code , равным 0 (значение перечисления OK , HTTP-ответ 200 OK ), и возвращает объект IngestEventsResponse , IngestAudienceMembersResponse или RemoveAudienceMembersResponse .

    Если запрос не удался, измените его, устранив ошибку, и отправьте запрос снова.

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

  3. Подождите 30 минут, затем отправьте запрос RetrieveRequestStatus для каждого успешного request_id .

    Периодически повторяйте этот шаг для каждого request_id , пока статус назначения для каждого запроса не достигнет SUCCESS , PARTIAL_SUCCESS или FAILURE . Используйте алгоритм экспоненциальной задержки для ожидания между каждым запросом.

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

  5. Исправьте ошибки в данных.

  6. Вернитесь к шагу 1 и повторяйте действия, пока не устраните все проблемы с загрузкой файлов.

Отправляйте запросы

Для параметра RetrieveRequestStatusRequest требуется одно значение request_id . Отправляйте отдельный запрос статуса для каждого идентификатора запроса, полученного из успешного запроса на обработку.

Периодически отправляйте запрос RetrieveRequestStatusRequest используя алгоритм экспоненциальной задержки, пока request_status не достигнет SUCCESS , FAILURE или PARTIAL_SUCCESS для каждого пункта назначения в исходном запросе. Это может занять до 24 часов, хотя API Data Manager может завершить обработку некоторых запросов всего за 30 минут.

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

Параметр Ценить
Время ожидания до первого запроса на диагностику (в минутах) 30
Множитель обратной связи 1.3
Максимальное время отступления (в минутах) 60 (1 час)
Максимальное общее время (в минутах) 1440 (24 часа)

Вот последовательность запросов и затраченное время при данной конфигурации:

График

Стратегия проведения опросов

Данные

Пытаться Время с момента запроса на прием (чч:мм) Задержитесь перед попыткой. Примечания
1 00:30 30,0 мин Сначала проверьте наличие свободных мест.
2 01:09 39,0 мин
3 01:59 50,7 мин
4 02:59 60,0 мин Теперь задержка ограничена 1 часом.
5 03:59 60,0 мин
6 04:59 60,0 мин
7 05:59 60,0 мин
8 06:59 60,0 мин
9 07:59 60,0 мин
10 08:59 60,0 мин
11 09:59 60,0 мин
12 10:59 60,0 мин
13 11:59 60,0 мин 12-часовая отметка
14 12:59 60,0 мин
15 13:59 60,0 мин
16 14:59 60,0 мин
17 15:59 60,0 мин
18 16:59 60,0 мин
19 17:59 60,0 мин
20 18:59 60,0 мин
21 19:59 60,0 мин
22 20:59 60,0 мин
23 21:59 60,0 мин
24 22:59 60,0 мин
25 23:59 60,0 мин Последний запрос перед истечением максимального 24-часового срока.

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

Отзывы

В объекте RetrieveRequestStatusResponse параметр request_status_per_destination содержит отдельную запись для каждого пункта назначения в соответствующем запросе на прием данных.

Например, если ваш IngestAudienceMembersRequest содержал 3 записи в списке destinations для отправки данных 3 разным аудиториям, то ответ со статусом будет содержать 3 записи в request_status_per_destination (по одной записи на каждую аудиторию).

Проверьте общий статус пункта назначения.

В качестве первого шага проверьте поле request_status , чтобы определить, завершил ли API Data Manager обработку данных для destination RequestStatusPerDestination .

Вот возможные значения параметра request_status :

  • PROCESSING : Данные для целевого объекта все еще обрабатываются. Предупреждения и ошибки для целевого объекта на данном этапе не отображаются.

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

  • FAILURE : Все записи для целевого объекта не были обработаны из-за ошибок. Проверьте наличие предупреждений и ошибок , чтобы определить причину сбоя. Также проверьте наличие предупреждений, выявленных в процессе обработки.

  • PARTIAL_SUCCESS : Часть записей для целевого объекта была успешно обработана, но другие не были обработаны из-за ошибок. Проверьте наличие ошибок , чтобы определить причину сбоя некоторых записей. Также проверьте наличие предупреждений, выявленных в процессе обработки.

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

Проверьте поле статуса, соответствующее типу запроса на прием данных. В каждом RequestStatusPerDestination установлено только одно из следующих полей:

статус приема событий

Поле events_ingestion_status заполняется, если запрос был типа IngestEventsRequest .

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

Статус приема информации участниками аудитории

Поле audience_members_ingestion_status заполняется, если запрос был типа IngestAudienceMembersRequest . Вот поле IngestAudienceMembersStatus , которое нужно проверить для каждого типа данных об аудитории. Заполнено только одно из этих полей.

user_data_ingestion_status

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

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

Если запрос содержал достаточное количество записей, параметр upload_match_rate_range содержит диапазон коэффициентов совпадения для записей в запросе.

mobile_data_ingestion_status

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

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

pair_data_ingestion_status

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

Проверьте значение pair_id_count , чтобы убедиться, что количество полученных идентификаторов пар соответствует вашим ожиданиям.

ppid_data_ingestion_status

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

Проверьте значение ppid_count , чтобы убедиться, что количество полученных PPID соответствует вашим ожиданиям.

user_id_data_ingestion_status

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

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

Статус удаления участников аудитории

Поле audience_members_removal_status заполняется, если запрос был типа RemoveAudienceMembersRequest . Вот поле RemoveAudienceMembersStatus которое нужно проверить для каждого типа данных об аудитории. Заполнено только одно из этих полей.

user_data_removal_status
Статус удаления пользовательских данных .
mobile_data_removal_status
Статус отключения мобильной передачи данных .
pair_data_removal_status
Статус удаления данных PAIR .
ppid_data_removal_status
Статус удаления данных PPID .
user_id_data_removal_status
Статус удаления данных идентификатора пользователя

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

Кроме того, проверьте значения user_identifier_count , mobile_id_count или pair_id_count , чтобы подтвердить общее количество полученных идентификаторов пользователей, мобильных идентификаторов или идентификаторов пар.

Проверьте предупреждения и ошибки.

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

  • Ошибка указывает на то, что API полностью отклонил запись.
  • Предупреждение указывает на то, что API не отклонил запись, но был вынужден проигнорировать часть данных записи.

Например, если Event для офлайн-конверсии Google Ads содержит зашифрованные данные UserIdentifier и AdIdentifiers , такие как gclid , и данные UserIdentifier не могут быть расшифрованы, API Data Manager все равно обработает запись, используя AdIdentifiers , но вернет предупреждение PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR .

Однако, если Event не содержит AdIdentifiers , а данные UserIdentifier не могут быть расшифрованы, API Data Manager отклоняет всю запись и сообщает об ошибке PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR , поскольку допустимое Event конверсии в офлайн-режиме Google Ads должно содержать хотя бы один из параметров ad_identifiers или user_data .

Ниже представлены поля ответа, содержащие информацию о предупреждениях и ошибках. Эти поля заполняются, когда общий статус назначения достигает SUCCESS , PARTIAL_SUCCESS или FAILURE .

warning_info

Список объектов WarningCount . Каждый WarningCount содержит reason с указанием типа предупреждения и record_count записей, в которых было обнаружено предупреждение данного типа.

Проверьте warning_info даже если общий статус назначения — SUCCESS .

error_info

Список объектов ErrorCount . Каждый объект ErrorCount содержит reason ошибки и её тип, а также record_count указывающий количество записей, обработка которых завершилась с ошибкой данного типа.