Attribution Reporting: pełny przegląd systemu

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, czy 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. Pomoże Ci to zrozumieć cel interfejsu API i przepływ danych w różnych raportach wyjściowych (raport na poziomie zdarzeniaraporty podsumowania). Jeśli natrafisz na nieznane terminy, zapoznaj się z glosariuszem Piaskownicy prywatności.

Dla kogo jest przeznaczony ten artykuł?

Ten artykuł 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. Zastanawiasz się, jak działają interfejsy API do pomiarów z zachowowaniem prywatności.
  • Jesteś praktykiem technicznym (np. deweloperem, operatorem systemu, architektem systemowym lub specjalistą ds. danych), który będzie konfigurować eksperymenty za pomocą tego interfejsu API i środowiska usługi agregacji.

Z tego artykułu dowiesz się, jak działają usługi 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:

  • Podejmować decyzje projektowe. Określ, jakie informacje chcesz zbierać, jakie konwersje chcesz mierzyć w danej kampanii i jaki typ raportu chcesz tworzyć. Ostateczne dane wyjściowe to jeden lub oba z tych typów raportów: raporty na poziomie zdarzenia i raporty z podsumowaniem.

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 złączanie 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, potrzebujesz 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 z podsumowaniem).

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

  • Generowanie raportu zbiorczego. zbiorczo raporty zbiorcze i wykorzystywać usługę agregującą do ich przetwarzania w celu wygenerowania raportu podsumowującego.

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 Twoich kampaniach lub firmie.

Raport wyjściowy może być:

  • Raporty na poziomie zdarzenia powiązane z danymi o konwersjach łączą 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 możliwość elastycznego złączania 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 wygenerować 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.
Ź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 możliwe do zsumowania) będą generowane w ten sposób:

  1. 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 rejestruje ź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});
    
  1. Gdy użytkownik kliknie reklamę lub ją wyświetli, przeglądarka wysyła żądanie GET do attributionsrc, czyli zwykle do punktu końcowego reklamodawcy lub dostawcy technologii reklamowych.
  2. Po otrzymaniu tej prośby reklamodawca lub dostawca technologii reklamowych może zdecydować, aby przeglądarka zarejestrowała zdarzenia źródłowe związane z interakcjami z reklamą, dzięki czemu konwersje będą mogły zostać przypisane do tej reklamy. 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 danej reklamy dojdzie do konwersji, te dane niestandardowe zostaną uwzględnione w raporcie atrybucji.

    Wyświetl lub kliknij reklamę.

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

  4. Na każdej odpowiedniej stronie w witrynie 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=....

  5. 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 śledzącego specjalny nagłówek HTTP z danymi niestandardowymi o konswerwacji.

  6. 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). Więcej informacji znajdziesz w artykule Dopasowywanie źródeł do reguł.

  7. 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. niestandardowe dane konwersji skonfigurowane w kroku 6.
    konwersji,
  8. 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 zbiorczych 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 zarówno do adtech.example, jak i do 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 dostawcy technologii reklamowej (czasem nazywanym punktem końcowym zbierania danych lub usługą zbierania danych). Mogą to być raporty na poziomie zdarzenia lub zbiorcze.

Możliwość agregowania raportów służy 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 zbiorcze, musisz przetworzyć raporty podlegające agregacji za pomocą dodatkowej usługi.

Generowanie raportu zbiorczego

Aby wygenerować raporty podsumowujące, użyjesz usługi agregującej (obsługiwanej przez dostawcę technologii reklamowych) do przetwarzania raportów podlegających agregacji. Usługa AggregationService 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 zbierania, raportów zbiorczych i przetwarzania w usługi agregacji należącej do firmy zajmującej się technologiami reklamowymi.

Po zebraniu raportów podlegających agregacji są one przetwarzane przez usługę agregującą. Koordynator udostępnia klucze odszyfrowywania tylko w przypadku zweryfikowanych wersji usługi agregacji. Usługa agregująca odszyfrowuje dane, agreguje je i dodaje do nich szum, a następnie zwraca wyniki w postaci raportu podsumowującego.

Raporty zbiorcze możliwe do zgrupowania

Zanim przetworzone zostaną raporty, które można zsumować, 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 zróżnicowana.

Okresy zbiorczego przetwarzania danych mogą się zmieniać w dowolnym momencie, aby uwzględniać konkretne zdarzenia, w których przypadku spodziewasz się większej liczby transakcji, np. w przypadku wyprzedaży rocznej. Okres grupowania można zmienić bez konieczności zmiany źródeł atrybucji ani wyzwalaczy.

Usługa do agregacji

Usługa agregująca odpowiada za przetwarzanie raportów zbiorczych w celu wygenerowania raportu podsumowującego. Raporty z możliwością agregacji są szyfrowane i mogą być odczytywane tylko przez usługę agregacji, która działa w zaufanym środowisku wykonawczym (TEE).

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

Użytkownicy mogą generować raporty w czystym tekście, które można agregować, aby testować usługę agregującą 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 przeprowadzić eksperyment i uczestniczyć w rozmowie na temat interfejsu Attribution Reporting API.