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. Sie können 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 eine Status mit code gleich 0 (Enum-Wert OK, HTTP-Antwort 200 OK) und gibt eine 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. Einige Anfragen werden von der Data Manager API jedoch möglicherweise schon nach 30 Minuten verarbeitet.

Hier sehen Sie ein Beispiel für eine angemessene anfängliche Wartezeit und Wiederholungskonfiguration, bei der die Liveness und die 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 eine Abfolge von Anfragen und der verstrichenen 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 einer 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 Ziels prüfen

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

Hier sind die möglichen Werte für request_status:

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

• SUCCESS: Die Verarbeitung der Anfrage für das Ziel wurde ohne Fehler abgeschlossen. Warnungen prüfen, 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. Prüfen Sie auch, ob während der Verarbeitung Warnungen ausgegeben wurden.

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

Ereignis- oder Zielgruppenstatus nach Zielvorhaben prüfen

Prüfen Sie das Statusfeld, das dem Typ der Aufnahmeanfrage 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 von 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 die einzelnen Arten von Zielgruppendaten geprüft werden muss. Nur eines dieser Felder ist festgelegt.

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.

mobile_data_ingestion_status

Prüfen Sie die record_count der 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 auf der 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 im pair_id_count, ob die Anzahl der erhaltenen PAIR-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_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.

composite_data_ingestion_status

Prüfen Sie die record_count der 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.

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 Sie für jeden Typ von Zielgruppendaten prüfen müssen. Nur eines dieser Felder ist festgelegt.

user_data_removal_status

Entfernungsstatus für Nutzerdaten.

mobile_data_removal_status

Entfernungsstatus für mobile Daten.

pair_data_removal_status

Entfernungsstatus für PAIR-Daten.

ppid_data_removal_status

Entfernungsstatus für PPID-Daten.

user_id_data_removal_status

Entfernungsstatus für Nutzer-ID-Daten

composite_data_removal_status

Entfernungsstatus für zusammengesetzte 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 oder user_id_count, um die Gesamtzahl der empfangenen Kennungen zu bestätigen.

Prüfen Sie bei zusammengesetzten Daten die data_type_counts, um zu bestätigen, dass 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).

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 bedeutet, 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 Ziels SUCCESS, PARTIAL_SUCCESS oder FAILURE erreicht.

warning_info

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

Prüfen Sie die warning_info, auch 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, das die Anzahl der Datensätze angibt, bei denen dieser Fehlertyp aufgetreten ist.