Sprawdzanie stanu żądania i diagnostyki

Żądania wysyłania zdarzeń lub odbiorców są przetwarzane asynchronicznie. Odpowiedź o pomyślnym przetworzeniu zwraca kod request_id i wskazuje, że żądanie spełniło wszystkie wymagania i zostało zaakceptowane do przetworzenia. Nie wskazuje jednak, czy rekordy w żądaniu zostały przetworzone.

Użyj zwróconego identyfikatora request_id z RetrieveRequestStatus, aby sprawdzić stan przesłanych danych i wyświetlić dane diagnostyczne.

Oto zalecany sposób sprawdzania stanu żądań oraz stanu przesłanych zdarzeń i list odbiorców:

  1. Wysyłaj żądania, aby wysyłać zdarzenia lub wysyłać bądź usuwać odbiorców.

  2. Sprawdź ogólny stan każdej prośby o pozyskanie. Prawidłowe żądanie ma Status z code równym 0 (wartość typu wyliczeniowego OK, odpowiedź HTTP 200 OK) i zwraca IngestEventsResponse, IngestAudienceMembersResponse lub RemoveAudienceMembersResponse.

    Jeśli żądanie nie powiedzie się, zmodyfikuj je, aby rozwiązać problem, i wyślij je ponownie.

    Jeśli żądanie się powiedzie, przechwyć request_id odpowiedzi, aby użyć go do sprawdzenia stanu przetwarzania w następnym kroku.

  3. Zaczekaj 30 minut, a następnie wyślij żądanie RetrieveRequestStatus dla każdego udanego żądania request_id.

    RetrieveRequestStatusRequest wymaga pojedynczej wartości request_id. Wyślij osobne żądanie stanu dla każdego identyfikatora żądania, który został przechwycony z udanego żądania przetwarzania.

    Powtarzaj ten krok okresowo dla każdego request_id, aż stan miejsca docelowego dla każdego miejsca docelowego osiągnie wartość SUCCESS, PARTIAL_SUCCESS lub FAILURE. Postępuj zgodnie z zalecaną strategią odpytywania, aby odczekać między poszczególnymi żądaniami.

  4. Sprawdź każdy RetrieveRequestStatusResponse, aby upewnić się, że przesyłanie działa prawidłowo, i wykryć ewentualne problemy z danymi.

  5. Rozwiąż problemy z danymi.

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

Sprawdzanie ogólnego stanu miejsca docelowego

Plik request_status_per_destination w RetrieveRequestStatusResponse zawiera osobny wpis dla każdego miejsca docelowego w odpowiednim żądaniu pozyskiwania.

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ź dotycząca stanu będzie zawierać 3 wpisy w request_status_per_destination (po 1 wpisie na każdą listę odbiorców).

Sprawdź pole request_status w każdym obiekcie RequestStatusPerDestination, aby się dowiedzieć, czy interfejs Data Manager API zakończył przetwarzanie danych dla danego miejsca docelowego.

Oto możliwe wartości parametru request_status:

  • PROCESSING: dane dotyczące miejsca docelowego są nadal przetwarzane. Na tym etapie ostrzeżenia i błędy nie są wypełniane dla miejsca docelowego. Kontynuuj odpytywanie, aż stan osiągnie stan końcowy.

  • SUCCESS: przetwarzanie żądania dla miejsca docelowego zostało zakończone bez błędów. Sprawdź, czy nie ma ostrzeżeń oznaczonych podczas przetwarzania.

  • FAILURE: wszystkie rekordy dla miejsca docelowego nie zostały przesłane z powodu błędów. Sprawdź ostrzeżenia i błędy, aby dowiedzieć się, dlaczego nie udało się przesłać wszystkich rekordów. Sprawdź też, czy podczas przetwarzania nie pojawiły się ostrzeżenia.

  • PARTIAL_SUCCESS: niektóre rekordy dla miejsca docelowego zostały utworzone, ale inne nie zostały utworzone z powodu błędów. Sprawdź błędy, aby dowiedzieć się, dlaczego nie udało się zaimportować niektórych rekordów. Sprawdź też, czy podczas przetwarzania nie pojawiły się ostrzeżenia.

Sprawdź diagnostykę

Gdy request_status dla miejsca docelowego osiągnie wartość SUCCESS, FAILURE lub PARTIAL_SUCCESS, sprawdź szczegółowe dane diagnostyczne w odpowiedzi, aby zweryfikować liczbę i rozwiązać problemy.

Sprawdzanie stanu zdarzenia lub listy odbiorców według miejsca docelowego

Sprawdź pole stanu, które odpowiada typowi żądania pozyskiwania. W każdym obiekcie RequestStatusPerDestination ustawione jest tylko jedno z tych pól:

