Диагностика

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

  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 по тому же пути доступа, который указан в исходном запросе на загрузку.

    Например, если в запросе на получение данных для operating_account Google Рекламы в качестве 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,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 часов

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

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

Объект 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, указывающий количество записей, которые не удалось обработать из-за ошибки этого типа.