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

Attribution Reporting: pełny przegląd systemu

Ogólny przegląd połączonych usług na potrzeby raportowania atrybucji, który jest przeznaczony dla decydentów technicznych.

Attribution Reporting API umożliwia technikom reklamowym i reklamodawcom pomiar, kiedy kliknięcie lub wyświetlenie reklamy prowadzi do konwersji, np. zakupu. W zależności od potrzeb biznesowych ten interfejs API korzysta z kombinacji integracji po stronie klienta i po stronie serwera.

Zanim przejdziesz dalej, przeczytaj artykuł Omówienie raportowania atrybucji. Dzięki temu możesz lepiej zrozumieć przeznaczenie interfejsu API i przepływ różnych raportów wyjściowych (raport na poziomie zdarzenia i raporty podsumowujące). Jeśli napotkasz jakieś nieznane terminy, zapoznaj się z słowniczkiem Piaskownicy prywatności.

Dla kogo jest ten artykuł?

Przeczytaj ten artykuł, jeśli:

To Ty podejmujesz decyzje techniczne w sprawie technologii reklamowej lub reklamodawcy. Możesz pracować w obszarach operacyjnych, DevOps, badania danych, IT, marketingu lub w innych obszarach, w których podejmujesz techniczne decyzje dotyczące wdrażania. Zastanawiasz się, jak interfejsy API działają w ramach pomiarów z zachowaniem ochrony prywatności.
Jesteś specjalistą ds. technicznych (np. programistą, operatorem systemu, architektem systemu lub badaczem danych), który będzie konfigurować eksperymenty z tym środowiskiem interfejsu API i usług agregacji.

W tym artykule znajdziesz ogólny, kompleksowy opis działania usług pod kątem interfejsu Attribution Reporting API. Jeśli jesteś specjalistą ds. technicznych, możesz eksperymentować z tym interfejsem API lokalnie.

Przegląd

Interfejs Attribution Reporting API obejmuje wiele usług, które wymagają konkretnej konfiguracji, konfiguracji po stronie klienta i wdrożeń na serwerze. Aby określić, czego potrzebujesz, najpierw:

Podejmuj decyzje projektowe. Określ, jakie informacje chcesz zbierać, sprawdź, jakich konwersji oczekujesz od danej kampanii, i wskaż typ raportu, który chcesz zbierać. Wynikiem końcowym jest co najmniej 1 z 2 typów raportów: raporty na poziomie zdarzenia i raporty podsumowujące.

Do raportowania zawsze są dostępne dwa (a czasem nawet trzy) komponenty, które współdziałają ze sobą:

Komunikacja między witryną a przeglądarką. W systemach opartych na plikach cookie informacje o konwersjach i interakcjach z reklamą są przypisywane do identyfikatora, który umożliwia Ci lub usłudze analitycznej późniejsze dołączenie do tych zdarzeń. Ten interfejs API wiąże konwersje z kliknięciami/wyświetleniami reklam zgodnie z Twoimi instrukcjami, zanim trafią one do analizy. Dlatego kod renderowania reklamy i śledzenie konwersji muszą:
- Informuje przeglądarkę, które konwersje mają być przypisywane do poszczególnych kliknięć lub wyświetleń reklam.
- Wskaż inne dane, które mają zostać uwzględnione w raportach końcowych.
Zbieranie danych. Aby otrzymywać raporty generowane w przeglądarkach użytkowników, musisz mieć punkt końcowy kolektora. Dane wyjściowe przeglądarek mogą być 1 z 2 raportów: raportów na poziomie zdarzenia lub raportów zbiorczych (zaszyfrowanych, używanych do generowania raportów podsumowujących).

Jeśli masz raporty skumulowane, potrzebny będzie trzeci komponent:

Generowanie raportu podsumowania. Zbiorcze tworzenie raportów zbiorczych i przetwarzanie ich za pomocą usługi agregacji w celu wygenerowania raportu podsumowania.

Decyzje projektowe

Kluczową zasadą raportowania atrybucji są decyzje dotyczące wczesnego projektowania. To Ty decydujesz, jakie dane chcesz zbierać, w jakich kategoriach i jak często je przetwarzać. Raporty wyjściowe zapewniają wgląd w Twoje kampanie lub firmę.

Raport wyjściowy może wyglądać tak:

Raporty na poziomie zdarzenia łączą kliknięcie lub wyświetlenie określonej reklamy (po stronie reklamy) z danymi od strony konwersji. Aby chronić prywatność użytkowników, ograniczając łączenie ich tożsamości z różnych witryn, dane po stronie konwersji są bardzo ograniczone, a zaszumiane (co oznacza, że w niewielkim odsetku przypadków zamiast rzeczywistych raportów są wysyłane dane losowe).
Raporty podsumowujące nie są powiązane z konkretnym zdarzeniem po stronie reklamy. Raporty te zapewniają bardziej szczegółowe dane o konwersjach oraz umożliwiają łączenie danych o kliknięciach i wyświetleniach z danymi o konwersjach.

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

