Sprawdzone metody

Podczas korzystania z interfejsu Data Manager API pamiętaj o tych sprawdzonych metodach.

Wysyłanie wszystkich identyfikatorów użytkowników

Niezależnie od tego, czy wysyłasz odbiorców czy zdarzenia za pomocą UserData, uwzględnij jak najwięcej parametrów user_identifiers, w tym wiele identyfikatorów tego samego typu.

Jeśli na przykład masz kilka adresów e-mail użytkownika, dodaj osobny element UserIdentifier dla każdego z nich. Podobnie, jeśli masz identyfikatory różnych typów dla użytkownika, takie jak adresy e-mail, numery telefonów i adresy, dodaj osobny element UserIdentifier dla każdego identyfikatora, aż do maksymalnej liczby identyfikatorów.

Optymalizacja żądań

Aby zmniejszyć prawdopodobieństwo przekroczenia dziennych limitów żądań, w każdym żądaniu umieść jak najwięcej elementów, nie przekraczając limitów na żądanie.

Jeśli na przykład chcesz dodać do grupy odbiorców 10 000 użytkowników, dodaj ich wszystkich do listy audience_members w jednym pliku IngestAudienceMembersRequest. Przesłanie wszystkich 10 000 odbiorców w jednym żądaniu jest bardziej efektywne niż wysyłanie osobnego żądania dla każdego odbiorcy.

Wysyłanie żądań równoczesnych

Aby skrócić łączny czas potrzebny na pozyskanie danych, wysyłaj żądania równoczesne do IngestionService. Zalecamy wysyłanie maksymalnie 10 żądań jednocześnie, aby zmniejszyć prawdopodobieństwo przekroczenia limitu żądań na minutę.

Możesz wysyłać żądania równoczesne, nawet jeśli mają tę samą wartość destinations.

Sprawdzanie poprawności danych po stronie klienta

Interfejs Data Manager API korzysta z modelu szybkiego niepowodzenia. Jeśli którykolwiek rekord w żądaniu nie przejdzie weryfikacji synchronicznej, całe żądanie zakończy się niepowodzeniem i żaden z rekordów nie zostanie przetworzony. Dodatkowo interfejs API sprawdza żądania w kolejnych warstwach, więc naprawienie jednego błędu może ujawnić błąd z kolejnej warstwy walidacji.

Aby uniknąć powtarzających się operacji przesyłania danych w obie strony i odrzuconych żądań, przed wysłaniem danych sprawdź je i usuń z nich informacje:

  • Usuń puste wartości przed szyfrowaniem: przed obliczeniem skrótów SHA-256 sprawdź, czy pola takie jak email_address i phone_number nie zawierają pustych ciągów znaków ani ciągów znaków zawierających tylko spacje. Haszowanie pustego ciągu znaków daje prawidłowy hasz, który przechodzi testy składni, ale obniża współczynniki dopasowania.

  • Odrzucaj niekompletne obiekty złożone: przed dodaniem obiektów złożonych do rekordu upewnij się, że zawierają one wszystkie wymagane pola. Jeśli na przykład w obiekcie AddressInfo brakuje dowolnego z 4 wymaganych pól (given_name, family_name, region_code lub postal_code), usuń cały identyfikator address, aby uniknąć błędów REQUIRED_FIELD_MISSING.

  • Sprawdź pola kodowania i zwykłego tekstu: sprawdź, czy pola zaszyfrowane są zgodne z deklarowaną wartością encoding, a nie wysyłają zwykłego tekstu, i upewnij się, że pola, które muszą pozostać zwykłym tekstem (np. mobile_ids), nie są zaszyfrowane.

  • Odfiltruj sygnatury czasowe spoza zakresu: upewnij się, że sygnatury czasowe nie są z przyszłości ani nie są starsze niż okres ważności konwersji w miejscu docelowym.

    Jeśli wysyłasz żądania za pomocą JSON, upewnij się, że ciągi znaków sygnatury czasowej używają formatu RFC 3339 z przesunięciem strefy czasowej.

  • Czyste numery telefonów: przed zaszyfrowaniem numerów telefonów sprawdź, czy zawierają one kod kraju i są w formacie E.164.

  • Usuń puste lub zbyt duże rekordy: ogranicz user_identifiers do limitu na rekord (10 identyfikatorów), usuń puste parametry niestandardowe i pomiń wszystkie rekordy, które nie zawierają prawidłowych identyfikatorów.

  • Sprawdź wymagania dotyczące przypadków użycia: upewnij się, że każde zdarzenie zawiera wszystkie pola wymagane w przypadku danego miejsca docelowego i przypadku użycia (np. transaction_id w przypadku konwersji online w Google Ads). Pełną listę wymaganych pól według przypadków użycia znajdziesz w przewodniku po wysyłaniu zdarzeń do miejsca docelowego w Omówieniu zdarzeń.

  • Używaj validateOnly do testowania żądań: wysyłaj żądania z parametrem validateOnly ustawionym na true, aby wychwytywać błędy typu fast-fail bez pozyskiwania ani usuwania danych. Pomyślne żądanie tylko do walidacji nie gwarantuje, że podczas przetwarzania asynchronicznego nie wystąpią błędy, dlatego po wysłaniu zwykłego żądania nadal sprawdzaj stan żądania i diagnostykę.

Szczegółowe reguły normalizacji i haszowania znajdziesz w artykule Formatowanie danych użytkownika.

Sprawdzanie stanu żądania i diagnostyki

Przechwyć i zbierz request_id z każdego elementu IngestAudienceMembersResponse lub IngestEventsResponse i użyj identyfikatorów żądań, aby sprawdzić stan żądania i informacje diagnostyczne.

Monitorowanie limitów i alerty o nich

Aby uniknąć nieoczekiwanych odrzuceń żądań, skonfiguruj alerty dotyczące limitów i monitorowanie w konsoli Google Cloud. Monitorowanie wykorzystania limitów pomaga śledzić wzorce wykorzystania i optymalizować grupowanie żądań, zanim aplikacja osiągnie limity dzienne lub minutowe.

Wdrażanie w środowisku produkcyjnym

Przechodząc z testowania lokalnego do zadań produkcyjnych, używaj domyślnego uwierzytelniania aplikacji z dołączonym kontem usługi lub federacją tożsamości zadań, aby uwierzytelniać się w sposób nieinteraktywny i bezpieczny.

Szczegółowe informacje o konfigurowaniu uwierzytelniania w różnych środowiskach produkcyjnych znajdziesz w artykule na temat wdrażania w środowisku produkcyjnym.

Wstecz
Informacje o błędach interfejsu API