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.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/attribution-sources-a-pu-b04d5ed143672.png?authuser=6&hl=pl)
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 atrybutemattributionsrc
. 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ługiattributionsrc
, 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 dohttps://adtech.example/conversion?param1=...¶m2=...
.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:- Niestandardowe dane konfiguracji atrybucji, które dostawca technologii reklamowych lub reklamodawca dołączył do zdarzenia źródłowego w kroku 3.
- 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.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/aggregatable-reports-are-a0830fd543e6f.png?authuser=6&hl=pl)
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.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/larger-periods-lead-les-4d4edffb3d2d6.png?authuser=6&hl=pl)
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.