Attribution Reporting: pełny przegląd systemu

Ogólne omówienie połączonych usług na potrzeby raportowania atrybucji, przeznaczone dla osób podejmujących decyzje techniczne.

Interfejs Attribution Reporting API umożliwia dostawcom technologii reklamowych i reklamodawcom pomiar, kiedy kliknięcie lub wyświetlenie reklamy prowadzi do konwersji, np. zakupu. Ten interfejs API korzysta z kombinacji integracji po stronie klienta i po stronie serwera, w zależności od potrzeb Twojej firmy.

Zanim przejdziesz dalej, zapoznaj się z omówieniem raportowania atrybucji. Pomoże Ci to zrozumieć przeznaczenie interfejsu API i przepływ różnych raportów wyjściowych (raportu na poziomie zdarzenia i raportów podsumowujących). Jeśli napotkasz nieznane terminy, zapoznaj się z glosariuszem Piaskownicy prywatności.

Dla kogo jest przeznaczony ten dokument?

Ten dokument jest przeznaczony dla Ciebie, jeśli:

• Jesteś osobą podejmującą decyzje techniczne w firmie z branży technologii reklamowych lub w firmie reklamodawcy. Możesz pracować w zespole ds. operacji, DevOps, analizy danych, IT, marketingu lub w innej roli, w której podejmujesz decyzje dotyczące wdrożeń technicznych. Zastanawiasz się, jak interfejsy API działają w przypadku pomiarów chroniących prywatność.
• Jesteś osobą techniczną (np. deweloperem, operatorem systemu, architektem systemu lub specjalistą ds. danych), która będzie konfigurować eksperymenty w tym środowisku interfejsu API i usługi agregacji.

W tym dokumencie znajdziesz ogólne wyjaśnienie działania usług interfejsu Attribution Reporting API. Jeśli jesteś osobą techniczną, możesz eksperymentować z tym interfejsem API lokalnie.

Przegląd

Interfejs Attribution Reporting API składa się z wielu usług, które wymagają określonej konfiguracji, ustawień po stronie klienta i wdrożeń serwera. Aby określić, czego potrzebujesz, najpierw:

• Podejmowanie decyzji projektowych Określ, jakie informacje chcesz zbierać, jakie konwersje oczekujesz w przypadku poszczególnych kampanii i który typ raportu chcesz zbierać. Dane wyjściowe to jeden lub oba z tych 2 typów raportów: raporty na poziomie zdarzenia i raporty podsumowujące.

Zawsze są 2 (a czasami 3) komponenty, które współpracują ze sobą, aby obsługiwać raportowanie:

• Komunikacja między witryną a przeglądarką W systemach opartych na plikach cookie informacje o konwersjach i interakcjach z reklamami są powiązane z identyfikatorem, który umożliwia Tobie lub usłudze analitycznej późniejsze łączenie tych zdarzeń. Dzięki temu interfejsowi API przeglądarka kojarzy konwersje z kliknięciami lub wyświetleniami reklam na podstawie Twoich instrukcji, zanim dane zostaną przekazane do analizy. Dlatego kod renderowania reklamy i śledzenie konwersji muszą:
  • Informuje przeglądarkę, które konwersje powinny być przypisywane do których kliknięć lub wyświetleń reklam.
  • Wskaż inne dane, które mają być uwzględnione w raportach końcowych.
• Zbieranie danych. Aby otrzymywać raporty generowane w przeglądarkach użytkowników, musisz mieć punkt końcowy zbierania danych. Dane wyjściowe z przeglądarek mogą mieć postać jednego z 2 rodzajów raportów: raportów na poziomie zdarzenia i raportów z możliwością agregacji (które są szyfrowane i używane do generowania raportów podsumowujących).

Jeśli zbierasz raporty, które można agregować, potrzebujesz trzeciego komponentu:

• Generowanie raportu zbiorczego Zbiorczo przesyłaj raporty możliwe do agregacji i używaj usługi do agregacji do ich przetwarzania w celu wygenerowania raportu podsumowującego.

