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

Attribution Reporting: pełny przegląd systemu
Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Ogólny opis połączonych usług na potrzeby raportowania atrybucji, przeznaczony dla osób podejmujących decyzje techniczne.

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

Zanim przejdziesz dalej, przeczytaj artykuł Omówienie raportów o przypisaniu. Dzięki temu lepiej zrozumiesz cel interfejsu API i przepływ danych w różnych raportach wyjściowych (raport na poziomie zdarzenia i raporty podsumowania). Jeśli natrafisz na nieznane terminy, zajrzyj do glosariusza Piaskownicy prywatności.

Dla kogo jest przeznaczony ten dokument?

Ten dokument powinieneś przeczytać, jeśli:

Jesteś osobą podejmującą decyzje techniczne w firmie zajmującej się technologiami reklamowymi lub reklamodawcą. Możesz pracować w zespole operacyjnym, dziale DevOps, dziale analizy danych, dziale IT, dziale marketingu lub w innej roli, w której podejmujesz decyzje dotyczące technicznego wdrożenia. Chcesz się dowiedzieć, jak działają interfejsy API do pomiarów z zachowaniem prywatności.
Jesteś praktykiem technicznym (np. deweloperem, operatorem systemu, architektem systemowym lub specjalistą ds. danych), który będzie konfigurować eksperymenty z tym interfejsem API i środowiskiem usługi agregacji.

W tym dokumencie znajdziesz ogólne, kompleksowe omówienie działania usług w ramach interfejsu Attribution Reporting API. Jeśli jesteś specjalistą ds. technicznych, możesz eksperymentować z tym interfejsem API lokalnie.

Omówienie

Interfejs Attribution Reporting API składa się z wielu usług, które wymagają odpowiedniej konfiguracji, konfiguracji po stronie klienta i wdrażania na serwerze. Aby określić, czego potrzebujesz:

Podejmowanie decyzji projektowych. Określ, jakie informacje chcesz zbierać, jakie konwersje chcesz mierzyć w danej kampanii i jaki typ raportu chcesz tworzyć. Wynikiem działania interfejsu jest jeden lub oba typy raportów: raporty na poziomie zdarzenia i raporty podsumowujące.

Zawsze występują 2 (czasami 3) komponenty, które współpracują ze sobą na potrzeby raportowania:

Komunikacja między witryną a przeglądarką. W systemach opartych na plikach cookie informacje o konwersjach i zaangażowaniu w reklamy są dołączane do identyfikatora, który umożliwia Ci lub usłudze analitycznej późniejsze łączenie tych zdarzeń. Dzięki temu interfejsowi API przeglądarka łączy konwersje z kliknięciami lub wyświetleniami reklamy na podstawie Twoich instrukcji, zanim przekaże je do analizy. Dlatego kod renderowania reklamy i śledzenie konwersji muszą:
- Powiedz przeglądarce, które konwersje powinny być przypisywane do których kliknięć lub wyświetleń reklam.
- Wskazać inne dane, które mają być uwzględnione w ostatecznych raportach.
Zbieranie danych. Aby otrzymywać raporty generowane w przeglądarkach użytkowników, musisz użyć punktu końcowego kolektora. Dane wyjściowe z przeglądarek mogą być jednym z 2 możliwych raportów: raportami na poziomie zdarzenia i raportami możliwymi do agregacji (które są zaszyfrowane i służą do generowania raportów podsumowujących).

Jeśli zebrane przez Ciebie raporty można agregować, potrzebujesz 3 elementu:

Generowanie raportu zbiorczego. Przetwarzać zbiorczo raporty i wykorzystywać usługę do agregacji do generowania raportów podsumowujących.

Decyzje projektowe

Kluczową zasadą raportowania atrybucji są wczesne decyzje projektowe. To Ty decydujesz, jakie dane zbierać w jakich kategoriach i jak często je przetwarzać. Raporty wyjściowe zawierają informacje o kampaniach lub Twojej firmie.

Raport wyjściowy może być:

