Diagnose

Hier finden Sie den empfohlenen Workflow, um den Status Ihrer Event- und Zielgruppen-Uploads zu prüfen und Probleme mit Ihren Daten zu ermitteln.

1. Anfragen zum Senden von Ereignissen oder zum Senden oder Entfernen von Zielgruppenmitgliedern stellen.

2. Prüfen Sie den Gesamtstatus der einzelnen Anfragen. Eine erfolgreiche Anfrage hat ein Status mit code gleich 0 (Enum-Wert OK, HTTP-Antwort 200 OK) und gibt ein IngestEventsResponse, IngestAudienceMembersResponse oder RemoveAudienceMembersResponse zurück.

   Wenn eine Anfrage nicht erfolgreich ist, ändern Sie sie, um den Fehler zu beheben, und senden Sie sie noch einmal.

   Wenn eine Anfrage erfolgreich ist, erfassen Sie die request_id der Antwort, damit Sie sie im nächsten Schritt zum Abrufen von Diagnosedaten verwenden können.

3. Warten Sie 30 Minuten und senden Sie dann für jede erfolgreiche request_id eine RetrieveRequestStatus-Anfrage.

   Wiederholen Sie diesen Schritt regelmäßig für jede request_id, bis der Zielstatus für jedes Ziel SUCCESS, PARTIAL_SUCCESS oder FAILURE erreicht. Verwenden Sie einen exponentiellen Backoff-Algorithmus, um zwischen den einzelnen Anfragen zu warten.

4. Prüfen Sie jede RetrieveRequestStatusResponse, um zu bestätigen, dass Ihre Uploads ordnungsgemäß funktionieren, und um Probleme mit Ihren Daten zu erkennen.

5. Datenprobleme beheben

6. Kehren Sie zu Schritt 1 zurück und wiederholen Sie die Schritte, bis Sie alle Probleme mit Ihren Uploads behoben haben.

Anfragen senden

Für RetrieveRequestStatusRequest ist ein einzelner request_id-Wert erforderlich. Senden Sie für jede Anfrage-ID, die Sie aus einer erfolgreichen Aufnahme-Anfrage erhalten haben, eine separate Statusanfrage.

Senden Sie die RetrieveRequestStatusRequest regelmäßig mit einem exponentiellen Backoff-Algorithmus, bis die request_status für jedes Ziel in der ursprünglichen Anfrage SUCCESS, FAILURE oder PARTIAL_SUCCESS erreicht. Das kann bis zu 24 Stunden dauern. Bei einigen Anfragen kann die Verarbeitung über die Data Manager API jedoch auch schon nach 30 Minuten abgeschlossen sein.

Hier sehen Sie ein Beispiel für eine angemessene anfängliche Wartezeit und Wiederholungskonfiguration, bei der Aktivität und Kontingentnutzung im Gleichgewicht sind:

Einstellung	Wert
Wartezeit vor der ersten Diagnoseanfrage (Minuten)	30
Backoff-Multiplikator	1.3
Maximaler Backoff (Minuten)	60 (1 Stunde)
Maximale Gesamtzeit (Minuten)	1440 (24 Stunden)

Hier ist eine Sequenz von Anfragen und verstrichener Zeit mit dieser Konfiguration:

Fügen Sie den Backoff-Verzögerungen eine kleine zufällige Menge an Jitter hinzu, um das „Thundering Herd“-Problem zu vermeiden, bei dem viele Clients gleichzeitig Wiederholungsversuche starten.

Antworten überprüfen

Die request_status_per_destination in einem RetrieveRequestStatusResponse enthält einen separaten Eintrag für jedes Ziel in der entsprechenden Erfassungsanfrage.

Wenn Ihr IngestAudienceMembersRequest beispielsweise drei Einträge in der Liste destinations enthält, um Daten an drei verschiedene Zielgruppen zu senden, enthält die Statusantwort drei Einträge in request_status_per_destination (einen Eintrag pro Zielgruppe).

Gesamtstatus des Zielvorhabens prüfen

Prüfen Sie zuerst das Feld request_status, um festzustellen, ob die Data Manager API die Daten für den destination des RequestStatusPerDestination verarbeitet hat.

Folgende Werte sind für request_status möglich:

• PROCESSING: Die Daten für das Ziel werden noch verarbeitet. Die Warnungen und Fehler werden für das Ziel in dieser Phase nicht ausgegeben.

• SUCCESS: Die Verarbeitung der Anfrage für das Ziel wurde ohne Fehler abgeschlossen. Nach Warnungen suchen, die während der Verarbeitung gemeldet wurden.

• FAILURE: Alle Datensätze für das Ziel sind aufgrund von Fehlern fehlgeschlagen. Prüfen Sie auf Warnungen und Fehler, um herauszufinden, warum alle Datensätze fehlgeschlagen sind. Sehen Sie auch nach, ob während der Verarbeitung Warnungen ausgegeben wurden.