Decyzje projektowe

Kluczową zasadą interfejsu Attribution Reporting są wczesne decyzje projektowe. To Ty decydujesz, jakie dane chcesz zbierać w poszczególnych kategoriach i jak często je przetwarzać. Raporty wyjściowe dostarczają informacji o Twoich kampaniach lub firmie.

Raport wyjściowy może być:

• Raporty na poziomie zdarzenia łączą konkretne kliknięcie lub wyświetlenie reklamy (po stronie reklamy) z danymi o konwersji. Aby chronić prywatność użytkowników przez ograniczenie łączenia tożsamości użytkowników w różnych witrynach, dane po stronie konwersji są bardzo ograniczone i zawierają szum (co oznacza, że w niewielkim odsetku przypadków zamiast rzeczywistych raportów wysyłane są losowe dane).
• Raporty podsumowujące nie są powiązane z konkretnym zdarzeniem po stronie reklamy. Raporty te zawierają bardziej szczegółowe dane o konwersjach i zapewniają większą elastyczność w zakresie łączenia danych o kliknięciach i wyświetleniach z danymi o konwersjach.

Wybór raportu określa, jakie dane musisz zbierać.

Możesz też traktować wynik końcowy jako dane wejściowe dla narzędzi, których używasz do podejmowania decyzji. Jeśli na przykład generujesz raporty podsumowujące, aby określić, ile konwersji doprowadziło do określonej łącznej wartości wydatków, może to pomóc Twojemu zespołowi zdecydować, na co powinna być ukierunkowana następna kampania reklamowa, aby generować wyższe łączne wydatki.

Gdy zdecydujesz, co chcesz mierzyć, możesz skonfigurować klienta interfejsu Attribution Reporting API.

Komunikacja między witryną a przeglądarką

Przepływ zdarzeń atrybucji

Wyobraź sobie witrynę wydawcy, która wyświetla reklamy. Każdy reklamodawca lub dostawca technologii reklamowych chce dowiedzieć się więcej o interakcjach z jego reklamami i przypisywać konwersje do odpowiednich reklam. Raporty (na poziomie zdarzenia i możliwe do agregowania) będą generowane w ten sposób:

1. W witrynie wydawcy element reklamy (tag <a> lub <img>) jest skonfigurowany ze specjalnym atrybutem attributionsrc. Jego wartością jest adres URL, np. https://adtech.example/register-source/ad_id=....

   Oto przykład linku, który po kliknięciu zarejestruje źródło:

   <a href="https://shoes.example/landing"
     attributionsrc="http://adtech.example/register-source?..."
     target="_blank">
   Click me</a>
   

   Oto przykład obrazu, który spowoduje zarejestrowanie źródła po wyświetleniu:

   <img href="https://advertiser.example/landing"
     attributionsrc="https://adtech.example/register-source?..."/>
   

   Zamiast elementów HTML można też używać wywołań JavaScriptu.

   Oto przykład kodu JavaScript z użyciem właściwości window.open(). Pamiętaj, że adres URL jest zakodowany, aby uniknąć problemów ze znakami specjalnymi.

   const encodedUrl = encodeURIComponent(
     'https://adtech.example/attribution_source?ad_id=...');
   window.open(
     "https://shoes.example/landing",
     "_blank",
     `attributionsrc=${encodedUrl}`);
   

2. Gdy użytkownik kliknie lub wyświetli reklamę, przeglądarka wyśle żądanie GET do attributionsrc – zwykle do punktu końcowego reklamodawcy lub dostawcy technologii reklamowych.

