Część 1 z 3 dotycząca debugowania interfejsu 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 różnice w wynikach pomiarów między implementacją opartą na plikach cookie a implementacją interfejsu Attribution Reporting API i rozwiąż wszelkie problemy z integracją.
Do wykonania tych zadań wymagane są raporty debugowania. Dlatego zdecydowanie zalecamy ich skonfigurowanie.
Słowniczek
.Najważniejsze aspekty raportów debugowania
2 typy raportów debugowania
Dostępne są 2 typy raportów debugowania. Używaj obu tych typów, ponieważ służą one do różnych celów.
Raporty debugowania dotyczące powodzenia
Raporty debugowania dotyczące powodzenia śledzą udane wygenerowanie raportu atrybucji. Są one bezpośrednio powiązane z raportem atrybucji.
Raporty debugowania dotyczące powodzenia są dostępne od Chrome 101 (kwiecień 2022 r.).
Szczegółowe raporty debugowania
Szczegółowe raporty debugowania zapewniają większą widoczność źródeł i zdarzeń wywołujących. Dzięki temu możesz sprawdzić, czy źródła zostały zarejestrowane, lub śledzić brakujące raporty i określać, dlaczego ich nie ma (błąd w źródle lub zdarzeniach wywołujących, błąd podczas wysyłania lub generowania raportu). Szczegółowe raporty debugowania zawierają informacje o:
- 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 o atrybucji.
- Sytuacje, w których z jakiegoś powodu nie można wygenerować ani wysłać raportu o atrybucji.
Szczegółowe raporty debugowania zawierają pole type, które opisuje udaną rejestrację źródła lub powód, dla którego nie wygenerowano źródła, wyzwalacza ani raportu o atrybucji.
Szczegółowe raporty debugowania są dostępne od Chrome 109 (styczeń 2023 r.) z wyjątkiem szczegółowych raportów debugowania dotyczących udanej rejestracji źródła, które zostały dodane później w Chrome 112.
Przykładowe raporty znajdziesz w części 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 źródło skonfigurowane do otrzymywania raportów jest podmiotem zewnętrznym, ten plik cookie będzie plikiem cookie innej firmy. Oznacza to, że raporty debugowania są generowane tylko wtedy, gdy w przeglądarce użytkownika są dozwolone pliki cookie innych firm.
Raporty debugowania są wysyłane natychmiast.
Raporty debugowania są wysyłane natychmiast przez przeglądarkę do źródła raportowania. W przeciwieństwie do raportów atrybucji, które są wysyłane z opóźnieniem.
Raporty debugowania dotyczące powodzenia są generowane i wysyłane od razu po wygenerowaniu odpowiedniego raportu atrybucji, czyli po zarejestrowaniu wywołania.
Szczegółowe raporty debugowania są wysyłane natychmiast po zarejestrowaniu źródła lub wywołania.
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 raportów debugowania sukcesu na poziomie zdarzenia
- Punkt końcowy raportów debugowania sukcesu, które można agregować
- Punkt końcowy szczegółowych raportów debugowania verbose, które można agregować i które zawierają dane na poziomie zdarzenia.
Więcej informacji znajdziesz w części 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. Używaj raportów debugowania jako sygnału w czasie rzeczywistym, który potwierdza, że integracja z interfejsem Attribution Reporting API działa prawidłowo.
Więcej informacji znajdziesz w części 3: Przewodnik po debugowaniu.
Analiza strat
W przeciwieństwie do plików cookie innych firm interfejs Attribution Reporting API ma wbudowane mechanizmy ochrony prywatności, które mają na celu zachowanie 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 przypadku raportów na poziomie zdarzenia możesz zarejestrować co najwyżej 1 konwersję na 1 wyświetlenie. Oznacza to, że w przypadku danego wyświetlenia reklamy otrzymasz tylko 1 raport o atrybucji, niezależnie od tego, ile razy użytkownik zrealizuje konwersję.
Korzystaj z raportów debugowania, aby sprawdzać różnice między wynikami pomiarów opartych na plikach cookie a wynikami uzyskiwanymi za pomocą interfejsu Attribution Reporting API. Określ, które konwersje są raportowane, ile konwersji nie jest raportowanych, a także które konkretnie i dlaczego.
Dowiedz się, jak przeprowadzić analizę utraty, w części 3: Przewodnik po debugowaniu.
Rozwiązywanie problemów
Utrata spowodowana ochroną prywatności lub zasobów jest oczekiwana, ale inne straty mogą być niezamierzone. Błędne konfiguracje w implementacji lub błędy w samej przeglądarce mogą powodować brak raportów.
Raporty debugowania możesz wykorzystać do wykrywania i rozwiązywania problemów z wdrożeniem po Twojej stronie lub do zgłaszania potencjalnych błędów zespołom przeglądarek. Dowiedz się, jak to zrobić, w części 3: Przewodnik po debugowaniu.
Zaawansowane sprawdzanie konfiguracji
Niektóre funkcje interfejsu Attribution Reporting API umożliwiają dostosowywanie jego działania. Przykłady to reguły filtrowania, reguły usuwania duplikatów i reguły priorytetów.
Korzystając z tych funkcji, używaj raportów debugowania, aby sprawdzić, czy logika prowadzi do zamierzonego działania w środowisku produkcyjnym, bez czekania na raporty atrybucji. Więcej informacji znajdziesz w części 3: Przewodnik po debugowaniu.
Testowanie lokalne z raportami zbiorczymi
W przeciwieństwie do raportów atrybucji z możliwością agregacji, które są szyfrowane, raporty debugowania z możliwością agregacji zawierają niezaszyfrowany ładunek.
Używaj raportów debugowania z możliwością agregacji, aby weryfikować zawartość raportów z możliwością agregacji i 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 możliwość ponownego przetwarzania raportów. Aby przetwarzać raporty więcej niż raz, włącz raporty debugowania. Raporty warto przetworzyć ponownie, gdy:
- próbujesz debugować usługę agregacji.
- eksperymentowanie z różnymi strategiami przetwarzania zbiorczego;
- eksperymentowanie z różnymi wartościami epsilona,
Odzyskiwanie danych
Zalecamy, aby dostawcy technologii reklamowych włączyli tryb debugowania, aby otrzymywać raporty debugowania i móc odzyskać dane raportowania. Jest to przydatne w przypadku problemów z usługą do agregacji, takich jak niedostępność lub brak odpowiedzi ze strony usług, które mogą powodować niepowodzenie generowania raportu podsumowującego.
Następny
Część 2. Konfigurowanie raportów debugowania