Diagnostyka

Oto zalecany proces weryfikacji stanu przesył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 element Status, w którym code jest równe 0 (wartość wyliczeniowa OK, odpowiedź HTTP 200 OK), i zwraca element 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, zapisz request_id z odpowiedzi, aby w następnym kroku móc pobrać dane diagnostyczne.

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żywaj algorytmu wzrastającego czasu do ponowienia, aby odczekać między poszczególnymi żądaniami.

4. Sprawdź każdy RetrieveRequestStatusResponse, aby potwierdzić, ż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. W przypadku każdego identyfikatora żądania, który został zarejestrowany w ramach udanego żądania pozyskiwania danych, wyślij osobne żądanie stanu.

Okresowo wysyłaj RetrieveRequestStatusRequest za pomocą algorytmu wzrastającego czasu do ponowienia, dopóki request_status nie osiągnie wartości SUCCESS, FAILURE lub PARTIAL_SUCCESS w przypadku 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 ponawiania, która równoważy aktywność i wykorzystanie limitu:

Ustawienie	Wartość
Czas oczekiwania przed pierwszą prośbą o diagnostykę (w minutach)	30
Mnożnik czasu do ponowienia	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ął w tej konfiguracji:

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 w parametrze IngestAudienceMembersRequest znajdowały się 3 wpisy na liście destinations, aby wysyłać dane do 3 różnych list odbiorców, odpowiedź o stanie zawierałaby 3 wpisy w parametrze request_status_per_destination (po jednym wpisie na każdą listę odbiorców).

Sprawdzanie ogólnego stanu miejsca docelowego

Najpierw sprawdź pole request_status, aby określić, czy interfejs Data Manager API zakończył przetwarzanie danych dla destination w przypadku 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 w przypadku 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 dotyczące miejsca docelowego nie zostały przetworzone z powodu błędów. Sprawdź ostrzeżenia i błędy, aby określić, dlaczego wszystkie rekordy nie zostały przetworzone. 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ź, czy nie ma błędów, aby dowiedzieć się, dlaczego niektóre rekordy nie zostały przetworzone. Sprawdź też ostrzeżenia oznaczone podczas przetwarzania.

Sprawdzanie stanu zdarzenia lub odbiorców w poszczególnych miejscach docelowych

Sprawdź pole stanu odpowiadające typowi żądania ingestowania. W każdym polu RequestStatusPerDestination ustawione jest tylko jedno z tych pól:

• events_ingestion_status
• audience_members_ingestion_status
• audience_members_removal_status

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 członkach listy 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 Twoimi 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 Twoimi 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ź record_count w IngestGoogleUserIdDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z Twoimi oczekiwaniami. Pole record_count zawiera zarówno udane, jak i nieudane rekordy.

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

mobile_data_ingestion_status

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

Sprawdź mobile_id_count, aby potwierdzić, że liczba otrzymanych identyfikatorów mobilnych jest zgodna z Twoimi 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. record_count obejmuje zarówno udane, jak i nieudane rekordy.

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

partner_provided_id_data_ingestion_status

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

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ź pole record_count w sekcji IngestPpidDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z Twoimi oczekiwaniami. record_count obejmuje zarówno udane, jak i nieudane rekordy.

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

user_data_ingestion_status

Sprawdź pole record_count w sekcji IngestUserDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z Twoimi 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ź pole record_count w sekcji IngestUserIdDataStatus, aby potwierdzić, że łączna liczba otrzymanych rekordów jest zgodna z Twoimi oczekiwaniami. record_count obejmuje zarówno udane, jak i nieudane rekordy.

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

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 usuwania danych złożonych

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 usuwania danych identyfikacyjnych dostarczonych 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 usuwania 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 udane, jak i nieudane rekordy.

Sprawdź też pola 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 otrzymanych identyfikatorów (takich jak adres e-mail, numer telefonu, adres pocztowy i adres IP) przez DataType.

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

Oprócz pól stanu dotyczących 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ć części danych rekordu.

Jeśli na przykład Event zawiera zaszyfrowaneUserIdentifier daneAdIdentifiers, takie jak gclid, a 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 element Event musi zawierać co najmniej jeden z 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 element WarningCount zawiera element reason z typem ostrzeżenia i element 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

Lista obiektów ErrorCount. Każdy element ErrorCount zawiera element reason z typem błędu i element record_count wskazujący liczbę rekordów, w których wystąpił ten typ błędu.