3. Po otrzymaniu tej prośby reklamodawca lub dostawca technologii reklamowej decyduje, czy ma wydać przeglądarce polecenie zarejestrowania zdarzeń źródłowych dotyczących interakcji z reklamą, aby później można było przypisać do niej konwersje. W tym celu reklamodawca lub dostawca technologii reklamowych umieszcza w odpowiedzi specjalny nagłówek HTTP. Dołącza do tego nagłówka dane niestandardowe, które zawierają informacje o zdarzeniu źródłowym (kliknięciu lub wyświetleniu reklamy). Jeśli w przypadku tej reklamy dojdzie do konwersji, te dane niestandardowe zostaną ostatecznie uwzględnione w raporcie o atrybucji.

   

4. Później użytkownik odwiedza witrynę reklamodawcy.

5. Na każdej odpowiedniej stronie witryny reklamodawcy, np. na stronie potwierdzenia zakupu lub stronie produktu, piksel konwersji (element <img>) lub wywołanie JavaScript wysyła żądanie do https://adtech.example/conversion?param1=...&param2=....

6. Usługa pod tym adresem URL – zwykle reklamodawca lub dostawca technologii reklamowych – otrzymuje żądanie. System decyduje, że jest to konwersja, więc musi poinstruować przeglądarkę, aby ją zarejestrowała, czyli wywołała atrybucję. W tym celu reklamodawca lub dostawca technologii reklamowych umieszcza w odpowiedzi na żądanie piksela specjalny nagłówek HTTP, który zawiera niestandardowe dane o konwersji.

7. Przeglądarka na lokalnym urządzeniu użytkownika otrzymuje tę odpowiedź i dopasowuje dane o konwersji do pierwotnego zdarzenia źródłowego (kliknięcia lub wyświetlenia reklamy).

8. Przeglądarka planuje wysłanie raportu do attributionsrc. Ten raport zawiera:

   1. Dane konfiguracji atrybucji niestandardowej, które dostawca technologii reklamowych lub reklamodawca dołączył do zdarzenia źródłowego w kroku 3.
   2. Niestandardowy zbiór danych o konwersjach w kroku 6.

   

9. Później przeglądarka wysyła raporty do punktu końcowego zdefiniowanego w attributionsrc. Dzieje się to z pewnym opóźnieniem i dodaniem szumu. Raporty podlegające agregacji są szyfrowane, a raporty na poziomie zdarzenia – nie.

Reguły atrybucji (witryna reklamodawcy)

Aktywator atrybucji to zdarzenie, które informuje przeglądarkę o konieczności rejestrowania konwersji.

Zalecamy rejestrowanie konwersji, które są najważniejsze dla reklamodawcy, np. zakupów. W raportach podsumowujących można rejestrować wiele typów konwersji i metadanych.

Dzięki temu wyniki zbiorcze będą szczegółowe i dokładne w przypadku tych zdarzeń.

Dopasowywanie źródeł do aktywatorów

Gdy przeglądarka otrzyma odpowiedź na wywołanie atrybucji, uzyskuje dostęp do pamięci lokalnej, aby znaleźć źródło, które pasuje zarówno do pochodzenia wywołania atrybucji, jak i do eTLD+1 adresu URL tej strony.

Na przykład, gdy przeglądarka otrzyma wywołanie atrybucji z domeny adtech.example w domenie shoes.example/shoes123, wyszuka w pamięci lokalnej źródło, które pasuje zarówno do domeny adtech.example, jak i do domeny shoes.example.

Możesz ustawić filtry (lub reguły niestandardowe), aby określić, kiedy reguła ma być dopasowywana do konkretnego źródła. Możesz na przykład ustawić filtr, aby zliczać tylko konwersje w przypadku określonej kategorii produktów i ignorować wszystkie inne kategorie. Filtry i modele ustalania priorytetów umożliwiają tworzenie bardziej zaawansowanych raportów atrybucji.

Jeśli w pamięci lokalnej znajdzie się kilka źródeł atrybucji, przeglądarka wybierze to, które zostało zapisane najpóźniej. W niektórych przypadkach, gdy źródła atrybucji mają przypisany priorytet, przeglądarka wybierze źródło o najwyższym priorytecie.

