Ta strona została przetłumaczona przez Cloud Translation API.

Książka kucharska na temat debugowania raportów atrybucji

Część 3 z 3 dotycząca debugowania raportowania atrybucji. Znajdź instrukcje korzystania z raportów debugowania.

W tym podręczniku znajdziesz instrukcje korzystania z raportów debugowania w różnych przypadkach użycia opisanych w artykule Część 1. Wprowadzenie do raportów debugowania.

Słowniczek

Źródło raportowania to źródło, które ustawia źródło i aktywator funkcji Attribution Reporting. Wszystkie raporty generowane przez przeglądarkę są wysyłane do tego źródła. W tych wskazówkach jako przykładowego źródła zgłoszenia używamy https://adtech.example.
Raport atrybucji (w skrócie raport) to raport końcowy (na poziomie zdarzenia lub agregowany) zawierający żądane dane pomiarowe.
Raport debugowania zawiera dodatkowe dane o raporcie atrybucji albo o źródle lub zdarzeniu reguły. Otrzymanie raportu na temat debugowania nie musi oznaczać, że coś działa nieprawidłowo. Istnieją 2 typy raportów debugowania.
Przejściowy raport debugowania to raport debugowania, który wymaga skonfigurowania pliku cookie w celu wygenerowania i wysłania. Jeśli plik cookie nie zostanie skonfigurowany i po wycofaniu plików cookie innych firm, raporty dotyczące debugowania przejściowych będą niedostępne. Wszystkie raporty na temat debugowania opisane w tym przewodniku to raporty na temat debugowania.
Raporty na temat pomyślnego debugowania pozwalają śledzić udane wygenerowanie raportu atrybucji. Mają bezpośredni związek z raportem atrybucji. Raporty o udanym debugowaniu są dostępne od wersji Chrome 101 (kwiecień 2022 r.).
Szczegółowe raporty debugowania pozwalają śledzić brakujące raporty i ustalać, dlaczego ich brakuje. Wskazują przypadki, w których przeglądarka nie zarejestrowała zdarzenia źródła ani nie wywołała tego zdarzenia (co oznacza, że nie generuje raportu atrybucji), oraz przypadki, gdy z jakiegoś powodu nie można wygenerować lub wysłać raportu atrybucji. Szczegółowe raporty debugowania zawierają pole type, które podaje powód, dla którego zdarzenie źródłowe, zdarzenie reguły lub raport atrybucji nie zostały wygenerowane. Szczegółowe raporty dotyczące debugowania są dostępne w Chrome od wersji 109 (stabilnej wersji od stycznia 2023 r.).
Klucze debugowania to unikalne identyfikatory, które możesz ustawić zarówno po stronie źródła, jak i po stronie reguły. Klucze debugowania umożliwiają mapowanie konwersji opartych na plikach cookie i atrybucji. Gdy skonfigurujesz system do generowania raportów debugowania i ustawiania kluczy debugowania, przeglądarka będzie uwzględniać te klucze debugowania we wszystkich raportach atrybucji i raportach debugowania.

Więcej pojęć i kluczowych terminów używanych w naszej dokumentacji znajdziesz w słowniczku Piaskownicy prywatności.

Procedura: sprawdzanie integracji w czasie rzeczywistym

Skonfiguruj system tak, aby generował raporty debugowania z sukcesem. Dowiedz się, jak to zrobić w artykule Część 2. Konfigurowanie raportów debugowania.
Po wdrożeniu kodu raportowania atrybucji sprawdzaj w czasie rzeczywistym, czy na Twoim punkcie końcowym pojawiają się raporty debugowania o udanym działaniu. Jeśli tak, konfiguracja raportowania atrybucji działa prawidłowo.
Raporty debugowania o udanych konwersjach są wysyłane tylko wtedy, gdy dochodzi do konwersji. Zamiast tego możesz sprawdzić, czy integracja jest prawidłowo skonfigurowana niezależnie od konwersji, czyli czy źródła zostały zarejestrowane. Aby to zrobić, możesz polegać na udanym rejestrowaniu źródeł w szczegółowych raportach debugowania. Dowiedz się, jak je skonfigurować w artykule Część 2. Konfigurowanie raportów debugowania.

