Diagnostyka

Oto zalecany proces sprawdzania stanu przesyłania zdarzeń i list odbiorców oraz identyfikowania problemów z danymi.

  1. Wysyłaj prośby o przesyłanie zdarzeń lub dodawanie bądź usuwanie członków list odbiorców.

  2. Sprawdź ogólny stan każdej prośby. Prawidłowa prośba ma Status z code równym 0 (wartość wyliczeniowa OK, odpowiedź HTTP 200 OK), i zwraca IngestEventsResponse, IngestAudienceMembersResponse lub RemoveAudienceMembersResponse.

    Jeśli prośba nie zostanie zrealizowana, zmodyfikuj ją, aby rozwiązać problem, i wyślij ją ponownie.

    Jeśli prośba zostanie zrealizowana, zapisz request_id z odpowiedzi, aby móc go użyć do pobrania diagnostyki w następnym kroku.

  3. Odczekaj 30 minut, a potem wyślij prośbę RetrieveRequestStatus dla każdego prawidłowego request_id.

    Okresowo powtarzaj ten krok dla każdego request_id, aż stan miejsca docelowego dla każdego miejsca docelowego osiągnie wartość SUCCESS, PARTIAL_SUCCESS, lub FAILURE. Aby odczekać między poszczególnymi prośbami, użyj algorytmu wzrastającego czasu do ponowienia.

  4. Sprawdź każdą odpowiedź RetrieveRequestStatusResponse, aby potwierdzić , że przesyłanie działa prawidłowo, i zidentyfikować problemy z danymi.

  5. Rozwiąż problemy z danymi.

  6. Wróć do kroku 1 i powtarzaj go, aż rozwiążesz wszystkie problemy z przesyłaniem.

Przesyłanie próśb

A RetrieveRequestStatusRequest wymaga pojedynczej request_id wartości. Dla każdego identyfikatora prośby, który został zapisany w odpowiedzi na prawidłową prośbę o pozyskanie, wyślij osobną prośbę o stan.

Okresowo wysyłaj RetrieveRequestStatusRequest za pomocą algorytmu wzrastającego czasu do ponowienia, aż request_status osiągnie wartość SUCCESS, FAILURE lub PARTIAL_SUCCESS dla każdego miejsca docelowego w pierwotnej prośbie. Może to potrwać do 24 godzin, chociaż interfejs Data Manager API może zakończyć przetwarzanie niektórych próśb nawet w 30 minut.

Oto przykład rozsądnego początkowego czasu oczekiwania i konfiguracji ponawiania, która równoważy aktywność i wykorzystanie limitu:

Ustawienie Wartość
Czas oczekiwania przed pierwszą prośbą o diagnostykę (minuty) 30
Mnożnik czasu do ponowienia 1.3
Maksymalny czas do ponowienia (minuty) 60 (1 godzina)
Maksymalny łączny czas (minuty) 1440 (24 godziny)

Oto sekwencja próśb i czas, który upłynął w tej konfiguracji:

Wykres

Strategia odpytywania

Dane

Podejście Czas od wysłania prośby o pozyskanie (gg:mm) Opóźnienie przed próbą Uwagi
1 00:30 30,0 min Pierwsze sprawdzenie dostępności stanu
2 01:09 39,0 min
3 01:59 50,7 min
4 02:59 60,0 min Opóźnienie jest teraz ograniczone do 1 godziny
5 03:59 60,0 min
6 04:59 60,0 min
7 05:59 60,0 min
8 06:59 60,0 min
9 07:59 60,0 min
10 08:59 60,0 min
11 09:59 60,0 min
12 10:59 60,0 min
13 11:59 60,0 min 12 godzin
14 12:59 60,0 min
15 13:59 60,0 min
16 14:59 60,0 min
17 15:59 60,0 min
18 16:59 60,0 min
19 17:59 60,0 min
20 18:59 60,0 min
21 19:59 60,0 min
22 20:59 60,0 min
23 21:59 60,0 min
24 22:59 60,0 min
25 23:59 60,0 min Ostatnia prośba przed upływem maksymalnego łącznego czasu 24 godzin

Dodaj niewielką losową ilość zakłóceń do opóźnień ponawiania , aby zapobiec problemowi „stada grzmiących” polegającemu na tym, że wielu klientów ponawia próbę jednocześnie.

Sprawdzanie odpowiedzi

Pole request_status_per_destination w RetrieveRequestStatusResponse zawiera osobny wpis dla każdego miejsca docelowego w odpowiedniej prośbie o pozyskanie.

Jeśli na przykład IngestAudienceMembersRequest zawierał 3 wpisy na liście destinations, aby wysłać dane do 3 różnych list odbiorców, odpowiedź o stanie będzie zawierać 3 wpisy w request_status_per_destination (po jednym na każdą listę odbiorców).

Sprawdzanie ogólnego stanu miejsca docelowego

W pierwszym kroku sprawdź pole request_status, aby określić, czy interfejs Data Manager API zakończył przetwarzanie danych dla destination w RequestStatusPerDestination.

Oto możliwe wartości request_status:

Sprawdzanie stanu zdarzenia lub listy odbiorców w zależności od miejsca docelowego

Sprawdź pole stanu odpowiadające typowi prośby o pozyskanie. W każdym RequestStatusPerDestination ustawione jest tylko jedno z tych pól:

Stan pozyskiwania zdarzeń

Pole events_ingestion_status jest wypełniane, jeśli prośba była IngestEventsRequest.