Zbieranie danych

W połączeniu z odpowiednim źródłem są one wysyłane przez przeglądarkę jako raport do punktu końcowego raportowania na serwerze należącym do dostawcy technologii reklamowej (czasami nazywanym punktem końcowym lub usługą zbierania danych). Mogą to być raporty na poziomie zdarzenia lub raporty zbiorcze.

Raporty z możliwością agregacji służą do generowania raportów podsumowujących. Raport z możliwością agregacji to połączenie danych zebranych z reklamy (w witrynie wydawcy) i danych o konwersjach (z witryny reklamodawcy), które są generowane i szyfrowane przez przeglądarkę na urządzeniu użytkownika, zanim zostaną zebrane przez dostawcę technologii reklamowej.

Raporty na poziomie zdarzenia są opóźnione o 2–30 dni. Raporty, które można agregować, są wysyłane z losowym opóźnieniem w ciągu godziny, a zdarzenia muszą mieścić się w budżecie na udział. Te wybory chronią prywatność i zapobiegają wykorzystywaniu działań poszczególnych użytkowników.

Jeśli interesują Cię tylko raporty na poziomie zdarzenia, to ostatni element infrastruktury, którego potrzebujesz. Jeśli jednak chcesz generować raporty podsumowujące, musisz przetworzyć raporty, które można agregować, za pomocą dodatkowej usługi.

Generowanie raportu zbiorczego

Aby generować raporty podsumowujące, będziesz używać usługi do agregacji (obsługiwanej przez technologię reklamową) do przetwarzania raportów z możliwością agregacji. Usługa do agregacji dodaje szum, aby chronić prywatność użytkowników, i zwraca końcowy raport podsumowujący.

Raporty zbiorcze w pakietach

Zanim będzie można przetworzyć raporty z możliwością agregacji, muszą one zostać zgrupowane. Partia składa się ze strategicznie pogrupowanych raportów z możliwością agregacji. Twoja strategia będzie prawdopodobnie odzwierciedlać określony okres (np. dzienny lub tygodniowy). Ten proces może odbywać się na tym samym serwerze, który pełni funkcję punktu końcowego raportowania.

Partie powinny zawierać wiele raportów, aby zapewnić wysoki stosunek sygnału do szumu.

Okresy przetwarzania zbiorczego mogą się zmieniać w dowolnym momencie, aby umożliwić rejestrowanie konkretnych wydarzeń, w przypadku których spodziewasz się większej liczby konwersji, np. podczas corocznej wyprzedaży. Okres przetwarzania zbiorczego można zmienić bez konieczności zmiany źródeł atrybucji ani wyzwalaczy.

Usługa do agregacji

Usługa do agregacji odpowiada za przetwarzanie raportów podlegających agregacji w celu wygenerowania raportu podsumowującego. Raporty z możliwością agregacji są szyfrowane i może je odczytać tylko usługa do agregacji, która działa w zaufanym środowisku wykonawczym (TEE).

Usługa do agregacji wysyła do koordynatora żądania kluczy odszyfrowywania, aby odszyfrować i zagregować dane. Po odszyfrowaniu i zagregowaniu wyniki są zaszumiane w celu zachowania prywatności i zwracane w postaci raportu podsumowującego.

Specjaliści mogą generować raporty w formie zwykłego tekstu, które można agregować, aby lokalnie testować usługę do agregacji. Możesz też przeprowadzić testy z zaszyfrowanymi raportami w AWS z użyciem Nitro Enclaves.

Co dalej?

Chcemy z Tobą porozmawiać, aby mieć pewność, że tworzymy interfejs API, który będzie przydatny dla wszystkich.

Omówienie interfejsu API

Podobnie jak inne interfejsy API Piaskownicy prywatności, ten interfejs API jest udokumentowany i omawiany publicznie.

Eksperymentowanie z interfejsem API

Możesz eksperymentować i brać udział w rozmowach na temat interfejsu Attribution Reporting API.