Как проверить статус запроса и данные диагностики

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

Используйте возвращенный request_id с RetrieveRequestStatus, чтобы проверить статус загрузки и посмотреть диагностику.

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

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

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

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

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

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

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

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

   Совет. Попробуйте отправить запрос в браузере с помощью API Explorer.

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

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

5. Устраните проблемы с данными.

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

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

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

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

Проверьте поле request_status в каждом объекте RequestStatusPerDestination, чтобы узнать, завершил ли Data Manager API обработку данных для этого целевого сервиса.

Возможные значения request_status:

• PROCESSING: данные для целевой страницы ещё обрабатываются. На этом этапе предупреждения и ошибки для целевого ресурса не заполняются. Продолжайте опрос, пока не будет достигнуто конечное состояние.

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

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

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

Посмотреть результаты диагностики

Когда значение request_status для целевого сервиса достигнет SUCCESS, FAILURE или PARTIAL_SUCCESS, проверьте подробные диагностические данные в ответе, чтобы подтвердить количество и устранить неполадки.

Как проверить статус события или аудитории для каждого целевого сервиса

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

• events_ingestion_status

• audience_members_ingestion_status

• audience_members_removal_status

Статус передачи событий

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

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

Периодически отправляйте запрос 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 часов

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

Требования к авторизации

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.