Stan pozyskiwania zdarzeń

Pole events_ingestion_status jest wypełniane, jeśli żądanie było IngestEventsRequest.

Sprawdź pole record_count w IngestEventStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z oczekiwaniami. record_count zawiera zarówno udane, jak i nieudane próby.

Stan pozyskiwania odbiorców

Pole audience_members_ingestion_status jest wypełniane, jeśli żądanie było 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.

composite_data_ingestion_status

Sprawdź record_count w IngestCompositeDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z oczekiwaniami. Plik record_count zawiera zarówno rekordy, które udało się przesłać, jak i te, których nie udało się przesłać.

Sprawdź data_type_counts, aby potwierdzić, że liczba identyfikatorów jest zgodna z oczekiwaniami. Ta lista zawiera zestawienie wszystkich identyfikatorów (takich jak adres e-mail, numer telefonu, adres pocztowy i adres IP) otrzymanych przez DataType.

Jeśli żądanie zawierało wystarczającą liczbę rekordów, upload_match_rate_range zawiera zakres współczynnika dopasowania dla rekordów w żądaniu.

google_user_id_data_ingestion_status

Sprawdź w polu record_count w IngestGoogleUserIdDataStatus, czy łączna liczba otrzymanych rekordów jest zgodna z Twoimi oczekiwaniami. Plik record_count zawiera zarówno rekordy, które udało się przesłać, jak i te, których nie udało się przesłać.

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

mobile_data_ingestion_status

Sprawdź record_count w IngestMobileDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z oczekiwaniami. Plik record_count zawiera zarówno rekordy, które udało się przesłać, jak i te, których nie udało się przesłać.

Sprawdź mobile_id_count, aby potwierdzić, że liczba otrzymanych dokumentów Mobile ID 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 oczekiwaniami. Plik record_count zawiera zarówno udane, jak i nieudane próby.

Sprawdź w pair_id_count, czy liczba otrzymanych identyfikatorów PAIR jest zgodna z oczekiwaną.

partner_provided_id_data_ingestion_status

Sprawdź pole record_count w IngestPartnerProvidedIdDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z oczekiwaniami. Plik record_count zawiera zarówno udane, jak i nieudane rekordy.

Sprawdź partner_provided_id_count, aby potwierdzić, że liczba otrzymanych identyfikatorów dostarczonych przez partnera jest zgodna z oczekiwaniami.

ppid_data_ingestion_status

Sprawdź record_count w IngestPpidDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z oczekiwaniami. Plik record_count zawiera zarówno udane, jak i nieudane próby.

Sprawdź ppid_count, aby upewnić się, że liczba otrzymanych identyfikatorów PPID jest zgodna z oczekiwaniami.

user_data_ingestion_status

Sprawdź record_count w IngestUserDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z oczekiwaniami. Plik record_count zawiera zarówno udane, jak i nieudane próby.

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

Jeśli żądanie zawierało wystarczającą liczbę rekordów, upload_match_rate_range zawiera zakres współczynnika dopasowania dla rekordów w żądaniu.

user_id_data_ingestion_status

Sprawdź pole record_count w IngestUserIdDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z oczekiwaniami. Plik record_count zawiera zarówno udane, jak i nieudane próby.

Sprawdź w user_id_count, czy liczba otrzymanych identyfikatorów użytkowników jest zgodna z oczekiwaną.

Stan usuwania członków grupy odbiorców

Pole audience_members_removal_status jest wypełniane, jeśli żądanie było 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.

composite_data_removal_status
Stan usunięcia danych wieloskładnikowych
google_user_id_data_removal_status
Stan usunięcia danych identyfikatora użytkownika Google
mobile_data_removal_status
Stan usunięcia mobilnej transmisji danych.
pair_data_removal_status
Stan usunięcia danych PAIR.
partner_provided_id_data_removal_status
Stan usunięcia danych identyfikatora podanego przez partnera
ppid_data_removal_status
Stan usunięcia danych PPID.
user_data_removal_status
Stan usunięcia danych użytkownika.
user_id_data_removal_status
Stan usunięcia danych identyfikatora użytkownika

Sprawdź w polu record_count, czy łączna liczba otrzymanych rekordów jest zgodna z Twoimi oczekiwaniami. Plik record_count zawiera zarówno rekordy, które udało się przesłać, jak i te, których nie udało się przesłać.

Sprawdź też user_identifier_count, mobile_id_count, pair_id_count, ppid_count, user_id_count, google_user_id_count lub partner_provided_id_count, aby potwierdzić łączną liczbę otrzymanych identyfikatorów.

