Diagnóstico

Este es el flujo de trabajo recomendado para verificar el estado de tus cargas de eventos y públicos, y para identificar problemas con tus datos.

1. Envía solicitudes para enviar eventos o para enviar o quitar miembros del público.

2. Verifica el estado general de cada solicitud. Una solicitud correcta tiene un Status con code igual a 0 (valor de enum OK, HTTP respuesta 200 OK) y muestra un IngestEventsResponse, IngestAudienceMembersResponse o RemoveAudienceMembersResponse.

   Si una solicitud no se realiza correctamente, modifícala para solucionar el error y vuelve a enviarla.

   Si una solicitud se realiza correctamente, captura el request_id de la respuesta para que puedas usarlo y recuperar el diagnóstico en el siguiente paso.

3. Espera 30 minutos y, luego, envía una RetrieveRequestStatus solicitud para cada request_id correcta.

   Repite este paso periódicamente para cada request_id hasta que el estado de destino de cada destino alcance SUCCESS, PARTIAL_SUCCESS, o FAILURE. Usa un algoritmo de retirada exponencial para esperar entre cada solicitud.

4. Revisa cada RetrieveRequestStatusResponse para confirmar que tus cargas funcionen correctamente y para identificar cualquier problema con tus datos.

5. Corrige los problemas de datos.

6. Vuelve al paso 1 y repite el proceso hasta que hayas resuelto todos los problemas con tus cargas.

Envía solicitudes

Un RetrieveRequestStatusRequest requiere un solo request_id valor. Envía una solicitud de estado independiente para cada ID de solicitud que capturaste de una solicitud de transferencia correcta.

Envía el RetrieveRequestStatusRequest periódicamente con un algoritmo de retirada exponencial hasta que el request_status alcance SUCCESS, FAILURE o PARTIAL_SUCCESS para cada destino en la solicitud original. Esto puede tardar hasta 24 horas, aunque la API de Data Manager puede terminar de procesar algunas solicitudes en tan solo 30 minutos.

Este es un ejemplo de un tiempo de espera inicial razonable y una configuración de reintento que equilibra la actividad y el uso de la cuota:

Configuración	Valor
Tiempo de espera antes de la primera solicitud de diagnóstico (minutos)	30
Multiplicador de retirada	1.3
Retirada máxima (minutos)	60 (1 hora)
Tiempo total máximo (minutos)	1440 (24 horas)

Esta es una secuencia de solicitudes y el tiempo transcurrido con esta configuración:

Agrega una pequeña cantidad aleatoria de fluctuación a las demoras de retirada para evitar el problema de "activación simultánea", en el que muchos clientes reintentan la solicitud al mismo tiempo.

Revisar respuestas

El request_status_per_destination en un RetrieveRequestStatusResponse contiene una entrada independiente para cada destino en la solicitud de transferencia correspondiente.

Por ejemplo, si tu IngestAudienceMembersRequest contenía 3 entradas en la lista destinations para enviar datos a 3 públicos diferentes, la respuesta de estado contendría 3 entradas en request_status_per_destination (una entrada por público).

Verifica el estado general del destino

Como primer paso, verifica el request_status campo para determinar si la API de Data Manager terminó de procesar los datos para el destination del RequestStatusPerDestination.

Estos son los valores posibles de request_status:

• PROCESSING: Los datos del destino aún se están procesando. Las advertencias y los errores no se propagan para el destino en esta etapa.

• SUCCESS: El procesamiento de la solicitud para el destino se completó sin errores. Verifica si hay advertencias marcadas durante el procesamiento.

• FAILURE: Todos los registros del destino fallaron debido a errores. Verifica si hay advertencias y errores para determinar por qué fallaron todos los registros. También verifica si hay advertencias marcadas durante el procesamiento.

• PARTIAL_SUCCESS: Algunos de los registros del destino se realizaron correctamente, pero otros fallaron debido a errores. Verifica si hay errores para determinar por qué fallaron algunos registros. También verifica si hay advertencias marcadas durante el procesamiento.

Verifica el estado del evento o del público por destino

Inspecciona el campo de estado que corresponde al tipo de solicitud de transferencia. Solo se establece uno de los siguientes campos en cada RequestStatusPerDestination:

• events_ingestion_status
• audience_members_ingestion_status
• audience_members_removal_status

Estado de transferencia de eventos

El campo events_ingestion_status se propaga si la solicitud era un IngestEventsRequest.

Verifica el record_count del IngestEventStatus para confirmar que la cantidad total de registros recibidos coincida con tus expectativas. El record_count incluye registros correctos y fallidos.

