Verifica el estado de la solicitud y los diagnósticos

Las solicitudes para enviar eventos o miembros del público se procesan de forma asíncrona. Una respuesta de transferencia correcta devuelve un request_id y, además, indica que la solicitud cumplió con todos los requisitos y se aceptó para su procesamiento. Sin embargo, no indica si los registros de la solicitud se procesaron correctamente.

Usa el request_id que se muestra con RetrieveRequestStatus para verificar el estado de la carga y revisar los diagnósticos.

Este es el flujo de trabajo recomendado para verificar el estado de tus solicitudes y el estado de tus cargas de eventos y públicos:

1. Emite solicitudes para enviar eventos o enviar o quitar miembros del público.

2. Verifica el estado general de cada solicitud de transferencia. Una solicitud correcta tiene un Status con code igual a 0 (valor de enumeración OK, respuesta HTTP 200 OK) y devuelve 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 verificar el estado del procesamiento en el siguiente paso.

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

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

   Repite este paso de forma periódica para cada request_id hasta que el estado de destino de cada destino alcance SUCCESS, PARTIAL_SUCCESS o FAILED. Sigue la estrategia de sondeo recomendada para esperar entre cada solicitud.

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

5. Corrige los problemas de datos.

6. Regresa al paso 1 y repítelo hasta que hayas solucionado todos los problemas con tus cargas.

Verifica el estado general del destino

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 contiene 3 entradas en la lista destinations para enviar datos a 3 públicos diferentes, la respuesta de estado contiene 3 entradas en request_status_per_destination (una entrada por público).

Verifica el campo request_status en cada RequestStatusPerDestination para determinar si la API de Data Manager terminó de procesar los datos de ese destino.

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. Sigue sondeando hasta que el estado alcance un estado terminal.

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

• FAILED: Se produjeron errores en todos los registros del destino. 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 para el 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.

Revisar diagnósticos

Una vez que el request_status de un destino alcance SUCCESS, FAILED o PARTIAL_SUCCESS, revisa los diagnósticos detallados en la respuesta para verificar los recuentos y solucionar problemas.

Verifica el estado de los eventos o públicos por destino

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

• events_ingestion_status

• audience_members_ingestion_status

• audience_members_removal_status

Estado de la transferencia de eventos

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

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

Estado de transferencia de los miembros del público

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

composite_data_ingestion_status

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

Verifica el data_type_counts para confirmar que la cantidad de identificadores coincida con tus expectativas. En esta lista, se desglosan 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.

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

google_user_id_data_ingestion_status

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

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

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 con errores.

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 con errores.

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

partner_provided_id_data_ingestion_status

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

Consulta el partner_provided_id_count para confirmar que la cantidad de IDs proporcionados por el socio que se recibieron 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 con errores.

Consulta el ppid_count para confirmar que la cantidad de PPID recibidos coincida con tus expectativas.

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 con errores.

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 porcentaje de coincidencias para los registros de la solicitud.

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 con errores.

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

Estado de eliminación de los miembros del público

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

composite_data_removal_status

Estado de eliminación de datos compuestos

google_user_id_data_removal_status

Estado de eliminación de los datos del ID de usuario de Google

mobile_data_removal_status

Estado de eliminación de los datos móviles.

pair_data_removal_status

Estado de eliminación de los datos de PAIR.

partner_provided_id_data_removal_status

Estado de eliminación de los datos de ID proporcionados por el socio

ppid_data_removal_status

Es el estado de eliminación de los datos de PPID.

user_data_removal_status

Estado de eliminación de los datos del usuario.

user_id_data_removal_status

Estado de eliminación de los datos del 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 exitosos y fallidos.

Además, verifica user_identifier_count, mobile_id_count, pair_id_count, ppid_count, user_id_count, google_user_id_count o partner_provided_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.

Cómo verificar advertencias y errores

Además de los campos de estado para el destino y el tipo de solicitud, RetrieveRequestStatusResponse contiene un desglose de advertencias y 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 aún procesa el registro con el AdIdentifiers, pero devuelve la advertencia PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.

Sin embargo, si el Event no contiene AdIdentifiers y los datos de UserIdentifier no se pueden desencriptar, la API de Data Manager rechaza todo el registro y informa el error PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR porque un Event 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 completan cuando el estado general del destino alcanza SUCCESS, PARTIAL_SUCCESS o FAILED.

warning_info

Un objeto WarningInfo. Su campo warning_counts contiene una lista de objetos WarningCount. Cada WarningCount contiene lo siguiente:

• reason: Es el tipo de advertencia.

• record_count: Es la cantidad de registros que tuvieron ese tipo de advertencia.

• record_indices: Son los índices de los registros de la solicitud original que tuvieron ese tipo de advertencia. Consulta Verifica los registros afectados.

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

error_info

Un objeto ErrorInfo. Su campo error_counts contiene una lista de objetos ErrorCount. Cada ErrorCount contiene lo siguiente:

• reason: Es el tipo de error.