Instrukcje: analiza strat i rozwiązywanie problemów z integracją

Aby porównać wyniki pomiaru konwersji na podstawie plików cookie z raportami atrybucji, użyj kluczy debugowania i zmapuj konwersje z plików cookie z raportami debugowania. Pamiętaj, że raporty debugowania są wysyłane natychmiast do Twojego punktu końcowego.

Omówienie

Użyj kluczy debugowania (para <source_debug_key, trigger_debug_key>), aby zmapować konwersje z użyciem plików cookie na raporty debugowania o udanych działaniach. Czy w przypadku każdej konwersji z wykorzystaniem pliku cookie w momencie konwersji otrzymano odpowiedni raport debugowania?

Jeśli tak: w przypadku wszystkich tych raportów debugowania o udanych wynikach możesz otrzymać raport atrybucji (z kilkoma wyjątkami). Aby uzyskać więcej informacji, zapoznaj się z scenariuszem raportu debugowania z pozytywnym wynikiem.

Jeśli nie: oznacza to, że konwersja nie została zarejestrowana w raportowaniu atrybucji. Aby mapować konwersje z plików cookie na szczegółowe raporty debugowania, użyj pary <source_debug_key, trigger_debug_key> (lub klucza debugowania źródła, jeśli klucz debugowania nie jest dostępny). Czy w przypadku każdej z tych konwersji w jakimś momencie (źródło lub czas aktywacji) otrzymano szczegółowy raport debugowania?

Jeśli nie otrzymasz szczegółowego raportu z debugowania: może to być spowodowane zachowaniem użytkownika lub problemem z integracją. Aby uzyskać więcej informacji, zapoznaj się z scenariuszem braku raportu debugowania.
Jeśli otrzymasz szczegółowy raport z debugowania, sprawdź pole type.
- Jeśli type to source-success: oznacza to, że źródło zostało zarejestrowane, ale nie udało się zarejestrować wyzwalacza. Aby dowiedzieć się, dlaczego raport debugowania powodzenia jest niedostępny, poszukaj odpowiedniego obszernego raportu debugowania dowolnego innego typu.⏤ Ten raport wskaże problem po stronie wyzwalacza.
- Jeśli type to cokolwiek inne: źródło lub wyzwalacz nie zostały zarejestrowane. typepokazuje, dlaczego. Brakuje raportu atrybucji (i raportu debugowania powodzenia). W zależności od type szczegółowego raportu z debugowania możesz użyć tych informacji jako punktu danych do analizy strat (czyli nie musisz nic robić) lub zgłosić błąd lub rozwiązać problem z implementacją. Aby uzyskać szczegółowe informacje, zapoznaj się z szczegółowym scenariuszem raportu debugowania.

Możliwe scenariusze

Raport debugowania o sukcesie

Jeśli w przypadku danej konwersji związanej z ciasteczkiem otrzymasz raport debugowania z oznaczeniem „Sukces”, oznacza to, że konwersja została zarejestrowana w raportowaniu atrybucji.

Możesz później otrzymać raport atrybucji dotyczący tej konwersji⏤, z kilkoma wyjątkami:

Zachowania użytkownika: wyczyszczenie danych po konwersji i przed wysłaniem raportu o przypisaniu, zamknięcie przeglądarki itp. Jeśli użytkownik zamknie przeglądarkę po konwersji i nie otworzy jej przez tydzień, raport nie zostanie wysłany przez co najmniej tydzień. Możesz uznać to opóźnienie za stratę.
Dotyczy tylko poziomu Zdarzenia: raport na poziomie zdarzenia jest zastępowany innym raportem o wyższym priorytecie.
Możliwe problemy z siecią.

Szczegółowy raport debugowania typu `source-success`

Jeśli w przypadku źródła danej konwersji z użyciem pliku cookie otrzymasz szczegółowy raport debugowania typu source-success, oznacza to, że rejestracja źródła przebiegła pomyślnie. W zależności od tego, czy rejestracja reguły się powiedzie, możesz otrzymać raport dotyczący tej konwersji.