• PARTIAL_SUCCESS: Einige der Datensätze für das Ziel wurden erfolgreich übertragen, andere sind jedoch aufgrund von Fehlern fehlgeschlagen. Prüfen Sie auf Fehler, um herauszufinden, warum einige Datensätze fehlgeschlagen sind. Prüfen Sie auch, ob während der Verarbeitung Warnungen angezeigt wurden.

Ereignis- oder Zielgruppenstatus nach Zielvorhaben prüfen

Sehen Sie sich das Statusfeld an, das dem Typ des Aufnahmeantrags entspricht. In jedem RequestStatusPerDestination ist nur eines der folgenden Felder festgelegt:

• events_ingestion_status
• audience_members_ingestion_status
• audience_members_removal_status

Status der Ereignisaufnahme

Das Feld events_ingestion_status wird ausgefüllt, wenn die Anfrage eine IngestEventsRequest war.

Prüfen Sie die record_count der IngestEventStatus, um zu bestätigen, dass die Gesamtzahl der empfangenen Datensätze Ihren Erwartungen entspricht. Die record_count enthält sowohl erfolgreiche als auch fehlgeschlagene Datensätze.

Status der Aufnahme von Zielgruppenmitgliedern

Das Feld audience_members_ingestion_status wird ausgefüllt, wenn die Anfrage eine IngestAudienceMembersRequest war. Hier finden Sie das Feld IngestAudienceMembersStatus, das für jeden Typ von Zielgruppendaten geprüft werden muss. Nur eines dieser Felder ist festgelegt.

composite_data_ingestion_status

Prüfen Sie die record_count von IngestCompositeDataStatus, um zu bestätigen, dass die Gesamtzahl der empfangenen Datensätze Ihren Erwartungen entspricht. Die record_count enthält sowohl erfolgreiche als auch fehlgeschlagene Datensätze.

Prüfen Sie auf der Seite data_type_counts, ob die Anzahl der Kennungen Ihren Erwartungen entspricht. In dieser Liste finden Sie eine Aufschlüsselung aller von DataType empfangenen Kennungen (z. B. E‑Mail-Adresse, Telefonnummer, Postanschrift und IP-Adresse).

Wenn die Anfrage eine ausreichende Anzahl von Datensätzen enthielt, enthält upload_match_rate_range den Bereich der Abgleichsrate für Datensätze in der Anfrage.

google_user_id_data_ingestion_status

Prüfen Sie die record_count der IngestGoogleUserIdDataStatus, um zu bestätigen, dass die Gesamtzahl der empfangenen Datensätze Ihren Erwartungen entspricht. Die record_count enthält sowohl erfolgreiche als auch fehlgeschlagene Datensätze.

Prüfen Sie google_user_id_count, um zu bestätigen, dass die Anzahl der empfangenen Google-Nutzer-IDs Ihren Erwartungen entspricht.

mobile_data_ingestion_status

Prüfen Sie die record_count von IngestMobileDataStatus, um zu bestätigen, dass die Gesamtzahl der empfangenen Datensätze Ihren Erwartungen entspricht. Die record_count enthält sowohl erfolgreiche als auch fehlgeschlagene Datensätze.

Prüfen Sie im mobile_id_count, ob die Anzahl der empfangenen mobilen IDs Ihren Erwartungen entspricht.

pair_data_ingestion_status

Prüfen Sie die record_count der IngestPairDataStatus, um zu bestätigen, dass die Gesamtzahl der empfangenen Datensätze Ihren Erwartungen entspricht. Die record_count enthält sowohl erfolgreiche als auch fehlgeschlagene Datensätze.

Prüfen Sie pair_id_count, um zu bestätigen, dass die Anzahl der erhaltenen PAIR-IDs Ihren Erwartungen entspricht.

partner_provided_id_data_ingestion_status

Prüfen Sie die record_count der IngestPartnerProvidedIdDataStatus, um zu bestätigen, dass die Gesamtzahl der empfangenen Datensätze Ihren Erwartungen entspricht. Die record_count enthält sowohl erfolgreiche als auch fehlgeschlagene Datensätze.

Prüfen Sie im partner_provided_id_count, ob die Anzahl der empfangenen Partner-IDs Ihren Erwartungen entspricht.

ppid_data_ingestion_status

Prüfen Sie die record_count der IngestPpidDataStatus, um zu bestätigen, dass die Gesamtzahl der empfangenen Datensätze Ihren Erwartungen entspricht. Die record_count enthält sowohl erfolgreiche als auch fehlgeschlagene Datensätze.

Prüfen Sie im ppid_count, ob die Anzahl der empfangenen PPIDs Ihren Erwartungen entspricht.

user_data_ingestion_status

