Diagnostics

  • Issue requests to send events or manage audience members.

  • Check the overall status of each request, modifying and resending if unsuccessful.

  • Send a RetrieveRequestStatus request for successful requests using the captured request_id.

  • Review the RetrieveRequestStatusResponse to confirm uploads are working and identify data issues.

  • Correct data issues and repeat the process until all issues are resolved.

Here's the recommended workflow to verify the health of your event and audience uploads and identify issues with your data.

  1. Issue requests to send events or send or remove audience members.

  2. Check the overall status of each request. A successful request has a Status with code equal to 0 (enum value OK, HTTP response 200 OK), and returns a IngestEventsResponse, IngestAudienceMembersResponse, or RemoveAudienceMembersResponse.

    If a request isn't successful, modify the request to address the error and send the request again.

    If a request succeeds, capture the response's request_id so you can use it to retrieve diagnostics in the next step.

  3. Send a RetrieveRequestStatus request for each successful request_id.

  4. Review each RetrieveRequestStatusResponse to confirm your uploads are working properly and identify any issues with your data.

  5. Correct data issues.

  6. Go back to step 1 and repeat until you've addressed all issues with your uploads.

Construct requests

A RetrieveRequestStatusRequest has a single request_id field. Send one request for each successful request ID you captured when sending ingestion requests.

Review responses

The request_status_per_destination in a RetrieveRequestStatusResponse contains a separate entry for each destination in the corresponding ingestion request.

For example, if your IngestAudienceMembersRequest contained 3 entries in the destinations list to send data to 3 different audiences, then the status response would contain 3 entries in request_status_per_destination (one entry per audience).

Check overall destination status

As a first step, check the request_status field to determine if the Data Manager API has finished processing the data for the destination of the RequestStatusPerDestination. Here are the possible values of request_status:

  • PROCESSING: The data for the destination is still being processed.
  • SUCCESS: Request processing for the destination completed without any errors.
  • FAILURE: All of the records for the destination failed due to errors.
  • PARTIAL_SUCCESS: Some of the records for the destination succeeded, but others failed due to errors.

Check event or audience status per destination

Inspect the status field that corresponds to the type of ingestion request. Only one of the following fields is set on each RequestStatusPerDestination:

Events ingestion status

The events_ingestion_status field is populated if the request was an IngestEventsRequest.

Check the record_count of the IngestEventStatus to confirm that the total number of records received matches your expectations. The record_count includes both successful and failed records.

Audience members ingestion status

The audience_members_ingestion_status field is populated if the request was an IngestAudienceMembersRequest. Here's the IngestAudienceMembersStatus field to check for each type of audience data. Only one of these fields is set.

user_data_ingestion_status

Check the record_count of the IngestUserDataStatus to confirm that the total number of records received matches your expectations. The record_count includes both successful and failed records.

Check the user_identifier_count to confirm the number of user identifiers received matches your expectations.

If the request had a sufficient number of records, the upload_match_rate_range contains the match rate range for records in the request.

mobile_data_ingestion_status

Check the record_count of the IngestMobileDataStatus to confirm that the total number of records received matches your expectations. The record_count includes both successful and failed records.

Check the mobile_id_count to confirm the number of mobile IDs received matches your expectations.

pair_data_ingestion_status

Check the record_count of the IngestPairDataStatus to confirm that the total number of records received matches your expectations. The record_count includes both successful and failed records.

Check the pair_id_count to confirm the number of PAIR IDs received matches your expectations.

Audience members removal status

The audience_members_removal_status field is populated if the request was a RemoveAudienceMembersRequest. Here's the RemoveAudienceMembersStatus field to check for each type of audience data. Only one of these fields is set.

user_data_removal_status
Removal status for user data.
mobile_data_removal_status
Removal status for mobile data.
pair_data_removal_status
Removal status for PAIR data.

Check the record_count to confirm that the total number of records received matches your expectations. The record_count includes both successful and failed records.

In addition, check the user_identifier_count, mobile_id_count, or pair_id_count to confirm the total count of user identifiers, mobile IDs, or PAIR IDs received.

Check warnings and errors

In addition to the status fields for the destination and request type, the RetrieveRequestStatusResponse contains a breakdown of warnings and errors for the request.

  • An error indicates that the API completely rejected the record.
  • A warning indicates that the API didn't reject the record, but it had to ignore portions of the record's data.

For example, if an Event contains encrypted UserIdentifier data and AdIdentifiers such as gclid, and the UserIdentifier data can't be decrypted, the Data Manager API still processes the record using the AdIdentifiers but returns the warning PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.

However, if the Event doesn't contain AdIdentifiers and the UserIdentifier data can't be decrypted, the Data Manager API rejects the entire record and reports the error PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR because a valid Event must have at least one of ad_identifiers or user_data.

Here are the response fields that contain warning and error information.

warning_info
A list of WarningCount objects. Each WarningCount contains a reason with the type of warning, and a record_count indicating the number of records that had warnings of that type.
error_info
A list of ErrorCount objects. Each ErrorCount contains a reason with the type of error, and a record_count indicating the number of records that failed due to that type of error.