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. Emitir solicitudes para enviar eventos o 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 enumeración OK, respuesta HTTP 200 OK) y muestra un IngestEventsResponse, IngestAudienceMembersResponse o RemoveAudienceMembersResponse.

    Si una solicitud no se realiza correctamente, modifícala para corregir 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 los diagnósticos en el siguiente paso.

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

    Repite este paso periódicamente para cada request_id hasta que el estado del 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 funcionan correctamente y, luego, identifica cualquier problema con tus datos.

  5. Corregir problemas de datos

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

Envía solicitudes

Un RetrieveRequestStatusRequest requiere un solo valor de request_id. 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 request_status alcance SUCCESS, FAILURE o PARTIAL_SUCCESS para cada destino de la solicitud original. Este proceso 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 y una configuración de reintentos razonables que equilibran la actividad y el uso de la cuota:

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

A continuación, se muestra una secuencia de solicitudes y el tiempo transcurrido con esta configuración:

Gráfico

Estrategia de sondeo

Datos

Intento Tiempo transcurrido desde la solicitud de transferencia (hh:mm) Retraso antes del intento Notas
1 00:30 30.0 min Primero, verifica la disponibilidad del estado
2 01:09 39.0 min
3 01:59 50.7 min
4 02:59 60.0 min El retraso ahora se limita a 1 hora
5 03:59 60.0 min
6 04:59 60.0 min
7 05:59 60.0 min
8 06:59 60.0 min
9 07:59 60.0 min
10 08:59 60.0 min
11 09:59 60.0 min
12 10:59 60.0 min
13 11:59 60.0 min Marca de 12 horas
14 12:59 60.0 min
15 13:59 60.0 min
16 14:59 60.0 min
17 15:59 60.0 min
18 16:59 60.0 min
19 17:59 60.0 min
20 18:59 60.0 min
21 19:59 60.0 min
22 20:59 60.0 min
23 21:59 60.0 min
24 22:59 60.0 min
25 23:59 60.0 min Última solicitud antes del tiempo total máximo de 24 horas

Agrega una pequeña cantidad aleatoria de jitter a las demoras de la retirada para evitar el problema de "activación simultánea", en el que muchos clientes vuelven a intentar la operación de forma simultánea.

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).

Cómo verificar el estado general del destino

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

Estos son los valores posibles de request_status:

  • PROCESSING: Los datos del destino aún se están procesando. En esta etapa, no se propagan las advertencias ni los errores para el destino.

  • SUCCESS: Se completó el procesamiento de la solicitud para el destino sin errores. Verifica las 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 se marcaron advertencias durante el procesamiento.

  • PARTIAL_SUCCESS: Algunos de los registros del destino se completaron correctamente, pero otros fallaron debido a errores. Verifica si hay errores para determinar por qué fallaron algunos registros. También verifica si se marcaron advertencias 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 configura uno de los siguientes campos en cada RequestStatusPerDestination:

Estado de la transferencia de eventos

El campo events_ingestion_status se completa si la solicitud fue un IngestEventsRequest.

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

Estado de la transferencia de miembros del público

El campo audience_members_ingestion_status se completa si la solicitud fue un IngestAudienceMembersRequest. A continuación, se indica 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 de IngestUserDataStatus para confirmar que la cantidad total de registros recibidos coincida con tus expectativas. El objeto record_count incluye registros correctos y fallidos.

Verifica el campo 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, upload_match_rate_range contiene el rango de la tasa de coincidencias para los registros de la solicitud.

mobile_data_ingestion_status

Verifica el record_count de IngestMobileDataStatus para confirmar que la cantidad total de registros recibidos coincida con tus expectativas. El objeto record_count incluye los registros correctos y los 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 de IngestPairDataStatus para confirmar que la cantidad total de registros recibidos coincida con tus expectativas. El objeto 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 de IngestPpidDataStatus para confirmar que la cantidad total de registros recibidos coincida con tus expectativas. El objeto record_count incluye registros correctos y fallidos.

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

user_id_data_ingestion_status

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

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

composite_data_ingestion_status

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

Verifica el data_type_counts para confirmar que la cantidad de identificadores coincide con tus expectativas. En esta lista, se proporciona un desglose de todos los identificadores que recibe DataType (como la dirección de correo electrónico, el número de teléfono, la dirección física y la dirección IP).

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

Estado de eliminación de miembros del público

El campo audience_members_removal_status se completa si la solicitud fue un RemoveAudienceMembersRequest. Aquí se muestra el campo RemoveAudienceMembersStatus que debes verificar para cada tipo de datos de público. Solo se establece uno de estos campos.

user_data_removal_status
Estado de eliminación de los datos del usuario
mobile_data_removal_status
Es el estado de eliminación de los datos móviles.
pair_data_removal_status
Es el estado de eliminación de los datos de PAIR.
ppid_data_removal_status
Estado de eliminación de los datos del PPID.
user_id_data_removal_status
Estado de eliminación de los datos del ID de usuario
composite_data_removal_status
Estado de eliminación de los datos compuestos

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

Además, verifica los campos user_identifier_count, mobile_id_count, pair_id_count, ppid_count o user_id_count para confirmar el recuento total de identificadores recibidos.

En el caso de los datos compuestos, verifica el data_type_counts para confirmar que la cantidad de identificadores coincida con tus expectativas. En esta lista, se proporciona un desglose de todos los identificadores recibidos (como la dirección de correo electrónico, el número de teléfono, la dirección física y la dirección IP) por DataType.

Comprueba las advertencias y los errores

Además de los campos de estado para el destino y el tipo de solicitud, el objeto RetrieveRequestStatusResponse contiene un desglose de las advertencias y los errores de 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 contiene datos UserIdentifier encriptados y AdIdentifiers, como gclid, y los datos UserIdentifier no se pueden desencriptar, la API de Data Manager sigue procesando el registro con el AdIdentifiers, pero devuelve la advertencia PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.

Sin embargo, si el objeto Event no contiene AdIdentifiers y no se pueden desencriptar los datos de UserIdentifier, la API de Data Manager rechaza todo el registro y muestra el error PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR porque un objeto Event válido debe tener al menos uno de los campos ad_identifiers o user_data.

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

warning_info

Es una lista de objetos WarningCount. Cada WarningCount contiene un reason con el tipo de advertencia y un record_count que indica la cantidad de registros que tuvieron ese tipo de advertencia.

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

error_info

Es una lista de objetos ErrorCount. 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.