Jest jednak jeden wyjątek:

szczegółowy raport debugowania dowolnego innego typu.

Jeśli w przypadku danej konwersji z użyciem pliku cookie otrzymasz obszerny raport debugowania innego typu, nie otrzymasz raportu debugowania o udanym działaniu, a w konsekwencji nie otrzymasz też raportu atrybucji⏤, ponieważ obszerny raport oznacza, że wystąpił błąd, który można zgłosić. coś uniemożliwiło rejestrację źródła, rejestrację reguły, wygenerowanie raportu lub wysłanie raportu; Możliwe przyczyny:

Ograniczenia dotyczące prywatności
Limity pamięci
Reguły niestandardowe
Problem z implementacją w kodzie
Błąd przeglądarki

Niektóre z nich są oczekiwane. Rodzaj działania zależy od typekażdego szczegółowego raportu. Zapoznaj się z pełnym opisem raportów.

Brak raportów debugowania

Jeśli w przypadku danej konwersji z użyciem pliku cookie otrzymasz tylko raport atrybucji (nie raport debugowania z udanymi konwersjami ani szczegółowy raport debugowania), oznacza to, że coś uniemożliwiło wygenerowanie raportów debugowania. Możliwe przyczyny:

preferencje użytkownika (użytkownik wyłączył pliki cookie innych firm);
Brak pliku cookie lub kluczy debugowania (usunięcie klucza debugowania z powodu braku pliku cookie). W chrome://attribution-internals otwórz kartę Dzienniki i sprawdź, czy pojawia się tam jakiś problem.
problemy z siecią, które wystąpiły w źródle lub w czasie działania, ale nie w momencie wysyłania raportu atrybucji;

Czy otrzymujesz raporty atrybucji?

Jest to podzbiór przypadku, gdy nie otrzymano raportu debugowania: jeśli w przypadku danej konwersji z wykorzystaniem pliku cookie nie otrzymano żadnych raportów (ani raportu debugowania, ani raportu atrybucji), oznacza to, że wystąpił błąd, którego nie można zgłosić. Możliwe przyczyny:

Podstawowy problem z integracją. Dowiedz się, jak rozwiązywać te problemy w sekcji Rozwiązywanie podstawowych problemów z integracją.
Możliwe problemy z siecią.
preferencje użytkownika w ustawieniach przeglądarki, np. wyłączona Piaskownica prywatności;

Szczegółowe raporty debugowania

Każdy szczegółowy raport debugowania zawiera pole type, w którym podana jest przyczyna odrzucenia odpowiedniego raportu atrybucji. Na podstawie tego dokumentu możesz się dowiedzieć, jakie działania należy podjąć w przypadku każdego type raportu szczegółowego.

Uwaga: jeśli type raportu szczegółowego zaczyna się od trigger-event, może być generowany tylko w przypadku zdarzeń źródłowych lub zdarzeń wyzwalających, które są powiązane z raportami na poziomie zdarzenia. Jeśli szczegółowy raport type zaczyna się od trigger-aggregate, może być generowany tylko w przypadku zdarzeń źródłowych lub zdarzeń aktywujących, które są powiązane z raportami podlegającymi agregacji. W pozostałych przypadkach dotyczy on albo zdarzenia, albo zbiorczego raportu.

Rejestracja źródła się powiodła

Źródło zostało zarejestrowane.

source-success: Szczegóły i tekst raportu

Raporty dotyczące ograniczeń związanych z ochroną prywatności

Te raporty są oczekiwane. Ograniczenia te mają na celu ochronę prywatności i ograniczenie wycieku danych o tożsamości użytkownika w różnych witrynach.

source-destination-limit: Szczegóły i treść raportu
source-noised: Szczegóły i treść raportu
trigger-attributions-per-source-destination-limit: Szczegóły i treść raportu
trigger-reporting-origin-limit: Szczegóły i treść raportu
trigger-event-noise: Szczegóły i treść raportu
trigger-event-excessive-reports: Wygenerowany, gdy liczba raportów przekroczy limit. W przypadku wyświetleń możesz zarejestrować maksymalnie 1 konwersję, a w przypadku kliknięć – 3 konwersje. Pamiętaj, że możesz skonfigurować, które raporty chcesz otrzymywać, ustawiając priorytety. Szczegóły i treść raportu