Ostateczne dane wyjściowe możesz też traktować jako dane wejściowe dla narzędzi, których używasz do podejmowania decyzji. Jeśli np. generujesz raporty podsumowujące, aby sprawdzić, ile konwersji doprowadziło do pewnej łącznej wartości wydatków, może to ułatwić Twojemu zespołowi podjęcie decyzji o kierowaniu kolejnej kampanii reklamowej, by uzyskać wyższe łączne wydatki.

Po wybraniu elementów, które chcesz mierzyć, możesz skonfigurować po stronie klienta interfejs Attribution Reporting API.

Komunikacja między przeglądarką a witryną

Źródła atrybucji w witrynie wydawcy łączą się z regułami w witrynie reklamodawcy.

Przebieg zdarzeń atrybucji

Wyobraź sobie witrynę wydawcy, w której wyświetlane są reklamy. Każdy reklamodawca i dostawca technologii reklamowych chce poznać interakcje z jego reklamami i przypisać konwersje do właściwej reklamy. Raporty (na poziomie zdarzenia i zbiorcze) będą generowane w ten sposób:

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 spowoduje zarejestrowanie źródła po kliknięciu:
```
<a href="https://shoes.example/landing" 
  attributionsrc="http://adtech.example/register-source?..."
  target="_blank">
Click me</a>
```
Oto przykład grafiki, która podczas wyświetlania spowoduje zarejestrowanie źródła:
```
<img href="https://advertiser.example/landing" 
  attributionsrc="https://adtech.example/register-source?..."/>
```
Zamiast elementów HTML można też używać wywołań JavaScript.

Oto przykład kodu JavaScript z użyciem elementu window.open(). Aby uniknąć problemów ze znakami specjalnymi, adres URL jest zakodowany.
```
const encodedUrl = encodeURIComponent(
  'https://adtech.example/attribution_source?ad_id=...');
window.open(
  "https://shoes.example/landing",
  "_blank",
  attributionsrc=${encodedUrl});
```

Gdy użytkownik kliknie lub wyświetli reklamę, przeglądarka wysyła żądanie GET do usługi attributionsrc, zwykle do punktu końcowego reklamodawcy lub dostawcy technologii reklamowych.
Po otrzymaniu tej prośby reklamodawca lub dostawca technologii reklamowych decyduje się na zarejestrowanie zdarzeń źródłowych na potrzeby interakcji z reklamą, aby konwersje mogły być później przypisywane do tej reklamy. W tym celu reklamodawca lub dostawca technologii reklamowych umieszcza w odpowiedzi specjalny nagłówek HTTP. Dołącza on do tych niestandardowych danych w nagłówku, które dostarczają informacji o zdarzeniu źródłowym (kliknięciu lub wyświetleniu reklamy). Jeśli w przypadku tej reklamy dojdzie do konwersji, te dane niestandardowe pojawią się w raporcie atrybucji.
Później użytkownik odwiedza witrynę reklamodawcy.
Na każdej odpowiedniej stronie w witrynie reklamodawcy – np. na stronie z potwierdzeniem zakupu lub stronie produktu – piksel konwersji (element <img>) lub wywołanie JavaScriptu wysyła żądanie do https://adtech.example/conversion?param1=...&param2=....
Usługa dostępna pod tym adresem URL – zazwyczaj reklamodawca lub dostawca technologii reklamowych – otrzymuje żądanie. Postanawia to klasyfikować jako konwersję, więc musi poinstruować przeglądarkę, aby zarejestrowała konwersję, czyli wywołać atrybucję. W tym celu reklamodawca lub dostawca technologii reklamowych umieszcza w odpowiedzi na żądanie piksela specjalny nagłówek HTTP zawierający niestandardowe dane o konwersji.
Przeglądarka na lokalnym urządzeniu użytkownika otrzymuje tę odpowiedź i dopasowuje dane o konwersjach do pierwotnego zdarzenia źródłowego (kliknięcia lub wyświetlenia reklamy). Więcej informacji znajdziesz w sekcji Dopasowanie źródeł do reguł.
Przeglądarka planuje wysłanie raportu do: attributionsrc. Raport zawiera:
1. Niestandardowe dane konfiguracji atrybucji, 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.
Później przeglądarka wysyła raporty do punktu końcowego zdefiniowanego w zasadzie attributionsrc (z pewnym opóźnieniem i szumem). Raporty zbiorcze są szyfrowane, a raporty na poziomie zdarzenia nie.

Reguły atrybucji (witryna reklamodawcy)

Reguła atrybucji to zdarzenie informujące przeglądarkę, że ma zarejestrować konwersje.

Zalecamy rejestrowanie konwersji, które są najważniejsze dla reklamodawcy, np. zakupów. Raporty podsumowujące pozwalają rejestrować różne typy konwersji i metadane.

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

Dopasuj źródła do reguł

Gdy przeglądarka otrzymuje odpowiedź związaną z regułą atrybucji, przeglądarka korzysta z pamięci lokalnej, aby znaleźć źródło pasujące zarówno do źródła aktywatora atrybucji, jak i do eTLD+1 adresu URL strony.