W przypadku danych złożonych sprawdź data_type_counts, aby potwierdzić, że liczba identyfikatorów jest zgodna z oczekiwaniami. Ta lista zawiera zestawienie wszystkich identyfikatorów (takich jak adres e-mail, numer telefonu, adres pocztowy i adres IP) otrzymanych przez DataType.

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

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

  • Błąd oznacza, że interfejs API całkowicie odrzucił rekord.

  • Ostrzeżenie oznacza, że interfejs API nie odrzucił rekordu, ale musiał zignorować jego części.

Jeśli np. Event zawiera zaszyfrowane dane UserIdentifier i AdIdentifiers, takie jak gclid, a danych UserIdentifier nie można odszyfrować, interfejs Data Manager API nadal przetwarza rekord, używając AdIdentifiers, ale zwraca ostrzeżenie PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.

Jeśli jednak Event nie zawiera AdIdentifiers i nie można odszyfrować danych UserIdentifier, interfejs Data Manager API odrzuca cały rekord i zgłasza błąd PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR, ponieważ prawidłowy Event musi zawierać co najmniej 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

Obiekt WarningInfo. Pole warning_counts zawiera listę obiektów WarningCount. Każdy element WarningCount zawiera element reason z typem ostrzeżenia i element record_count wskazujący liczbę rekordów, które miały ten typ ostrzeżenia.

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

error_info

Obiekt ErrorInfo. Pole error_counts zawiera listę obiektów ErrorCount. Każdy element ErrorCount zawiera element reason z typem błędu oraz element record_count wskazujący liczbę rekordów, które nie zostały przetworzone z powodu tego typu błędu.

Strategia odpytywania

Okresowo wysyłaj RetrieveRequestStatusRequest, używając algorytmu wzrastającego czasu do ponowienia, dopóki request_status nie osiągnie stanu SUCCESS, FAILURE lub PARTIAL_SUCCESS dla każdego miejsca docelowego w pierwotnym żądaniu. Może to potrwać do 24 godzin, chociaż interfejs Data Manager API może zakończyć przetwarzanie niektórych żądań w ciągu zaledwie 30 minut.

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

Ustawienie Wartość
Czas oczekiwania przed pierwszym żądaniem diagnostyki (w minutach) 30
Mnożnik ponawiania 1.3
Maksymalny czas do ponowienia (w minutach) 60 (1 godzina)
Maksymalny łączny czas (w minutach) 1440 (24 godziny)

Oto sekwencja żądań i czas, który upłynął, przy tej konfiguracji:

Wykres

Strategia odpytywania

Dane

Podejście Czas od żądania pozyskania (gg:mm) Opóźnienie przed próbą Uwagi
1 00:30 30,0 min Najpierw sprawdź dostępność 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 Ostatnie żądanie przed upływem maksymalnego łącznego czasu 24 godzin

Dodaj niewielką losową wartość jittera do opóźnień wycofywania, aby zapobiec problemowi „grzmiącego stada”, gdy wielu klientów ponawia próbę jednocześnie.

Wymagania dotyczące autoryzacji

RetrieveRequestStatusRequest nie akceptuje kont docelowych ani nagłówków żądań. Zamiast tego interfejs Data Manager API identyfikuje miejsca docelowe z pierwotnego żądania pozyskania danych powiązanego z request_id i sprawdza, czy wywołujący ma dostęp do operating_account w każdym Destination.

Aby sprawdzić stan żądania, dane logowania użyte w RetrieveRequestStatusRequest muszą spełniać te wymagania dotyczące operating_account każdego miejsca docelowego z pierwotnego żądania przetwarzania:

  • Identyczna ścieżka dostępu: dane logowania muszą mieć dostęp do każdego elementu operating_account przy użyciu dokładnie tej samej ścieżki dostępu, która została określona w pierwotnym żądaniu pozyskiwania.

    Jeśli na przykład żądanie pozyskania danych dla operating_account Google Ads określało konto menedżera nadrzędnego jako login_account, dane logowania muszą też mieć dostęp do operating_account przez to samo konto menedżera. Nawet jeśli konto Google powiązane z danymi logowania ma bezpośredni dostęp do podrzędnego konta operating_account, żądanie nie powiedzie się i zostanie zwrócony błąd PERMISSION_DENIED, jeśli to konto nie ma dostępu przez konto menedżera login_account określone podczas przetwarzania.

  • Wystarczający poziom dostępu: konto Google powiązane z danymi logowania musi mieć poziom dostępu lub rolę z uprawnieniami do pozyskiwania danych w operating_account.

    Na przykład w Google Ads konto Google musi mieć poziom dostępu Administrator lub Standardowy. Żądanie z danymi logowania do konta z poziomem dostępu Tylko do odczytu kończy się błędem PERMISSION_DENIED.

Wstecz
Zaszyfruj dane użytkownika
Dalej
Informacje o błędach interfejsu API