Raporty o ograniczeniach dotyczących miejsca na dane

Te raporty są oczekiwane. Ograniczenia te wskazują na ograniczenia miejsca na dane, aby zapobiec nadmiernemu zużyciu zasobów.

source-storage-limit: Szczegóły i treść raportu
trigger-event-storage-limit: Szczegóły i treść raportu
trigger-aggregate-storage-limit: Szczegóły i tekst raportu

Raporty reguł niestandardowych

Te raporty są oczekiwane, jeśli używasz filtrowania, deduplikacji, priorytetów lub filtrowania na podstawie okresu. W razie potrzeby sprawdź odpowiednie reguły niestandardowe, aby się upewnić, że raport odpowiadający temu obszernemu raportowi jest rzeczywiście raportem, który chcesz odrzucić. Jeśli to prawda, nie musisz nic robić.

trigger-no-matching-filter-data: Szczegóły i treść raportu
trigger-event-no-matching-configuration: Szczegóły i treść raportu
trigger-event-deduplicated: Szczegóły i treść raportu
trigger-aggregate-deduplicated: Szczegóły i treść raportu
trigger-event-low-priority: Szczegóły i treść raportu
trigger-event-report-window-passed: Szczegóły i treść raportu
trigger-aggregate-report-window-passed: Szczegóły i treść raportu

Inne szczegółowe raporty

Te raporty mogą wskazywać na potencjalne problemy z wdrożeniem kodu.

trigger-no-matching-source: Może to być problem z implementacją. Sprawdź, czy konfiguracja <reporting origin, destination> nie jest nieprawidłowa. Może to być też prawidłowy sposób działania interfejsu API. Może się to zdarzyć np. wtedy, gdy użytkownik wyczyścił dane w okresie między obejrzeniem reklamy a dokonaniem konwersji lub gdy użytkownik dokonał konwersji, nie widząc powiązanej z nią reklamy. Szczegóły i treść raportu
trigger-aggregate-no-contributions: Prawdopodobnie nie jest to zachowanie, jakiego oczekujesz od kodu. Rozwiąż problemy z kodem rejestracji wyzwalacza. Upewnij się, że konfiguracja wkładu jest prawidłowa. Szczegóły i treść raportu
trigger-aggregate-insufficient-budget: Prawdopodobnie nie jest to zachowanie, jakiego oczekujesz od kodu. Sprawdź kod rejestracji reguły, aby upewnić się, że suma wszystkich wkładów nie przekracza budżetu wkładu. Szczegóły i treść raportu

nieoczekiwane błędy (potencjalne błędy przeglądarki);

Te raporty są nieoczekiwane. Mogą być spowodowane błędem w przeglądarce. Zgłoś błąd i wskaż w opisie kroki, które należy wykonać, aby go odtworzyć.

source-unknown-error: Szczegóły i treść raportu
trigger-unknown-error: Szczegóły i tekst raportu

Przykład analizy strat

Krok 1. Konfiguracja i mapowanie za pomocą plików cookie

Aby skonfigurować system tak, aby generował raporty debugowania z pełnymi informacjami i raporty debugowania z pełnymi informacjami o udanych testach, wykonaj instrukcje podane w sekcji Część 2. Konfigurowanie raportów debugowania.

Dzięki temu możesz używać informacji o konwersjach opartych na plikach cookie do wyszukiwania odpowiednich raportów debugowania lub raportów atrybucji.

Krok 2. Określ, które rejestracje się udały, a które nie

W tym przykładzie założymy, że za pomocą systemu opartego na plikach cookie zarejestrowano 100 konwersji.

Za każdym razem, gdy rejestrujesz konwersję opartą na plikach cookie, szukaj raportu debugowania sukcesu (wysyłanego natychmiast), który zawiera tę samą parę <source_debug_key, trigger_debug_key> co ta konwersja.