• record_count: Es la cantidad de registros que fallaron debido a ese tipo de error.

• record_indices: Son los índices de los registros de la solicitud original que fallaron debido a ese tipo de error. Consulta Verifica los registros afectados.

Verifica los registros afectados

Usa el record_indices de cada WarningCount y ErrorCount para identificar los registros exactos de tu solicitud de transferencia que tuvieron advertencias o errores.

Cada valor en record_indices es la posición basada en 0 de un registro en la solicitud original:

• Para un IngestEventsRequest, el índice hace referencia a la posición del evento en la lista events de la solicitud.

• Para un IngestAudienceMembersRequest, el índice se refiere a la posición del miembro del público en la lista audience_members de la solicitud.

Por ejemplo, un valor record_indices de 0 hace referencia al primer evento o miembro del público de la solicitud.

Ten en cuenta lo siguiente cuando analices record_indices:

• Los índices se informan por destino. Si tu solicitud tenía varios destinos, cada RequestStatusPerDestination informa los índices de los registros con advertencias o errores para ese destino. El mismo registro puede aparecer en más de un RequestStatusPerDestination.

• Un registro puede aparecer en más de un motivo. Por ejemplo, un registro puede tener un error y una advertencia, o más de un tipo de advertencia. Para encontrar todos los problemas de un registro determinado, verifica cada WarningCount y ErrorCount del destino.

Este es un RetrieveRequestStatusResponse de ejemplo para un IngestEventsRequest con cinco eventos y un destino. El primer evento (índice 0) y el cuarto evento (índice 3) fallaron porque el ID de transacción ya se había subido, y el tercer evento (índice 2) se procesó, pero tenía un valor de variable personalizada que no está predefinido.

{
  "requestStatusPerDestination": [
    {
      "destination": {
        "operatingAccount": {
          "accountType": "GOOGLE_ADS",
          "accountId": "1234567890"
        },
        "productDestinationId": "123456789"
      },
      "requestStatus": "PARTIAL_SUCCESS",
      "eventsIngestionStatus": {
        "recordCount": "5"
      },
      "errorInfo": {
        "errorCounts": [
          {
            "recordCount": "2",
            "reason": "PROCESSING_ERROR_REASON_DUPLICATE_TRANSACTION_ID",
            "recordIndices": [0, 3]
          }
        ]
      },
      "warningInfo": {
        "warningCounts": [
          {
            "recordCount": "1",
            "reason": "PROCESSING_WARNING_REASON_CUSTOM_VARIABLE_NOT_PREDEFINED",
            "recordIndices": [2]
          }
        ]
      }
    }
  ]
}

Para corregir los registros, sigue estos pasos:

1. Para cada ErrorCount y WarningCount, usa el record_indices para buscar los registros correspondientes en tu solicitud original.

2. Usa el reason para determinar cómo corregir cada registro. Para obtener descripciones de cada motivo, consulta ProcessingErrorReason y ProcessingWarningReason.

3. Envía una nueva solicitud de transferencia que contenga solo los registros corregidos. No vuelvas a enviar los registros que se realizaron correctamente, ya que esto puede generar datos duplicados o errores adicionales.

Estrategia de sondeo

Envía de forma periódica el RetrieveRequestStatusRequest con un algoritmo de retirada exponencial hasta que el request_status alcance SUCCESS, FAILED o PARTIAL_SUCCESS para cada destino en 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:

A continuación, se muestra 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 vuelven a intentarlo al mismo tiempo.

Requisitos de autorización

Un RetrieveRequestStatusRequest no acepta cuentas de destino ni encabezados de solicitud. En cambio, la API de Data Manager identifica los destinos de la solicitud de transferencia original asociada con el request_id y verifica que el emisor tenga acceso al operating_account en cada Destination.

Para verificar el estado de una solicitud, las credenciales que se usan en una RetrieveRequestStatusRequest deben cumplir con los siguientes requisitos para el operating_account de cada destino de la solicitud de transferencia original:

• Ruta de acceso idéntica: Las credenciales deben tener acceso a cada operating_account con la misma ruta de acceso especificada en la solicitud de transferencia original.

  Por ejemplo, si una solicitud de transferencia para un operating_account de Google Ads especificó una cuenta de administrador superior como login_account, las credenciales también deben tener acceso al operating_account a través de esa misma cuenta de administrador. Incluso si la Cuenta de Google asociada con las credenciales tiene acceso directo a la cuenta secundaria de operating_account, la solicitud falla con un error PERMISSION_DENIED si esa cuenta no tiene acceso a través de la cuenta de administrador de login_account especificada durante la transferencia.

• Nivel de acceso suficiente: La Cuenta de Google asociada con las credenciales debe tener un nivel de acceso o un rol con permiso para transferir datos a operating_account.

  Por ejemplo, en Google Ads, la Cuenta de Google debe tener el nivel de acceso de Administrador o Estándar. Una solicitud con credenciales para una cuenta con el nivel de acceso de solo lectura falla con un error PERMISSION_DENIED.