Diagnostyka

Oto zalecany przepływ pracy, który pomoże Ci sprawdzić stan przesłanych plików z wydarzeniami i listami odbiorców oraz zidentyfikować problemy z danymi.

  1. Wysyłanie żądań dotyczących zdarzeń oraz wysyłanie lub usuwanie członków grup odbiorców.

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

    Jeśli żądanie nie zostanie zrealizowane, 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 użyć go do pobrania diagnostyki.

  3. Wyślij żądanie RetrieveRequestStatus dla każdego udanego request_id.

  4. Sprawdź każdy RetrieveRequestStatusResponse, aby potwierdzić, że przesyłanie działa prawidłowo, i zidentyfikować wszelkie problemy z danymi.

  5. Popraw problemy z danymi.

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

Tworzenie żądań

RetrieveRequestStatusRequest ma jedno pole request_id. Wysyłaj po 1 żądaniu dla każdego identyfikatora zaakceptowanego żądania, który został zarejestrowany podczas wysyłania żądań przesyłania danych.

Sprawdzanie 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 w 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 request_status_per_destination (po jednym wpisie na 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 request_status:

  • PROCESSING: dane dotyczące miejsca docelowego są nadal przetwarzane.
  • SUCCESS: przetwarzanie żądania dotyczącego miejsca docelowego zostało zakończone bez błędów.
  • FAILURE: wszystkie rekordy dotyczące miejsca docelowego nie zostały przetworzone z powodu błędów.
  • PARTIAL_SUCCESS: niektóre rekordy w miejscu docelowym zostały przetworzone, ale inne nie z powodu błędów.

Sprawdzanie stanu zdarzenia lub listy 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:

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. Pole record_count zawiera zarówno udane, jak i nieudane rekordy.

Stan przetwarzania członków 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ź pole record_count w sekcji 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ź w polu pair_id_count, czy liczba otrzymanych identyfikatorów PAIR 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.

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.

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 lub pair_id_count, aby potwierdzić łączną liczbę otrzymanych identyfikatorów użytkowników, identyfikatorów mobilnych lub identyfikatorów PAIR.

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

Oprócz pól stanu dotyczących miejsca docelowego i typu żądania element RetrieveRequestStatusResponse zawiera podział 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 dane, np. 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.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.

warning_info
Lista 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ły ostrzeżenia tego typu.
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, które nie zostały przetworzone z powodu tego typu błędu.