Załóżmy, że otrzymasz raport debugowania o skuteczności dotyczący 70 konwersji z plików cookie.

Raporty o skuteczności oznaczają, że udało się zarejestrować przypisanie, więc możesz założyć, że otrzymasz raport przypisania, który odpowiada każdemu raportowi o skuteczności (z pewnymi wyjątkami).
Możesz zdecydować się na monitorowanie tych wyjątków. Ponieważ raporty atrybucji są wysyłane do punktu końcowego w ciągu kilku dni lub tygodni (w zależności od daty wygaśnięcia), znajdź raporty atrybucji, które mają ten sam klucz debugowania co każdy raport debugowania z udanymi wynikami. Poczekaj chwilę: raporty mogą nie zostać wysłane natychmiast po zakończeniu każdego okresu. Załóżmy, że znajdziesz tylko 60 raportów atrybucji. 10 brakujących raportów atrybucji może być spowodowane zachowaniem użytkownika.

Uwaga: możliwe, że masz raporty atrybucji na poziomie zdarzenia, które nie są mapowane na konwersje oparte na plikach cookie. Prawdopodobnie są to raporty z dużą ilością błędów, które zostały wygenerowane losowo przez interfejs API. Możesz to sprawdzić, szukając szczegółowych raportów debugowania typu source-noised, które mają ten sam klucz debugowania źródła co raport na poziomie zdarzenia.

Krok 3. Krótka ocena strat

100 – 70 = 30 brakujących raportów debugowania z udanymi testami. Oznacza to, że te 30 konwersji (które były śledzone w ramach implementacji opartej na plikach cookie) nie zostały zarejestrowane w raportach atrybucji. Nie otrzymasz raportów atrybucji dotyczących tych reklam.

Ponieważ masz 100 konwersji na podstawie plików cookie i tylko 70 konwersji na podstawie atrybucji, Twoja strata wynosi 30%. Masz teraz krótką ocenę strat.

Krok 4. Analiza przyczyn

Aby sprawdzić, dlaczego brakuje tych raportów, poszukaj odpowiednich szczegółowych raportów debugowania, które zostały wysłane w momencie konwersji (rejestracji wyzwalacza) lub wcześniej w momencie rejestracji źródła. Użyj kluczy konwersji opartych na plikach cookie, aby zmapować je na szczegółowe raporty debugowania.

Załóżmy, że jest 10 kluczy, dla których nie ma obszernego raportu debugowania. Sprawdź, czy nie wystąpił problem z integracją. Jeśli nie, może to być spowodowane zachowaniem użytkownika.
Masz 20 szczegółowych raportów z debugowania. Możesz teraz doprecyzować analizę strat. Przeanalizuj pole type w każdym szczegółowym raporcie. Możesz na przykład zauważyć, że:
- 10 raportów (co odpowiada 10% w naszym przykładzie) jest niedostępnych z powodu pending destination limit
- Brak 5 raportów (= 5%), ponieważ trigger-aggregate-no-contributions.
- Brak 5 raportów (= 5%), ponieważ unknown-error.

Krok 5. Podejmij działania i rozwiąż problem

Teraz, gdy już wiesz, dlaczego raporty są niedostępne, możesz podjąć odpowiednie działania.

Rodzaj działania zależy od typekażdego szczegółowego raportu. Szczegółowe informacje znajdziesz w dokumentacji dotyczącej raportów szczegółowych. Na przykład:

pending-destination-limit to funkcja ochrony prywatności. Nie musisz nic robić. Użyj tego numeru jako punktu danych na potrzeby monitorowania i śledzenia.
trigger-aggregate-no-contributions może być oznaką problemu z implementacją po Twojej stronie. Przeanalizuj to dokładniej. Aby rozwiązać ten problem, skorzystaj z szczegółowych informacji w treści raportu.
unknown-error może być oznaką błędu w przeglądarce lub błędu sieci. Jeśli problem będzie się powtarzał, zgłoś go deweloperom przeglądarki.