Диагностика

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

  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 часов, хотя Data Manager API может обработать некоторые запросы всего за 30 минут.

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

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

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

График

Стратегия опроса

Данные

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

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

Проверить ответы

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

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

Как проверить общий статус целевого аккаунта

Сначала проверьте поле request_status, чтобы узнать, завершил ли Data Manager API обработку данных для 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 нужно проверить для каждого типа данных аудитории. Задано только одно из этих полей.

composite_data_ingestion_status

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

Проверьте data_type_counts, чтобы убедиться, что количество идентификаторов соответствует вашим ожиданиям. В этом списке приведена разбивка всех полученных идентификаторов (например, адрес электронной почты, номер телефона, физический адрес и IP-адрес) по DataType.

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

google_user_id_data_ingestion_status

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

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

mobile_data_ingestion_status

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

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

pair_data_ingestion_status

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

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

partner_provided_id_data_ingestion_status

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

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

ppid_data_ingestion_status

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

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

user_data_ingestion_status

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

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

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

user_id_data_ingestion_status

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

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

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

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

composite_data_removal_status
Статус удаления составных данных
google_user_id_data_removal_status
Статус удаления данных идентификатора пользователя Google
mobile_data_removal_status
Статус удаления мобильных данных.
pair_data_removal_status
Статус удаления данных PAIR.
partner_provided_id_data_removal_status
Статус удаления данных идентификатора, предоставленных партнером
ppid_data_removal_status
Статус удаления данных PPID.
user_data_removal_status
Статус удаления пользовательских данных.
user_id_data_removal_status
Статус удаления данных идентификатора пользователя

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

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

Если вы используете составные данные, проверьте, соответствует ли количество идентификаторов вашим ожиданиям. Для этого нажмите на значок data_type_counts. В этом списке представлена разбивка всех полученных идентификаторов (например, адрес электронной почты, номер телефона, физический адрес и IP-адрес), которые были переданы в DataType.

Проверка предупреждений и ошибок

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

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

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

Однако если в Event нет AdIdentifiers и данные UserIdentifier не удается расшифровать, Data Manager API отклоняет всю запись и сообщает об ошибке PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR, поскольку в допустимом значении Event должен быть хотя бы один из элементов: 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, указывающий количество записей, которые не удалось обработать из-за этой ошибки.