Diagnostyka

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

  1. Wysyłaj żądania dotyczące wysyłania zdarzeń lub wysyłania i usuwania członków grup odbiorców.

  2. Sprawdź ogólny stan każdej prośby. Pomyślne żądanie ma Status z code równym 0 (wartość enum 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 pobrania danych diagnostycznych w następnym kroku.

  3. Odczekaj 30 minut, a potem wyślij RetrieveRequestStatus żądanie dla każdego udanego 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. Użyj algorytmu wzrastającego czasu do ponowienia, aby odczekać między kolejnymi żą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 przesyłaniem.

Prześlij prośby

RetrieveRequestStatusRequest wymaga pojedynczej wartości request_id. Wyślij osobną prośbę o stan dla każdego identyfikatora żądania, który został zarejestrowany w ramach udanego żądania przetwarzania.

Autoryzacja

RetrieveRequestStatusRequest nie akceptuje kont docelowych ani nagłówków żądań. Zamiast tego interfejs Data Manager API identyfikuje miejsca docelowe z pierwotnego żądania pozyskania powiązanego z request_id i sprawdza, czy element 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 pozyskiwania danych:

  • 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 nadrzędne konto menedżera 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 usługi operating_account dziecka, żądanie zakończy się niepowodzeniem i wyświetli się błąd PERMISSION_DENIED, jeśli to konto nie ma dostępu za pomocą konta menedżera login_account określonego podczas przesyłania danych.

  • Odpowiedni poziom dostępu: konto Google powiązane z danymi logowania musi mieć poziom dostępu lub rolę z uprawnieniami do przesyłania danych do usługi 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.

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ń już po 30 minutach.

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 czasu do ponowienia 1.3
Maksymalny czas do ponowienia (w minutach) 60 (1 godzina)
Maksymalny łączny czas (minuty) 1440 (24 godziny)

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

Wykres

Strategia sondowania

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 „thundering herd”, w którym wielu klientów ponawia próbę jednocześnie.

Sprawdź odpowiedzi

Pole request_status_per_destination w RetrieveRequestStatusResponse zawiera osobny wpis dla każdego miejsca docelowego w odpowiednim żądaniu przesyłania danych.

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).

Sprawdzanie ogólnego stanu miejsca docelowego

Najpierw sprawdź pole request_status, aby dowiedzieć się, czy interfejs Data Manager API zakończył przetwarzanie danych dla destination w RequestStatusPerDestination.

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.

  • SUCCESS: przetwarzanie żądania w miejscu docelowym zostało ukończone bez błędów. Sprawdź ostrzeżenia oznaczone 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ż ostrzeżenia zgłoszone podczas przetwarzania.

  • PARTIAL_SUCCESS: niektóre rekordy w miejscu docelowym zostały przetworzone, ale inne nie z powodu błędów. Sprawdź błędy, aby dowiedzieć się, dlaczego niektóre rekordy nie zostały przetworzone. Sprawdź też ostrzeżenia oznaczone podczas przetwarzania.

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 przetwarzania zdarzeń

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

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

Stan przesyłania danych o odbiorcach

Pole audience_members_ingestion_status jest wypełniane, jeśli żądanie było IngestAudienceMembersRequest. Oto pole IngestAudienceMembersStatus, w którym możesz sprawdzić każdy typ danych o odbiorcach. Ustawione jest tylko jedno z tych pól.

composite_data_ingestion_status

Sprawdź w polu record_count w IngestCompositeDataStatus, czy łączna liczba otrzymanych rekordów jest zgodna z oczekiwaniami. Pole record_count zawiera zarówno udane, jak i nieudane rekordy.

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

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

google_user_id_data_ingestion_status

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

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

mobile_data_ingestion_status

Sprawdź w polu record_count w IngestMobileDataStatus, czy łączna liczba otrzymanych rekordów jest zgodna z oczekiwaniami. record_count zawiera zarówno udane, jak i nieudane rekordy.

Sprawdź mobile_id_count, aby potwierdzić, że liczba otrzymanych dokumentów Mobile ID jest zgodna z oczekiwaniami.

pair_data_ingestion_status

Sprawdź pole record_count w sekcji IngestPairDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z Twoimi 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ź w polu record_count w IngestPartnerProvidedIdDataStatus, czy łączna liczba otrzymanych rekordów jest zgodna z oczekiwaniami. record_count zawiera zarówno udane, jak i nieudane próby.

Sprawdź wartość partner_provided_id_count, aby potwierdzić, że liczba otrzymanych identyfikatorów dostarczonych przez partnera 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 oczekiwaniami. Plik record_count zawiera zarówno udane, jak i nieudane próby.

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

user_data_ingestion_status

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

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

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

user_id_data_ingestion_status

Sprawdź 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 usuwania danych identyfikatora użytkownika Google
mobile_data_removal_status
Stan usunięcia mobilnej transmisji danych.
pair_data_removal_status
Stan usuwania 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. record_count zawiera zarówno udane, jak i nieudane rekordy.

Dodatkowo sprawdź 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 Twoimi 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 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 reason z typem ostrzeżenia i record_count wskazujący liczbę rekordów, w których wystąpiło to ostrzeżenie.

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.