Diagnostyka

Oto zalecany przepływ pracy, który pomoże Ci sprawdzić stan przesyłanych zdarzeń i list odbiorców oraz zidentyfikować problemy 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. Prawidłowe żą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 odpowiedzi, aby w następnym kroku móc użyć go do pobrania diagnostyki.

3. Poczekaj 30 minut, a potem wyślij RetrieveRequestStatus żądanie dla każdego udanego request_id.

   Okresowo powtarzaj ten krok dla każdego request_id, dopóki stan miejsca docelowego dla każdego miejsca docelowego nie osiągnie wartości SUCCESS, PARTIAL_SUCCESS lub FAILURE. Używaj algorytmu wzrastającego czasu do ponowienia, aby odczekać przed wysłaniem kolejnego żądania.

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

Właściwość RetrieveRequestStatusRequest wymaga pojedynczej wartości request_id. W przypadku każdego identyfikatora żądania, który został zarejestrowany w odpowiedzi na żądanie dotyczące pomyślnego przesłania 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 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 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 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:

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

W request_status_per_destination w RetrieveRequestStatusResponse znajduje się oddzielny wpis dla każdego miejsca docelowego w odpowiednim żądaniu przesyłania danych.

Jeśli na przykład plik IngestAudienceMembersRequest zawierał 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 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 ustalić, 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 zgłoszone 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 dowiedzieć się, 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 zgłoszone podczas przetwarzania.

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

Sprawdź pole stanu odpowiadające typowi żądania dotyczącego przesyłania danych. W każdym elemencie 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ź 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.

user_data_ingestion_status

Sprawdź 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.

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ź, czy liczba otrzymanych identyfikatorów mobilnych mobile_id_count jest zgodna z Twoimi oczekiwaniami.

pair_data_ingestion_status

Sprawdź 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ź pair_id_count, aby potwierdzić, że liczba otrzymanych identyfikatorów PAIR jest zgodna z Twoimi oczekiwaniami.

ppid_data_ingestion_status

Sprawdź 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ź, czy liczba otrzymanych identyfikatorów PPID ppid_count jest zgodna z Twoimi oczekiwaniami.

user_id_data_ingestion_status

Sprawdź 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.

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.

Stan usuwania kont należących do 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.

user_data_removal_status

Stan usuwania danych użytkownika.

mobile_data_removal_status

Stan usuwania mobilnej transmisji danych.

pair_data_removal_status

Stan usuwania danych PAIR.

ppid_data_removal_status

Stan usunięcia danych PPID.

user_id_data_removal_status

Stan usuwania danych identyfikatora użytkownika

composite_data_removal_status

Stan usuwania danych złożonych

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

Sprawdź też user_identifier_count, mobile_id_count, pair_id_count, ppid_count lub user_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 element 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 na przykład element Event zawiera zaszyfrowane daneUserIdentifier, takie jak gclid, a danych UserIdentifier nie można odszyfrować, interfejs Data Manager API nadal przetwarza rekord za pomocą elementu AdIdentifiers, ale zwraca ostrzeżenie PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.AdIdentifiers

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 WarningCount obiektów. 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 ErrorCount obiektów. Każdy element ErrorCount zawiera element reason z typem błędu i element record_count wskazujący liczbę rekordów, które nie zostały przetworzone z powodu tego typu błędu.