Część 1 z 3 dotycząca debugowania raportowania atrybucji. Dowiedz się, dlaczego debugowanie jest ważne i kiedy warto używać raportów na potrzeby testów.
Dlaczego potrzebujesz raportów na temat 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ąż ewentualne problemy z integracją.
Do wykonania tych zadań wymagane są raporty na temat debugowania. Dlatego zdecydowanie zalecamy ich skonfigurowanie.
Glosariusz
Najważniejsze aspekty raportów debugowania
2 typy raportów debugowania
Dostępne są 2 rodzaje raportów na temat debugowania. Używaj ich, ponieważ sprawdzają się w różnych przypadkach.
Raporty o pomyślnym debugowaniu
Raporty na temat pomyślnego debugowania pozwalają śledzić udane wygenerowanie raportu atrybucji. Mają bezpośredni związek z raportem atrybucji.
Raporty o powodzeniu debugowania są dostępne od wersji Chrome 101 (kwiecień 2022 r.).
Szczegółowe raporty na temat debugowania
Wyczerpujące raporty na temat debugowania zapewniają lepszy wgląd w zdarzenia źródłowe i wyzwalacze, dzięki czemu możesz sprawdzić, czy źródła zostały zarejestrowane, lub śledzić brakujące raporty i ustalać, dlaczego ich brakuje (niepowodzenie w zdarzeniach źródłowych lub aktywatorów czy niepowodzenia podczas wysyłania lub generowania raportu). Szczegółowe informacje o debugowaniu:
- Przypadki, w których przeglądarka zarejestrowała źródło.
- Przypadki, w których przeglądarka nie zarejestrowała źródła ani nie wywołała zdarzenia, co oznacza, że nie generuje raportu atrybucji.
- Sytuacje, 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 pomyślną rejestrację źródła lub przyczynę, dla której nie utworzono źródła, reguły bądź raportu atrybucji.
Szczegółowe raporty debugowania są dostępne od Chrome 109 (styczeń 2023 r.) z wyjątkiem szczegółowych raportów debugowania o pomyślnej rejestracji źródła, które zostały dodane później w Chrome 112.
Zobacz przykładowe raporty w części Część 2. Konfigurowanie raportów debugowania.
Raporty debugowania są oparte na plikach cookie
Aby można było korzystać z raportów na temat debugowania, źródło raportowania musi ustawić plik cookie.
Jeśli źródłem skonfigurowanym do otrzymywania raportów jest inna firma, ten plik cookie będzie plikiem cookie innej firmy. Ma to kilka ważnych konsekwencji:
- Raporty o debugowaniu 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 o debugowaniu są wysyłane natychmiast
Raporty o debugowaniu 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 o pomyślnym debugowaniu są generowane i wysyłane natychmiast po wygenerowaniu odpowiedniego raportu atrybucji, czyli w momencie rejestracji.
Szczegółowe raporty na temat debugowania są wysyłane natychmiast po rejestracji źródła lub rejestracji.
Raporty debugowania mają różne ścieżki punktów końcowych
Tak jak w przypadku raportów atrybucji, wszystkie raporty o debugowaniu są wysyłane do źródła raportowania. Raporty o debugowaniu są wysyłane do 3 osobnych punktów końcowych źródła raportowania:
- Punkt końcowy dla raportów debugowania o sukcesie na poziomie zdarzenia
- Punkt końcowy dla raportów debugowania o sukcesie (możliwy do agregacji)
- Punkt końcowy na potrzeby wyczerpujących raportów debugowania, na poziomie zdarzenia i z możliwością agregacji.
Więcej informacji znajdziesz w części Część 2. Konfigurowanie raportów na temat debugowania.
Przykłady zastosowań
Podstawowe sprawdzanie integracji w czasie rzeczywistym
Raporty o debugowaniu są natychmiast wysyłane do punktu końcowego – w przeciwieństwie do raportów atrybucji, które są opóźnione ze względu na ochronę prywatności użytkowników. Używaj raportów na temat debugowania jako sygnału w czasie rzeczywistym, że integracja z interfejsem Attribution Reporting API działa.
Aby dowiedzieć się, jak to zrobić, przeczytaj Część 3. Debugowanie w książce kucharskiej.
Analiza strat
W przeciwieństwie do plików cookie innych firm interfejs Attribution Reporting API zawiera wbudowane zabezpieczenia, które pozwalają znaleźć równowagę między użytecznością a prywatnością. Oznacza to, że za pomocą Attribution Reporting API możesz nie być w stanie zbierać wszystkich danych pomiarowych, które gromadzisz obecnie za pomocą plików cookie. Nie wszystkie konwersje, które można śledzić za pomocą plików cookie innych firm, generują raport atrybucji.
Przykład: w przypadku raportów 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.
Dzięki raportom na temat debugowania możesz obserwować różnice między wynikami pomiarów na podstawie plików cookie a wynikami uzyskiwanymi za pomocą interfejsu Attribution Reporting API. Ustal, które konwersje są raportowane, a ile nie, oraz które konwersje i dlaczego.
Informacje o tym, jak przeprowadzić analizę strat, znajdziesz w części Część 3. Debugowanie książki kucharskiej.
Rozwiązywanie problemów
Choć straty spowodowane przez ochronę prywatności lub zasobów są oczekiwane, inne straty mogą być niezamierzone. Błędy w konfiguracji lub błędy w przeglądarce mogą powodować błędy w raportach.
Raporty na temat debugowania pozwalają wykrywać i naprawiać problemy z implementacją lub zgłaszać potencjalne błędy zespołom przeglądarek. Aby dowiedzieć się, jak to zrobić, przeczytaj Część 3. Debugowanie w książce kucharskiej.
Zaawansowane sprawdzanie konfiguracji
Niektóre funkcje Attribution Reporting API umożliwiają dostosowanie działania tego interfejsu. Mogą to być na przykład reguły filtrowania, deduplikacji i priorytetu.
Podczas korzystania z tych funkcji korzystaj z raportów na temat debugowania, aby bez oczekiwania na raporty atrybucji sprawdzić, czy Twoje działanie logiczne prowadzi do zamierzonego działania w środowisku produkcyjnym. Aby dowiedzieć się, jak to zrobić, przeczytaj Część 3. Debugowanie w książce kucharskiej.
Testy lokalne z raportami agregowanymi
W przeciwieństwie do agregowanych raportów atrybucji, które są zaszyfrowane, agregowane raporty o debugowaniu zawierają niezaszyfrowany ładunek.
Używaj agregowanych raportów debugowania do weryfikowania treści raportów agregowanych i generowania raportów podsumowujących za pomocą lokalnego narzędzia do agregacji na potrzeby testów.
Ponowne przetwarzanie raportów usługi agregacji
Inną zaletą korzystania z trybu debugowania jest możliwość ponownego przetwarzania raportów. Jeśli więc chcesz przetworzyć raporty więcej niż raz, musisz mieć włączone raporty na temat debugowania. Ponowne przetwarzanie raportów może być przydatne, jeśli:
- próbując zdebugować usługę agregacji.
- eksperymentując z różnymi strategiami grupowania.
- eksperymentując z różnymi wartościami ypsilon.
Odzyskiwanie danych
Specjaliści ds. technologii reklamowych powinni włączyć tryb debugowania, aby otrzymywać raporty o debugowaniu umożliwiające przywrócenie danych. Jest to przydatne w przypadku problemów z usługą agregacji, takich jak niedostępne lub niedostępne usługi, które mogą powodować błędy podczas generowania raportu podsumowującego.