Raporty na poziomie zdarzenia powiązać kliknięcie lub wyświetlenie reklamy (po stronie reklamy) z danymi po stronie konwersji. Aby chronić prywatność użytkowników przez ograniczenie łączenia tożsamości użytkowników w różnych witrynach, dane o konwersjach są bardzo ograniczone i nieprecyzyjne (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. Te raporty zawierają bardziej szczegółowe dane o konwersjach i dają Ci większą swobodę w łączeniu 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 np. wygenerujesz raporty podsumowujące, aby określić, ile konwersji doprowadziło do określonej wartości łącznych wydatków, może to pomóc Twojemu zespołowi zdecydować, na co powinna być nastawiona następna kampania reklamowa, aby uzyskać wyższe łączne wydatki.

Gdy już zdecydujesz, co chcesz mierzyć, możesz skonfigurować interfejs Attribution Reporting API po stronie klienta.

Komunikacja między witryną a przeglądarką

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

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 reklamami i przypisać konwersje do odpowiedniej reklamy. Raporty (zarówno na poziomie zdarzenia, jak i zbiorcze) będą generowane w ten sposób:

W witrynie wydawcy element reklamy (tag <a> lub <img>) jest skonfigurowany za pomocą specjalnego atrybutu attributionsrc. Jego wartość to 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 powoduje zarejestrowanie źródła podczas wyświetlania:
```
<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, który używa właściwości window.open(). Pamiętaj, że adres URL jest zakodowany, aby uniknąć problemów z znakami specjalnymi.
```
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 attributionsrc, czyli zwykle do punktu końcowego reklamodawcy lub dostawcy technologii reklamowych.
Po otrzymaniu tej prośby reklamodawca lub dostawca technologii reklamowych może zdecydować, że wskaże przeglądarce zdarzenia źródłowe dotyczące interakcji z reklamą, aby można było później 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 źródłowym zdarzeniu (kliknięciu lub wyświetleniu reklamy). Jeśli w przypadku tej reklamy nastąpi konwersja, te dane niestandardowe zostaną uwzględnione w raporcie atrybucji.
Później użytkownik odwiedza witrynę reklamodawcy.
Na każdej odpowiedniej stronie witryny reklamodawcy, np. na stronie potwierdzenia zakupu lub na stronie produktu, piksel konwersji (element <img>) lub wywołanie kodu JavaScript wysyła żądanie do https://adtech.example/conversion?param1=...&param2=....
Usługa pod tym adresem URL (zwykle reklamodawca lub dostawca technologii reklamowych) odbiera żądanie. Uznaje, że jest to konwersja, więc musi zlecić przeglądarce zarejestrowanie konwersji, czyli uruchomienie atrybucji. W tym celu reklamodawca lub dostawca technologii reklamowych umieszcza w odpowiedzi na żądanie pliku pzcelowego specjalny nagłówek HTTP zawierający dane niestandardowe o konswerwacji.
Przeglądarka na lokalnym urządzeniu użytkownika odbiera tę odpowiedź i dopasowuje dane o konwersji do pierwotnego zdarzenia źródłowego (kliknięcia lub wyświetlenia reklamy).
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 źródłowego zdarzenia w kroku 3.
2. niestandardowego zbioru danych konwersji na etapie 6.
Diagrama przedstawia elementy reguł raportowania atrybucji, które prowadzą do raportów na poziomie zdarzenia i zbiorcze.
Później przeglądarka wysyła raporty do punktu końcowego zdefiniowanego w sekcji attributionsrc. Dzieje się to z pewnym opóźnieniem i dodaniem szumu. Raporty podlegające agregacji są szyfrowane, a raporty na poziomie zdarzenia nie są szyfrowane.

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 podsumowaniach można uwzględniać różne typy konwersji i metadane.

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

Dopasowywanie źródeł do wyzwalaczy

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

Gdy np. przeglądarka otrzyma od adtech.example w witrynie shoes.example/shoes123 wyzwalacz atrybucji, poszuka w pamięci lokalnej źródła, które pasuje do adtech.example i shoes.example.

Filtry (lub reguły niestandardowe) mogą być ustawiane w celu określenia, kiedy reguła ma być dopasowywana do określonego źródła. Możesz np. ustawić filtr, aby zliczać tylko konwersje w ramach określonej kategorii produktów i ignorować wszystkie pozostałe kategorie. Filtry i modele priorytetów umożliwiają bardziej zaawansowane raportowanie atrybucji.

Jeśli w pamięci lokalnej znaleziono wiele źródeł atrybucji, przeglądarka wybierze to, które zostało zapisane jako ostatnie. W niektórych przypadkach, gdy źródłom atrybucji przypisano priorytet, przeglądarka wybierze źródło o najwyższym priorytecie.

Zbieranie danych

Razem z wyzwalaczemi atrybucji dopasowanymi do odpowiedniego źródła przeglądarka wysyła raport do punktu końcowego raportowania na serwerze należącym do dostawcy technologii reklamowej (czasami nazywanym punktem końcowym zbierania lub usługą zbierania). Mogą to być raporty na poziomie zdarzenia lub zbiorcze.

Raporty podlegające 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 podlegające agregacji są wysyłane z losowym opóźnieniem w ciągu 1 godziny, a zdarzenia muszą mieścić się w budżecie udziału. Te opcje chronią prywatność i zapobiegają wykorzystywaniu działań poszczególnych użytkowników.

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

Generowanie raportu podsumowującego

Do generowania raportów podsumowujących używasz usługi do agregacji (obsługiwanej przez dostawcę technologii reklamowych) do przetwarzania raportów podlegających agregacji. Usługa do agregacji dodaje szum, aby chronić prywatność użytkowników, i zwraca końcowy raport podsumowujący.

Raporty z możliwością agregacji są zbierane, grupowane i wysyłane do środowiska dostawcy technologii reklamowej. — Ten diagram przedstawia asynchroniczny przepływ danych z punktu końcowego do zbierania danych, raportów zbiorczych i przetwarzania w usługi do agregacji należącej do firmy zajmującej się technologią reklamową.

Po zebraniu raportów podlegających agregacji są one przetwarzane przez usługę do agregacji. Koordynator udostępnia klucze odszyfrowywania tylko w przypadku poświadczonych wersji usługi do agregacji. Usługa do agregacji odszyfrowuje dane, agreguje je i dodaje szum, a potem zwraca wyniki w raporcie podsumowującym.

Raporty zbiorcze możliwe do zgrupowania

Zanim przetworzone zostaną raporty podlegające agregacji, muszą one zostać zgrupowane. Partie zawierają strategicznie pogrupowane raporty podlegające agregacji. Strategia będzie najprawdopodobniej odzwierciedlać określony przedział czasu (np. codziennie lub co tydzień). Ten proces może odbywać się na tym samym serwerze, który działa jako punkt końcowy raportowania.

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

Większe przedziały czasowe dają mniej zakłóceń w wynikach. — Porównaj czas oczekiwania 1 dzień i 1 dzień. Po 1 godzinie uzyskasz mniejszą wartość podsumowania, która prawdopodobnie będzie bardziej narażona na szum. W ciągu jednego dnia uzyskasz większą wartość zbiorczą, która będzie prawdopodobnie mniej wiarygodna.

Okresy zbiorczego przetwarzania danych mogą się zmieniać w dowolnym momencie, aby uwzględniać konkretne zdarzenia, w przypadku których spodziewasz się większej liczby transakcji, np. w ramach wyprzedaży rocznej. Okres grupowania 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 mogą być odczytywane tylko przez usługę do agregacji, która działa w zaufanym środowisku wykonawczym (TEE).

Usługa do agregacji wysyła żądanie kluczy odszyfrowywania do koordynatora, aby odszyfrować i zagnać dane. Po odszyfrowaniu i zsumowaniu wyniki są zaciemniane, aby zachować prywatność, i zwracane jako raport podsumowania.

Użytkownicy mogą generować raporty w postaci zwykłego tekstu, które można agregować, aby testować usługę do agregacji lokalnie. Możesz też przetestować szyfrowane raporty w AWS za pomocą Nitro Enclaves.

Co dalej?

Chcemy z Tobą porozmawiać, aby stworzyć 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.

Eksperymentowanie z interfejsem API

Możesz przeprowadzać eksperymenty i uczestniczyć w dyskusji na temat interfejsu Attribution Reporting API.