Prüfen Sie die record_count der IngestUserDataStatus, um zu bestätigen, dass die Gesamtzahl der empfangenen Datensätze Ihren Erwartungen entspricht. Die record_count enthält sowohl erfolgreiche als auch fehlgeschlagene Datensätze.

Prüfen Sie user_identifier_count, um zu bestätigen, dass die Anzahl der empfangenen Nutzer-IDs Ihren Erwartungen entspricht.

Wenn die Anfrage eine ausreichende Anzahl von Datensätzen enthielt, enthält upload_match_rate_range den Bereich der Abgleichsrate für Datensätze in der Anfrage.

user_id_data_ingestion_status

Prüfen Sie die record_count der IngestUserIdDataStatus, um zu bestätigen, dass die Gesamtzahl der empfangenen Datensätze Ihren Erwartungen entspricht. Die record_count enthält sowohl erfolgreiche als auch fehlgeschlagene Datensätze.

Prüfen Sie user_id_count, um zu bestätigen, dass die Anzahl der empfangenen Nutzer-IDs Ihren Erwartungen entspricht.

Status des Entfernens von Zielgruppenmitgliedern

Das Feld audience_members_removal_status wird ausgefüllt, wenn die Anfrage eine RemoveAudienceMembersRequest war. Hier sehen Sie das Feld RemoveAudienceMembersStatus, das für jeden Typ von Zielgruppendaten geprüft werden muss. Nur eines dieser Felder ist festgelegt.

composite_data_removal_status

Entfernungsstatus für zusammengesetzte Daten

google_user_id_data_removal_status

Entfernungsstatus für Google-Nutzer-ID-Daten

mobile_data_removal_status

Status der Entfernung für mobile Daten.

pair_data_removal_status

Entfernungsstatus für PAIR-Daten.

partner_provided_id_data_removal_status

Entfernungsstatus für von Partnern bereitgestellte Ausweisdaten

ppid_data_removal_status

Entfernungsstatus für PPID-Daten.

user_data_removal_status

Entfernungsstatus für Nutzerdaten.

user_id_data_removal_status

Entfernungsstatus für Nutzer-ID-Daten

Prüfen Sie record_count, um zu bestätigen, dass die Gesamtzahl der empfangenen Datensätze Ihren Erwartungen entspricht. Die record_count enthält sowohl erfolgreiche als auch fehlgeschlagene Datensätze.

Prüfen Sie außerdem user_identifier_count, mobile_id_count, pair_id_count, ppid_count, user_id_count, google_user_id_count oder partner_provided_id_count, um die Gesamtzahl der empfangenen Kennungen zu bestätigen.

Prüfen Sie bei zusammengesetzten Daten im data_type_counts, ob die Anzahl der Kennungen Ihren Erwartungen entspricht. In dieser Liste finden Sie eine Aufschlüsselung aller von DataType empfangenen Kennungen (z. B. E‑Mail-Adresse, Telefonnummer, Adresse und IP-Adresse).

Warnungen und Fehler prüfen

Zusätzlich zu den Statusfeldern für das Ziel und den Anfragetyp enthält RetrieveRequestStatusResponse eine Aufschlüsselung der Warnungen und Fehler für die Anfrage.

• Ein Fehler bedeutet, dass der Datensatz von der API vollständig abgelehnt wurde.
• Eine Warnung weist darauf hin, dass die API den Datensatz nicht abgelehnt hat, aber Teile der Daten des Datensatzes ignorieren musste.

Wenn ein Event beispielsweise verschlüsselte UserIdentifier-Daten und AdIdentifiers wie gclid enthält und die UserIdentifier-Daten nicht entschlüsselt werden können, wird der Datensatz von der Data Manager API trotzdem mit dem AdIdentifiers verarbeitet, aber die Warnung PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR zurückgegeben.

Wenn Event jedoch nicht AdIdentifiers enthält und die UserIdentifier-Daten nicht entschlüsselt werden können, lehnt die Data Manager API den gesamten Datensatz ab und meldet den Fehler PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR, da ein gültiger Event mindestens ad_identifiers oder user_data enthalten muss.

Hier sind die Antwortfelder, die Warn- und Fehlerinformationen enthalten. Diese Felder werden ausgefüllt, wenn der Gesamtstatus des Zielvorhabens SUCCESS, PARTIAL_SUCCESS oder FAILURE erreicht.

warning_info

Eine Liste von WarningCount-Objekten. Jeder WarningCount enthält ein reason mit dem Typ der Warnung und ein record_count, das die Anzahl der Datensätze mit dieser Art von Warnung angibt.

Prüfen Sie die warning_info auch dann, wenn der Gesamtstatus des Ziels SUCCESS lautet.

error_info

Eine Liste von ErrorCount-Objekten. Jedes ErrorCount enthält ein reason mit dem Fehlertyp und ein record_count mit der Anzahl der Datensätze, bei denen dieser Fehlertyp aufgetreten ist.