Диагностика

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

  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 не принимает целевые аккаунты или заголовки запросов. Вместо этого Data Manager API определяет целевые сервисы из исходного запроса на загрузку, связанного с request_id, и проверяет, есть ли у вызывающей стороны доступ к operating_account в каждом Destination.

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

  • Одинаковый путь доступа. Учетные данные должны иметь доступ к каждому объекту operating_account по точно такому же пути, который был указан в исходном запросе на загрузку.

    Например, если в запросе на загрузку данных для аккаунта Google Рекламы operating_account в качестве login_account указан родительский управляющий аккаунт, то учетные данные должны иметь доступ к operating_account через этот управляющий аккаунт. Даже если у аккаунта Google, связанного с учетными данными, есть прямой доступ к дочернему аккаунту operating_account, запрос завершится ошибкой PERMISSION_DENIED, если у этого аккаунта нет доступа через управляющий аккаунт login_account, указанный при загрузке.

  • Достаточный уровень доступа. Аккаунт Google, связанный с учетными данными, должен иметь уровень доступа или роль с разрешением на передачу данных в operating_account.

    Например, в Google Рекламе у аккаунта Google должен быть уровень доступа Администратор или Стандартный. Запрос с учетными данными для аккаунта с уровнем доступа Только чтение завершается ошибкой PERMISSION_DENIED.

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

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

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

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

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

График

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

Данные

Попытка Время с момента запроса на передачу данных (чч:мм) Задержка перед попыткой Примечания
1 00:30 30,0 мин. Сначала проверьте, доступен ли статус
2 01:09 39 мин.
3 01:59 50,7 мин.
4 02:59 60,0 мин. Максимальная задержка теперь составляет 1 час
5 03:59 60 мин.
6 04:59 60 мин.
7 05:59 60,0 мин.
8 06:59 60 мин.
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 мин.
15 13:59 60 мин.
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 мин.
22 20:59 60,0 мин.
23 21:59 60,0 мин.
24 22:59 60,0 мин.
25 23:59 60,0 мин. Последний запрос до истечения 24 часов

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

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

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

Например, если в списке destinations вашего запроса IngestAudienceMembersRequest было три записи для отправки данных трем разным аудиториям, то ответ о статусе будет содержать три записи в 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, чтобы убедиться, что количество идентификаторов соответствует вашим ожиданиям. В этом списке перечислены все идентификаторы, полученные DataType, например адреса электронной почты, номера телефонов, физические адреса и IP-адреса.

Если в запросе было достаточно записей, 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. В этом списке перечислены все идентификаторы, полученные DataType, например адреса электронной почты, номера телефонов, физические адреса и IP-адреса.

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

Помимо полей статуса для целевого местоположения и типа запроса, в 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

Объект WarningInfo. Его поле warning_counts содержит список объектов WarningCount. Каждый объект WarningCount содержит объект reason с типом предупреждения и объект record_count, указывающий количество записей с этим типом предупреждения.

Проверьте warning_info, даже если общий статус целевой страницы – SUCCESS.

error_info

Объект ErrorInfo. Поле error_counts содержит список объектов ErrorCount. Каждый элемент ErrorCount содержит элемент reason с типом ошибки и элемент record_count, указывающий количество записей, которые не удалось обработать из-за ошибки этого типа.