Część 1 z 3 dotycząca debugowania raportowania atrybucji Dowiedz się, dlaczego debugowanie jest ważne i kiedy używać raportów debugowania podczas testowania.
Dlaczego potrzebujesz raportów debugowania
Jeśli testujesz interfejs Attribution Reporting API, sprawdź, czy integracja działa prawidłowo, poznaj luki w wynikach pomiaru między implementacją opartą na plikach cookie a implementacją Attribution Reporting oraz rozwiąż problemy z integracją.
Do wykonania tych zadań wymagane są raporty z debugowania. Dlatego zdecydowanie zalecamy ich skonfigurowanie.
Słowniczek
Najważniejsze aspekty raportów debugowania
Dwa typy raportów debugowania
Dostępne są 2 typy raportów debugowania. Używaj obu, ponieważ mają one różne zastosowania.
Raporty debugowania o udanych wynikach
Raporty debugowania sukcesu umożliwiają śledzenie udanego wygenerowania raportu atrybucji. Są one bezpośrednio powiązane z raportami atrybucji.
Raporty o udanym debugowaniu są dostępne od wersji Chrome 101 (kwiecień 2022 r.).
Szczegółowe raporty debugowania
Szczegółowe raporty z debugowania zapewniają większą przejrzystość w przypadku źródeł i zdarzeń uruchamiających. Dzięki temu możesz się upewnić, że źródła zostały zarejestrowane, lub śledzić brakujące raporty i ustalić, dlaczego się nie wyświetlają (błąd w źródle lub zdarzeniu uruchamiającym, błąd podczas wysyłania lub generowania raportu). Szczegółowe raporty debugowania wskazują:
- Przypadki, w których przeglądarka zarejestrowała źródło.
- Przypadki, w których przeglądarka nie zarejestrowała źródła lub zdarzenia wywołującego, co oznacza, że nie wygeneruje raportu atrybucji.
- przypadki, w których z jakiegoś powodu nie można wygenerować ani wysłać raportu atrybucji;
Szczegółowe raporty debugowania zawierają pole type, które opisuje albo pomyślną rejestrację źródła, albo przyczynę, dla której nie wygenerowano raportu źródła, wyzwalacza lub atrybucji.
Szczegółowe raporty debugowania są dostępne od wersji 109 Chrome (styczeń 2023 r.), z wyjątkiem szczegółowych raportów debugowania dotyczących rejestracji źródła, które zostały dodane później w wersji 112 Chrome.
Przykładowe raporty znajdziesz w sekcji Część 2. Konfigurowanie raportów debugowania.
Raporty debugowania są oparte na plikach cookie
Aby korzystać z raportów debugowania, źródło raportowania musi ustawić plik cookie.
Jeśli do otrzymywania raportów skonfigurowano domeny innych firm, plik cookie będzie plikiem cookie innej firmy. Oznacza to, że raporty debugowania są generowane tylko wtedy, gdy pliki cookie innych firm są dozwolone w przeglądarce użytkownika.
Raporty debugowania są wysyłane natychmiast.
Raporty debugowania są natychmiast wysyłane przez przeglądarkę do źródła raportowania. Jest to odmienne podejście niż w przypadku raportów atrybucji, które są wysyłane z opóźnieniem.
Raporty debugowania o udanych wynikach są generowane i wysyłane, gdy tylko zostanie wygenerowany odpowiedni raport atrybucji, czyli w przypadku rejestracji wyzwalacza.
Szczegółowe raporty debugowania są wysyłane natychmiast po zarejestrowaniu źródła lub reguły.
Raporty debugowania mają różne ścieżki punktów końcowych
Podobnie jak raporty atrybucji, wszystkie raporty debugowania są wysyłane do źródła raportowania. Raporty debugowania są wysyłane do 3 oddzielnych punktów końcowych źródła raportowania:
- Punkt końcowy do raportów debugowania osiągnięć na poziomie zdarzenia
- Punkt końcowy służący do generowania pomyślnych raportów debugowania, które można agregować
- Punkt końcowy do szczegółowych raportów debugowania, które można agregować i przetwarzać na poziomie zdarzenia.
Więcej informacji znajdziesz w artykule Część 2. Konfigurowanie raportów debugowania.
Przypadki użycia
Podstawowe sprawdzanie integracji w czasie rzeczywistym
Raporty debugowania są wysyłane do punktu końcowego natychmiast, w przeciwieństwie do raportów atrybucji, które są opóźniane w celu ochrony prywatności użytkowników. Wykorzystaj raporty debugowania jako sygnał w czasie rzeczywistym, że integracja z interfejsem Attribution Reporting API działa.
Więcej informacji znajdziesz w artykule Część 3. Przewodnik po debugowaniu.
Analiza strat
W przeciwieństwie do plików cookie innych firm Attribution Reporting API zawiera wbudowane zabezpieczenia dotyczące prywatności, które mają na celu zapewnienie równowagi między użytecznością a prywatnością. Oznacza to, że za pomocą interfejsu Attribution Reporting API możesz nie być w stanie zbierać wszystkich danych pomiarowych, które można zbierać za pomocą plików cookie. Nie wszystkie konwersje, które możesz śledzić za pomocą plików cookie innych firm, będą generować raport atrybucji.
Przykład: w raportach na poziomie zdarzenia możesz zarejestrować maksymalnie 1 konwersję na wyświetlenie. Oznacza to, że w przypadku danego wyświetlenia reklamy otrzymasz tylko 1 raport atrybucji, niezależnie od tego, ile razy użytkownik dokonał konwersji.
Korzystając z raportów debugowania, możesz zobaczyć różnice między wynikami pomiarów opartych na plikach cookie a tymi uzyskanymi za pomocą interfejsu Attribution Reporting API. Określ, które konwersje są raportowane, ile konwersji nie jest raportowanych oraz które konwersje nie są raportowane i dlaczego.
Więcej informacji o analizie strat znajdziesz w artykule Część 3. Przewodnik po debugowaniu.
Rozwiązywanie problemów
Straty spowodowane ochroną prywatności lub zasobów są spodziewane, ale inne straty mogą być niezamierzone. Nieprawidłowa konfiguracja implementacji lub błędy w samym przeglądarce mogą powodować brak raportów.
Raporty debugowania możesz wykorzystać do wykrycia i rozwiązania problemu z wdrożeniem po swojej stronie lub do zgłoszenia potencjalnego błędu zespołom przeglądarek. Dowiedz się, jak to zrobić w artykule Część 3. Przewodnik po debugowaniu.
Sprawdzanie zaawansowanej konfiguracji
Niektóre funkcje interfejsu Attribution Reporting API umożliwiają dostosowywanie jego działania. Przykładami takich reguł są reguły filtrowania, reguły deduplikacji i reguły z priorytetami.
Podczas korzystania z tych funkcji możesz używać raportów debugowania, aby sprawdzić, czy logika prowadzi do zamierzonego działania w wersji produkcyjnej, bez oczekiwania na raporty o przypisaniu. Więcej informacji znajdziesz w artykule Część 3. Przewodnik po debugowaniu.
Testowanie lokalne z raportami możliwymi do agregacji
W odróżnieniu od zaszyfrowanych raportów o atrybucji, które można agregować, raporty debugowania, które można agregować, zawierają niezaszyfrowany ładunek.
Korzystaj z raportów debugowania danych zbiorczych, aby weryfikować zawartość raportów danych zbiorczych oraz generować raporty podsumowujące za pomocą lokalnego narzędzia do agregacji na potrzeby testowania.
Ponowne przetwarzanie raportów usługi do agregacji
Kolejną zaletą korzystania z trybu debugowania jest to, że pozwala on ponownie przetworzyć raporty. Aby przetwarzać raporty więcej niż raz, włącz raporty debugowania. Warto ponownie przetworzyć raporty, gdy:
- próbuje debugować usługę agregacji.
- eksperymentowanie z różnymi strategiami grupowania.
- eksperymentowanie z różnymi wartościami epsilona.
Odzyskiwanie danych
Zalecamy, aby specjaliści ds. technologii reklam włączyli tryb debugowania, aby otrzymywać raporty z debugowania, dzięki którym mogą odzyskać dane do raportowania. Jest to przydatne w przypadku problemów z usługą do agregacji, np. niedostępności lub braku odpowiedzi, które mogą spowodować niepowodzenie generowania raportu podsumowującego.