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:

Wykres

Strategia sondowania

Dane

Podejście Czas od przesłania prośby o pozyskanie (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-godzinny
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 24-godzinnego czasu działania

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:

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.