Część 1 z 3 dotycząca debugowania raportów atrybucji. Dowiedz się, dlaczego debugowanie jest ważne i kiedy warto korzystać z raportów debugowania podczas testowania.
Do czego są potrzebne raporty 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ą raportów atrybucji oraz rozwiąż problemy z integracją.
Do wykonywania tych zadań są wymagane raporty debugowania. Dlatego zdecydowanie zalecamy ich skonfigurowanie.
Glosariusz
Najważniejsze aspekty raportów debugowania
2 typy raportów debugowania
Dostępne są 2 typy raportów debugowania. Używaj obu, ponieważ mają one różne przypadki użycia.
Raporty debugowania zakończone powodzeniem
Raporty debugowania powodzenia zawierają informacje o pomyślnym wygenerowaniu raportu atrybucji. Są one związane bezpośrednio z raportem atrybucji.
Raporty debugowania zakończone powodzeniem są dostępne od wersji Chrome 101 (kwiecień 2022 r.).
Wyczerpujące raporty debugowania
Wyczerpujące raporty debugowania zapewniają lepszy wgląd w zdarzenia prowadzące do źródła i reguły. Możesz dzięki temu mieć pewność, że źródła zostały zarejestrowane, albo śledzić brakujące raporty i określać, dlaczego ich brakuje (niepowodzenie w wynikach zdarzenia źródła lub aktywatora, błąd podczas wysyłania lub generowania raportu). Szczegółowe raporty na temat debugowania zawierają te informacje:
- 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 aktywującego, co oznacza, że nie wygeneruje ona raportu atrybucji.
- Sytuacje, w których z jakiegoś powodu nie można wygenerować lub wysłać raportu atrybucji.
Pełne raporty debugowania zawierają pole type, w którym opisano pomyślną rejestrację źródła lub wyjaśnienie, dlaczego źródło, reguła lub raport atrybucji nie zostały wygenerowane.
Wyczerpujące raporty debugowania są dostępne od Chrome 109 (styczeń 2023) – z wyjątkiem szczegółowych raportów debugowania zakończonych powodzeniem rejestracji źródła, które zostały dodane później w Chrome 112.
Przejrzyj przykładowe raporty w Części 2. Konfigurowanie raportów debugowania.
Raporty debugowania są oparte na plikach cookie
Aby można było korzystać z raportów debugowania, źródło raportowania musi ustawić plik cookie.
Jeśli źródło skonfigurowane do otrzymywania raportów jest źródłem zewnętrznym, będzie to ten plik cookie. Ma to kilka kluczowych konsekwencji:
- Raporty debugowania są generowane tylko wtedy, gdy w przeglądarce użytkownika są dozwolone pliki cookie innych firm.
- Raporty debugowania nie będą już dostępne po wycofaniu plików cookie innych firm.
Raporty debugowania są wysyłane natychmiast
Raporty debugowania są natychmiast wysyłane przez przeglądarkę do źródła raportowania. Różni się to od raportów atrybucji, które są wysyłane z opóźnieniem.
Raporty dotyczące debugowania powodzenia są generowane i wysyłane natychmiast po wygenerowaniu odpowiedniego raportu atrybucji, czyli w momencie rejestracji użytkownika.
Szczegółowe raporty debugowania są wysyłane natychmiast po zarejestrowaniu źródła lub aktywatora.
Raporty debugowania mają różne ścieżki punktów końcowych
Podobnie jak w przypadku raportów atrybucji, wszystkie raporty debugowania są wysyłane do źródła raportowania. Raporty debugowania są wysyłane do 3 osobnych punktów końcowych źródła raportowania:
- Punkt końcowy dla raportów debugowania o zakończeniu powodzenie, na poziomie zdarzenia
- Punkt końcowy dla raportów debugowania o sukcesie (zbiorczy)
- Punkt końcowy dla szczegółowych raportów debugowania na poziomie zdarzenia, które są agregowane.
Więcej informacji znajdziesz w sekcji Część 2. Konfigurowanie raportów debugowania.
Przypadki użycia
Podstawowe sprawdzanie integracji w czasie rzeczywistym
W przeciwieństwie do raportów atrybucji, które są opóźnione, by chronić prywatność użytkowników, raporty debugowania są natychmiast wysyłane do punktu końcowego. Używaj raportów debugowania jako sygnału w czasie rzeczywistym, że integracja z interfejsem Attribution Reporting API działa.
Jak to zrobić, dowiesz się z części Część 3. Debugowanie książki kucharskiej.
Analiza strat
W odróżnieniu od plików cookie innych firm interfejs Attribution Reporting API zawiera wbudowane zabezpieczenia prywatności, które zostały opracowane z myślą o zachowaniu równowagi między przydatnością a prywatnością. Oznacza to, że korzystanie z interfejsu Attribution Reporting API może nie być w stanie zbierać wszystkich danych pomiarowych, które zbierasz obecnie za pomocą plików cookie. Nie wszystkie konwersje, które można śledzić za pomocą plików cookie innych firm, wygenerują raport atrybucji.
Na przykład w raportach na poziomie zdarzenia możesz zarejestrować maksymalnie jedną konwersję na wyświetlenie. Oznacza to, że dla danego wyświetlenia reklamy otrzymasz tylko 1 raport atrybucji, niezależnie od tego, ile razy użytkownik dokonał konwersji.
Raporty debugowania pozwalają sprawdzić różnice między wynikami pomiaru na podstawie plików cookie a wynikami uzyskanymi za pomocą interfejsu Attribution Reporting API. Określ, które konwersje są raportowane, ile z nich nie jest raportowanych, a które i dlaczego tak się dzieje.
Z części 3. Poradnik dotyczący debugowania dowiesz się, jak przeprowadzić analizę strat.
Rozwiązywanie problemów
Choć strata spowodowana przez ochronę prywatności lub zasobów jest przewidziana, inne straty mogą być niezamierzone. Błędy w konfiguracji lub błędy w samej przeglądarce mogą powodować zniknięcie raportów.
Raporty debugowania mogą służyć do wykrywania i rozwiązywania problemów z implementacją po Twojej stronie oraz do zgłaszania potencjalnych błędów zespołom ds. przeglądarek. Jak to zrobić, dowiesz się z części 3. Debugowanie książki kucharskiej.
Zaawansowane sprawdzanie konfiguracji
Niektóre funkcje interfejsu Attribution Reporting API umożliwiają dostosowanie działania tego interfejsu. Na przykład reguły filtrowania, usuwania duplikatów i reguł priorytetów.
Gdy korzystasz z tych funkcji, używaj raportów debugowania, aby sprawdzać, czy Twoja logika prowadzi do zamierzonego działania w środowisku produkcyjnym, bez oczekiwania na raporty atrybucji. Jak to zrobić, dowiesz się z części Część 3. Debugowanie książki kucharskiej.
Testowanie lokalne z użyciem raportów zbiorczych
W przeciwieństwie do zbiorczych raportów atrybucji, które są zaszyfrowane, zbiorcze raporty debugowania zawierają niezaszyfrowany ładunek.
Korzystaj z agregowanych raportów debugowania, aby sprawdzać zawartość raportów zbiorczych oraz generować raporty podsumowujące za pomocą lokalnego narzędzia agregacji na potrzeby testów.
Ponowne przetwarzanie raportów dotyczących usługi agregacji
Inną zaletą korzystania z trybu debugowania jest to, że umożliwia ponowne przetwarzanie raportów. Aby móc przetwarzać raporty więcej niż raz, musisz włączyć raporty debugowania. Ponownie przetwórz raporty, jeśli:
- próbujemy debugować usługę agregacji.
- eksperymentowania z różnymi strategiami grupowania.
- eksperymentując z różnymi wartościami epsilonu.
Odzyskiwanie danych
Zalecamy, aby technologie reklamowe włączyły tryb debugowania, aby otrzymywać raporty debugowania, które pozwolą im odzyskać dane raportowania. Jest to przydatne w przypadku problemów z usługą agregacji, takich jak niedostępne lub nieelastyczne usługi, które mogą powodować błąd generowania raportu podsumowującego.