Diagnose

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

1. Senden Sie Anfragen, um Ereignisse zu senden oder Zielgruppenmitglieder hinzuzufügen oder zu entfernen.

2. Prüfen Sie den Gesamtstatus jeder Anfrage. 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 die Anfrage, um den Fehler zu beheben, und senden Sie die Anfrage 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 Ziel status 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 ermitteln.

5. Beheben Sie Datenprobleme.

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

Anfragen senden

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

Senden Sie die RetrieveRequestStatusRequest regelmäßig mit einem exponentiellen Backoff-Algorithmus, bis der request_status SUCCESS, FAILURE oder PARTIAL_SUCCESS für jedes Ziel in der ursprünglichen Anfrage erreicht. Das kann bis zu 24 Stunden dauern. Die Data Manager API kann jedoch einige Anfragen in nur 30 Minuten verarbeiten.

Hier sehen Sie ein Beispiel für eine angemessene anfängliche Wartezeit und eine Konfiguration für Wiederholungsversuche, die ein Gleichgewicht zwischen Liveness und Kontingentnutzung schafft:

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 sehen Sie eine Abfolge von Anfragen und die verstrichene Zeit mit dieser Konfiguration:

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

Antworten überprüfen

Die request_status_per_destination in einer RetrieveRequestStatusResponse enthält einen separaten Eintrag für jedes Ziel in der entsprechenden Aufnahme-Anfrage.

Wenn Ihre IngestAudienceMembersRequest drei Einträge in der Liste destinations enthielt, 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 request_status Feld, um festzustellen, ob die Data Manager API die Verarbeitung der Daten für das destination der RequestStatusPerDestination abgeschlossen 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 ausgefüllt.

• SUCCESS: Die Verarbeitung der Anfrage für das Ziel wurde ohne Fehler abgeschlossen. Prüfen Sie, ob Warnungen während der Verarbeitung gemeldet wurden.

• FAILURE: Alle Datensätze für das Ziel sind aufgrund von Fehlern fehlgeschlagen. Prüfen Sie, ob Warnungen und Fehler vorliegen, um festzustellen, warum alle Datensätze fehlgeschlagen sind. Prüfen Sie außerdem, ob während der Verarbeitung Warnungen gemeldet wurden.

• PARTIAL_SUCCESS: Einige Datensätze für das Ziel waren erfolgreich, andere sind jedoch aufgrund von Fehlern fehlgeschlagen. Prüfen Sie, ob Fehler vorliegen, um festzustellen, warum einige Datensätze fehlgeschlagen sind. Prüfen Sie außerdem, ob während der Verarbeitung Warnungen gemeldet wurden.

Status von Ereignissen oder Zielgruppen pro Ziel prüfen

Prüfen Sie das Statusfeld, das dem Typ der Aufnahme-Anfrage entspricht. Für jede RequestStatusPerDestination wird 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 record_count der IngestEventStatus , um zu bestätigen, dass die Gesamtzahl der empfangenen Datensätze Ihren Erwartungen entspricht. record_count umfasst 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 sehen Sie das IngestAudienceMembersStatus Feld, das für jeden Typ von Zielgruppendaten geprüft werden muss. Nur eines dieser Felder ist festgelegt.

user_data_ingestion_status

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

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

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

mobile_data_ingestion_status

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

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

pair_data_ingestion_status

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

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

ppid_data_ingestion_status

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

Prüfen Sie ppid_count, um zu bestätigen, dass die Anzahl der empfangenen PPIDs Ihren Erwartungen entspricht.

user_id_data_ingestion_status

Prüfen Sie record_count der IngestUserIdDataStatus, um zu bestätigen, dass die Gesamtzahl der empfangenen Datensätze Ihren Erwartungen entspricht. record_count umfasst 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 der Entfernung von Zielgruppenmitgliedern

Das Feld audience_members_removal_status wird ausgefüllt, wenn die Anfrage eine RemoveAudienceMembersRequest war. Hier sehen Sie das RemoveAudienceMembersStatus Feld, das für jeden Typ von Zielgruppendaten geprüft werden muss. 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

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

Prüfen Sie außerdem user_identifier_count, mobile_id_count oder pair_id_count, um die Gesamtzahl der empfangenen Nutzerkennungen, Mobilgeräte-IDs oder PAIR-IDs zu bestätigen.

Warnungen und Fehler prüfen

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

• Ein Fehler gibt an, dass die API den Datensatz vollständig abgelehnt hat.
• Eine Warnung gibt an, dass die API den Datensatz nicht abgelehnt hat, aber Teile der Daten des Datensatzes ignorieren musste.

Wenn ein Event für eine Google Ads-Offline-Conversion beispielsweise verschlüsselte UserIdentifier-Daten und AdIdentifiers wie gclid enthält und die UserIdentifier-Daten nicht entschlüsselt werden können, verarbeitet die Data Manager API den Datensatz trotzdem mit den AdIdentifiers, gibt aber die Warnung PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR zurück.

Wenn das Event jedoch keine 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ültiges Event für die Google Ads-Offline-Conversion mindestens eines der Felder ad_identifiers oder user_data enthalten muss.

Hier sehen Sie die Antwortfelder, die Warnungs- und Fehlerinformationen enthalten. Diese Felder werden ausgefüllt, wenn der Gesamtstatus des Ziels erreicht SUCCESS, PARTIAL_SUCCESS, oder FAILURE.

warning_info

Eine Liste von WarningCount-Objekten. Jede WarningCount enthält einen reason mit dem Typ der Warnung und eine record_count mit der Anzahl der Datensätze, die diese Art von Warnung hatten.

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

error_info

Eine Liste von ErrorCount-Objekten. Jede ErrorCount enthält einen reason mit dem Typ des Fehlers und eine record_count mit der Anzahl der Datensätze, die aufgrund dieses Fehlertyps fehlgeschlagen sind.