Sprawdź record_count w IngestEventStatus , aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z Twoimi oczekiwaniami. record_count obejmuje zarówno rekordy przetworzone, jak i nieprzetworzone.

Stan pozyskiwania członków listy odbiorców

Pole audience_members_ingestion_status jest wypełniane, jeśli prośba była IngestAudienceMembersRequest. Oto pole IngestAudienceMembersStatus, które należy sprawdzić w przypadku każdego typu danych o odbiorcach. Ustawione jest tylko jedno z tych pól.

user_data_ingestion_status

Sprawdź record_count w IngestUserDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z Twoimi oczekiwaniami. record_count obejmuje zarówno rekordy przetworzone, jak i nieprzetworzone.

Sprawdź user_identifier_count, aby potwierdzić, że liczba identyfikatorów użytkowników otrzymanych jest zgodna z Twoimi oczekiwaniami.

Jeśli prośba zawierała wystarczającą liczbę rekordów, the upload_match_rate_range zawiera współczynnik dopasowania zakres rekordów w prośbie.

mobile_data_ingestion_status

Sprawdź record_count w IngestMobileDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z Twoimi oczekiwaniami. record_count obejmuje zarówno rekordy przetworzone, jak i nieprzetworzone.

Sprawdź mobile_id_count, aby potwierdzić, że liczba otrzymanych identyfikatorów mobilnych jest zgodna z Twoimi oczekiwaniami.

pair_data_ingestion_status

Sprawdź record_count w IngestPairDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z Twoimi oczekiwaniami. record_count obejmuje zarówno rekordy przetworzone, jak i nieprzetworzone.

Sprawdź pair_id_count, aby potwierdzić, że liczba otrzymanych identyfikatorów PAIR jest zgodna z Twoimi oczekiwaniami.

ppid_data_ingestion_status

Sprawdź record_count w IngestPpidDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z Twoimi oczekiwaniami. record_count obejmuje zarówno rekordy przetworzone, jak i nieprzetworzone.

Sprawdź ppid_count, aby potwierdzić, że liczba otrzymanych identyfikatorów PPID jest zgodna z Twoimi oczekiwaniami.

user_id_data_ingestion_status

Sprawdź record_count w IngestUserIdDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z Twoimi oczekiwaniami. record_count obejmuje zarówno rekordy przetworzone, jak i nieprzetworzone.

Sprawdź user_id_count, aby potwierdzić, że liczba otrzymanych identyfikatorów użytkowników jest zgodna z Twoimi oczekiwaniami.

Stan usuwania członków listy odbiorców

Pole audience_members_removal_status jest wypełniane, jeśli prośba była RemoveAudienceMembersRequest. Oto pole RemoveAudienceMembersStatus, które należy sprawdzić w przypadku każdego typu danych o odbiorcach. Ustawione jest tylko jedno z tych pól.

user_data_removal_status
Stan usuwania danych użytkownika.
mobile_data_removal_status
Stan usuwania danych mobilnych.
pair_data_removal_status
Stan usuwania danych PAIR.
ppid_data_removal_status
Stan usuwania danych PPID.
user_id_data_removal_status
Stan usuwania danych identyfikatora użytkownika

Sprawdź record_count, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z Twoimi oczekiwaniami. record_count obejmuje zarówno rekordy przetworzone, jak i nieprzetworzone.

Dodatkowo sprawdź user_identifier_count, mobile_id_count lub pair_id_count, aby potwierdzić łączną liczbę otrzymanych identyfikatorów użytkowników, identyfikatorów mobilnych lub identyfikatorów PAIR.

Sprawdzanie ostrzeżeń i błędów

Oprócz pól stanu miejsca docelowego i typu prośby RetrieveRequestStatusResponse zawiera zestawienie ostrzeżeń i błędów dotyczących prośby.

  • Błąd oznacza, że interfejs API całkowicie odrzucił rekord.
  • Ostrzeżenie oznacza, że interfejs API nie odrzucił rekordu, ale musiał zignorować części danych rekordu.

Jeśli na przykład Event dotyczące konwersji offline w Google Ads zawiera zaszyfrowane UserIdentifier dane i AdIdentifiers takie jak gclid, a danych UserIdentifier nie można odszyfrować, interfejs Data Manager API nadal przetwarza rekord za pomocą AdIdentifiers, ale zwraca ostrzeżenie PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.

Jeśli jednak Event nie zawiera AdIdentifiers, a danych UserIdentifier nie można odszyfrować, interfejs Data Manager API odrzuca cały rekord i zgłasza błąd PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR, ponieważ prawidłowy Event konwersji offline w Google Ads musi zawierać co najmniej jeden z tych elementów: ad_identifiers lub user_data.

Oto pola odpowiedzi, które zawierają informacje o ostrzeżeniach i błędach. Te pola są wypełniane, gdy ogólny stan miejsca docelowego osiągnie wartość SUCCESS, PARTIAL_SUCCESS, lub FAILURE.

warning_info

Lista obiektów WarningCount. Każdy WarningCount zawiera reason z typem ostrzeżenia oraz record_count wskazujący liczbę rekordów, które zawierały ten typ ostrzeżenia.

Sprawdź warning_info, nawet jeśli ogólny stan miejsca docelowego to SUCCESS.

error_info

Lista obiektów ErrorCount. Każdy ErrorCount zawiera reason z typem błędu oraz record_count wskazujący liczbę rekordów, które nie powiodły się z powodu tego typu błędu.