Jeśli np. shoes.example/shoes123 przeglądarka otrzyma aktywator atrybucji z adtech.example, przeglądarka szuka w pamięci lokalnej źródła pasującego zarówno do atrybutu adtech.example, jak i shoes.example.

Filtry (lub reguły niestandardowe) mogą określać, kiedy aktywator jest dopasowywany do określonego źródła. Możesz np. ustawić filtr, który będzie zliczać tylko konwersje dla określonej kategorii produktów i ignorować wszystkie inne kategorie. Filtry i modele określania priorytetów umożliwiają bardziej zaawansowane raportowanie atrybucji.

Jeśli w pamięci lokalnej znajdzie się wiele źródeł atrybucji, przeglądarka wybiera to, które zostało zapisane jako ostatni. W niektórych przypadkach źródła atrybucji o najwyższym priorytecie przeglądarka wybiera źródło o najwyższym priorytecie.

Gromadzenie danych

Reguła atrybucji dopasowana do odpowiedniego źródła jest łącznie wysyłana przez przeglądarkę w postaci raportu do punktu końcowego raportowania na serwerze należącym do technologii reklamowej (czasami nazywanym punktem końcowym zbierania danych lub usługą zbierającą). Mogą to być raporty na poziomie zdarzenia lub raporty zbiorcze.

Raporty zbiorcze służą do generowania raportów podsumowujących. Raport zbiorczy to połączenie danych zebranych z reklamy (w witrynie wydawcy) i danych o konwersjach (z witryny reklamodawcy). Dane te są generowane i szyfrowane przez przeglądarkę na urządzeniu użytkownika przed ich zebraniem przez technologię reklamową.

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

Jeśli interesują Cię tylko raporty na poziomie zdarzenia, jest to ostatni element infrastruktury. Jeśli jednak chcesz generować raporty podsumowujące, musisz przetwarzać te raporty za pomocą dodatkowej usługi.

Generowanie raportu podsumowującego

Raporty podsumowujące możesz generować za pomocą usługi agregacji (obsługiwanej przez technika reklamową). Usługa agregacji dodaje szum, aby chronić prywatność użytkowników i zwraca ostateczny raport podsumowujący.

Raporty zbiorcze są zbierane, grupowane i wysyłane do środowiska technologii reklamowych. — Ten diagram przedstawia asynchroniczny przepływ danych z punktu końcowego zbierania danych, grupując raporty przez przetwarzanie w usłudze agregacji należącej do technologii reklamowych.

Po zgrupowaniu zebranych raportów zbiorczych są one przetwarzane przez usługę agregacji. Koordynator przekazuje klucze odszyfrowywania tylko akredytowanym wersjom usługi agregacji. Następnie usługa agregacji odszyfrowuje dane, agreguje je i dodaje szum, a następnie zwraca wyniki w formie raportu podsumowującego.

Zbiorcze raporty zbiorcze

Przed przetworzeniem raportów zbiorczych należy je grupować. Taka grupa składa się ze strategicznie pogrupowanych raportów zbiorczych. Twoja strategia będzie najprawdopodobniej odzwierciedlała dane z określonego okresu (np. codziennie lub co tydzień). Ten proces może odbywać się na tym samym serwerze, który pełni funkcję punktu końcowego raportowania.

Wsady powinny zawierać wiele raportów, aby zapewnić wysoki współczynnik sygnału do szumu.

Dłuższe przedziały czasu zapewniają mniej zaszumionych wyników. — Porównaj czas oczekiwania 1 dzień i 1 tydzień. W ciągu 1 godziny uzyskasz mniejszą wartość podsumowania, a prawdopodobnie bardziej zaszumione wyniki. Za 1 dzień otrzymasz większą wartość podsumowania, więc prawdopodobnie nie będzie przekazywać więcej szumu.

Okresy grupowe mogą się zmieniać w każdej chwili, aby rejestrować określone zdarzenia, o których spodziewasz się większego ruchu, np. wyprzedaż roczną. Okres grupowania można zmienić bez konieczności zmiany źródeł atrybucji lub reguł.

Usługa agregacji

Usługa agregująca odpowiada za przetwarzanie raportów zbiorczych w celu generowania raportów podsumowujących. Raporty zbiorcze są zaszyfrowane i mogą być odczytywane tylko przez usługę agregacji, która działa w zaufanym środowisku wykonawczym (TEE).

Usługa agregacji żąda od koordynatora kluczy odszyfrowywania w celu odszyfrowania i agregacji danych. Po odszyfrowaniu i zagregowaniu wyniki są zaszumiane w celu ochrony prywatności i zwracane w formie raportu podsumowującego.

Aby lokalnie przetestować usługę agregacji, specjaliści mogą generować raporty w formie agregacji. Możesz też testować za pomocą zaszyfrowanych raportów w AWS za pomocą enklaw Nitro.

Co dalej?

Chcemy angażować użytkowników w rozmowy, aby mieć pewność, że utworzymy interfejs API, który będzie działał dla wszystkich.

Omów interfejs API

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

Eksperymenty z interfejsem API

Możesz eksperymentować i brać udział w rozmowach o interfejsie Attribution Reporting API.