Estado de transferencia de miembros del público

El campo audience_members_ingestion_status se propaga si la solicitud era un IngestAudienceMembersRequest. Este es el campo IngestAudienceMembersStatus que debes verificar para cada tipo de datos del público. Solo se establece uno de estos campos.

user_data_ingestion_status

Verifica el record_count del IngestUserDataStatus para confirmar que la cantidad total de registros recibidos coincida con tus expectativas. El record_count incluye registros correctos y fallidos.

Verifica el user_identifier_count para confirmar que la cantidad de identificadores de usuario recibidos coincida con tus expectativas.

Si la solicitud tenía una cantidad suficiente de registros, el upload_match_rate_range contiene el rango de tasa de coincidencias para los registros de la solicitud.

mobile_data_ingestion_status

Verifica el record_count del IngestMobileDataStatus para confirmar que la cantidad total de registros recibidos coincida con tus expectativas. El record_count incluye registros correctos y fallidos.

Verifica el mobile_id_count para confirmar que la cantidad de IDs de dispositivos móviles recibidos coincida con tus expectativas.

pair_data_ingestion_status

Verifica el record_count del IngestPairDataStatus para confirmar que la cantidad total de registros recibidos coincida con tus expectativas. El record_count incluye registros correctos y fallidos.

Verifica el pair_id_count para confirmar que la cantidad de IDs de PAIR recibidos coincida con tus expectativas.

ppid_data_ingestion_status

Verifica el record_count del IngestPpidDataStatus para confirmar que la cantidad total de registros recibidos coincida con tus expectativas. El record_count incluye registros correctos y fallidos.

Verifica el ppid_count para confirmar que la cantidad de PPIDs recibidos coincida con tus expectativas.

user_id_data_ingestion_status

Verifica el record_count del IngestUserIdDataStatus para confirmar que la cantidad total de registros recibidos coincida con tus expectativas. El record_count incluye registros correctos y fallidos.

Verifica el user_id_count para confirmar que la cantidad de IDs de usuario recibidos coincida con tus expectativas.

Estado de eliminación de miembros del público

El campo audience_members_removal_status se propaga si la solicitud era un RemoveAudienceMembersRequest. Este es el RemoveAudienceMembersStatus campo que debes verificar para cada tipo de datos del público. Solo se establece uno de estos campos.

user_data_removal_status

Estado de eliminación de datos del usuario.

mobile_data_removal_status

Estado de eliminación de datos móviles.

pair_data_removal_status

Estado de eliminación de datos de PAIR.

ppid_data_removal_status

Estado de eliminación de datos de PPID.

user_id_data_removal_status

Estado de eliminación de datos de ID de usuario

Verifica el record_count para confirmar que la cantidad total de registros recibidos coincida con tus expectativas. El record_count incluye registros correctos y fallidos.

Además, verifica el user_identifier_count, el mobile_id_count o el pair_id_count para confirmar el recuento total de identificadores de usuario, IDs de dispositivos móviles o IDs de PAIR recibidos.

Verifica las advertencias y los errores

Además de los campos de estado para el destino y el tipo de solicitud, el RetrieveRequestStatusResponse contiene un desglose de advertencias y errores para la solicitud.

• Un error indica que la API rechazó por completo el registro.
• Una advertencia indica que la API no rechazó el registro, pero tuvo que ignorar partes de los datos del registro.

Por ejemplo, si un Event para una conversión sin conexión de Google Ads contiene datos UserIdentifier encriptados y AdIdentifiers, como gclid, y los datos UserIdentifier no se pueden desencriptar, la API de Data Manager aún procesa el registro con los AdIdentifiers, pero muestra la advertencia PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.

Sin embargo, si el Event no contiene AdIdentifiers y los datos UserIdentifier no se pueden desencriptar, la API de Data Manager rechaza todo el registro y muestra el error PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR, ya que un Event de conversión sin conexión de Google Ads válido debe tener al menos uno de ad_identifiers o user_data.

Estos son los campos de respuesta que contienen información sobre advertencias y errores. Estos campos se propagan cuando el estado general del destino alcanza SUCCESS, PARTIAL_SUCCESS, o FAILURE.

warning_info

Una lista de WarningCount objetos. Cada WarningCount contiene un reason con el tipo de advertencia y un record_count que indica la cantidad de registros que tenían ese tipo de advertencia.

Verifica el warning_info incluso si el estado general del destino es SUCCESS.

error_info

Una lista de ErrorCount objetos. Cada ErrorCount contiene un reason con el tipo de error y un record_count que indica la cantidad de registros que fallaron debido a ese tipo de error.