Część 1 z 3 dotycząca debugowania raportu Attribution Reporting 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 pomiarów 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 powodzenia rejestrują udane wygenerowanie raportu atrybucji. Są one bezpośrednio powiązane z raportami atrybucji.
Raporty debugowania o udanych testach są dostępne od wersji 101 Chrome (kwiecień 2022 r.).
szczegółowe raporty debugowania,
Szczegółowe raporty debugowania zapewniają większą przejrzystość źródeł i zdarzeń uruchamiających. Dzięki temu możesz sprawdzić, czy źródła zostały zarejestrowane, lub śledzić brakujące raporty i ustalić, dlaczego ich brakuje (awaria źródeł lub zdarzeń uruchamiających, awaria 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 powód, dla którego nie wygenerowano raportu źródła, raportu o wyzwalaczu lub raportu o przypisaniu.
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 domenę należącą do innej firmy, 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.
Przeglądarka wysyła raporty debugowania natychmiast 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 utworzony 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 success na poziomie zdarzenia
- Punkt końcowy służący do generowania pomyślnych raportów debugowania, które można agregować
- Punkt końcowy służący do szczegółowych raportów debugowania na poziomie zdarzenia i zbiorczych.
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 odróżnieniu od plików cookie innych firm Attribution Reporting API zawiera wbudowane zabezpieczenia 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 zbiorczych raportów debugowania, aby weryfikować zawartość zbiorczych raportów oraz generować raporty podsumowujące za pomocą lokalnego narzędzia do agregacji na potrzeby testowania.
Ponowne przetwarzanie raportów usługi agregacji
Kolejną zaletą korzystania z trybu debugowania jest to, że umożliwia on ponowne przetworzenie raportów. 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ą agregacji, takich jak niedostępność lub brak odpowiedzi usług, które mogą spowodować niepowodzenie generowania raportu podsumowania.