Attribution Reporting: pełny przegląd systemu

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

Attribution Reporting API pozwala technikom reklamowym i reklamodawcom mierzyć, kiedy kliknięcie lub wyświetlenie reklamy prowadzi do konwersji, np. do zakupu. Ten interfejs API korzysta z połączenie integracji po stronie klienta i po stronie serwera, w zależności od do potrzeb biznesowych.

Zanim przejdziesz dalej, przeczytaj Omówienie raportowania atrybucji. Pomoże Ci to poznać przeznaczenie interfejsu API i przepływ różnych raportów wyjściowych (raport na poziomie zdarzenia i raporty podsumowujące). Jeśli natrafisz na nieznane terminy, przeczytaj Glosariusz Piaskownicy prywatności.

Dla kogo jest ten artykuł?

Przeczytaj ten artykuł, jeśli:

  • To Ty zajmujesz się decyzją techniczną w branży technologii reklamowej lub reklamodawcy. Możesz pracować w operacjach operacyjnych, w zakresie DevOps, badania danych, IT, marketingu lub w innej pracy, podejmować techniczne decyzje wdrożeniowe. Zastanawiasz się, jak interfejsy API działają w przypadku pomiarów z zachowaniem ochrony prywatności.
  • Jesteś specjalistą ds. technicznych (np. programistą, operatorem systemów, architekta systemów lub badaczy danych), który będzie konfigurował eksperymenty ten interfejs API i środowisko usługi agregacji.

W tym artykule znajdziesz ogólne, wyczerpujące wyjaśnienie, współdziałają z Attribution Reporting API. Jeśli jesteś specjalistą ds. technicznych ze specjalistą, eksperymentuj z tym interfejsem API lokalnie.

Omówienie

Interfejs Attribution Reporting API składa się z wielu usług, które wymagają określonych konfiguracji, konfiguracji po stronie klienta i wdrożeniach serwerów. Aby ustalić, co najpierw:

  • podejmować decyzje projektowe; Określ, jakie informacje chcesz zbierać, określ, jakich konwersji oczekujesz w ramach danej kampanii, oraz określ typ raportu, który chcesz zbierać. Wyniki można uzyskać, korzystając z jednego lub obu z 2 typów raportów: raportów na poziomie zdarzenia i raportów podsumowujących.

Zawsze na potrzeby raportowania dostępne są dwa (a czasem trzy) elementy:

  • Komunikacja między witryną a przeglądarką. W oparte na plikach cookie, informacje o konwersjach i interakcjach z reklamami są powiązane z identyfikatorem, który umożliwia Tobie lub usłudze analitycznej dołączenie takich zdarzeń. Za pomocą tego interfejsu API przeglądarka łączy konwersje z kliknięć/obejrzeń reklamy, zgodnie z Twoimi instrukcjami, przed ich wyświetleniem na analizy. W związku z tym kod renderowania reklamy i śledzenie konwersji muszą:
    • Poinformuj przeglądarkę, które konwersje powinny zostać przypisane do poszczególnych reklam liczby kliknięć lub wyświetleń.
    • Określ wszelkie inne dane, które chcesz uwzględnić w raportach końcowych.
  • Zbieranie danych. Potrzebujesz punktu końcowego kolektora, aby: raportów, generowanych na stronie przeglądarki. Dane wyjściowe przeglądarek mogą być dostępne dwa raporty: raporty na poziomie zdarzenia oraz raporty raportów (które są zaszyfrowane i służą do generowania raportów podsumowujących).

Jeśli masz zgromadzone raporty zbiorcze, potrzebujesz trzeciego komponentu:

Decyzje projektowe

Najważniejszą zasadą w raportach atrybucji są wczesne decyzje projektowe. Ty decydujesz jakie dane zbierać w jakich kategoriach i jak często je przetwarzać i skalowalnych danych. Raporty wyjściowe dostarczają statystyk o Twoich kampaniach lub firmie.

Raport wyjściowy może mieć taką postać:

  • Raporty na poziomie zdarzenia łączą konkretne 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 po stronie konwersji są bardzo ograniczone, a dane są zaszumione (czyli w niewielkim odsetku przypadków zamiast rzeczywistych raportów wysyłane są 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 elastyczność łączenia 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 używanych do podejmować decyzje. Jeśli na przykład generujesz raporty podsumowujące, by sprawdzić, konwersji przełożyło się na pewną łączną wartość wydatków, co może ułatwić Twojemu zespołowi na jaki cel powinna ustawić następna kampania reklamowa, by wygenerować wyższe łączne wydatki.

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

Komunikacja między witrynami a przeglądarkami

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

Przepływ zdarzeń atrybucji

Wyobraź sobie witrynę wydawcy, która wyświetla reklamy. Każdy reklamodawca lub dostawca technologii reklamowych chce poznać interakcje z jego reklamami i przypisać konwersje do odpowiednich reklam. Raporty (zarówno na poziomie zdarzenia, jak i możliwe do agregacji) będą generowane w taki 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órego kliknięcie spowoduje zarejestrowanie źródła:

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

    Oto przykład obrazu, który 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 JavaScriptu z użyciem window.open(). Pamiętaj, że adres URL jest zakodowany, by 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});
    
  1. Gdy użytkownik kliknie lub zobaczy reklamę, przeglądarka wysyła żądanie GET do usługi attributionsrc. Zazwyczaj jest to punkt końcowy reklamodawcy lub dostawcy technologii reklamowych.
  2. Po otrzymaniu tej prośby reklamodawca lub dostawca technologii reklamowych decyduje się na polecenie przeglądarki rejestrowania zdarzeń źródłowych związanych z interakcjami z reklamą, aby później można było przypisywać do niej konwersje. W tym celu reklamodawca lub dostawca technologii reklamowych dodaje w odpowiedzi specjalny nagłówek HTTP. Dołącza on te dane niestandardowe 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, dane niestandardowe pojawią się w raporcie atrybucji.

    Wyświetl lub kliknij reklamę.

  3. Następnie 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 JavaScriptu wysyła żądanie do https://adtech.example/conversion?param1=...&param2=....

  5. Usługa pod tym adresem URL – zwykle reklamodawca lub dostawca technologii reklamowych – otrzyma żądanie. Postanawia to przypisać do kategorii konwersję, więc musi nakazać przeglądarce zarejestrowanie konwersji, czyli uruchomienie atrybucji. W tym celu reklamodawca lub dostawca technologii reklamowych w odpowiedzi na żądanie pikselowe dodaje specjalny nagłówek HTTP zawierający niestandardowe dane o konwersji.

  6. Przeglądarka na lokalnym urządzeniu użytkownika otrzyma tę odpowiedź i dopasuje dane o konwersjach do pierwotnego zdarzenia źródłowego (kliknięcie lub wyświetlenie reklamy). Więcej informacji znajdziesz w artykule Dopasowywanie źródeł do reguł.

  7. Przeglądarka planuje wysłanie raportu na adres attributionsrc. Ten raport zawiera:

    1. Dane niestandardowej konfiguracji atrybucji, które dostawca technologii reklamowych lub reklamodawca załączył do zdarzenia źródłowego w kroku 3.
    2. Niestandardowy zbiór danych konwersji w kroku 6.
    Konwersja.
  8. Później przeglądarka wysyła raporty do punktu końcowego zdefiniowanego w zasadzie attributionsrc, z pewnym opóźnieniem i szumem. Raporty agregowane są szyfrowane, w przeciwieństwie do raportów na poziomie zdarzenia.

Reguły atrybucji (witryna reklamodawcy)

Reguła atrybucji to zdarzenie, które informuje przeglądarkę, że ma zarejestrować konwersje.

Zalecamy rejestrowanie konwersji, które są najważniejsze dla takich jak zakupy. Można określić wiele typów konwersji i metadanych są rejestrowane w raportach podsumowujących.

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

Dopasuj źródła do reguł

Gdy przeglądarka otrzymuje odpowiedź aktywatora atrybucji, uzyskuje dostęp pamięci lokalnej w celu znalezienia źródła, które pasuje zarówno do origin i adresu URL tej strony eTLD+1.

Jeśli na przykład przeglądarka otrzyma regułę atrybucji z adtech.example w witrynie shoes.example/shoes123, przeglądarka szuka źródła w: pamięci lokalnej zgodnej z kryteriami adtech.example i shoes.example.

Można ustawić filtry (lub reguły niestandardowe), aby określić, kiedy reguła jest dopasowywana do danej reguły. do konkretnego źródła. Ustaw np. filtr zliczający tylko konwersje określoną kategorię produktów i zignoruj wszystkie pozostałe. Filtry modele określania priorytetów pozwalają na bardziej zaawansowane raportowanie atrybucji.

Jeśli w pamięci lokalnej znajduje się wiele źródeł atrybucji, przeglądarka wybiera zapisany ostatnio. W niektórych przypadkach, gdy źródła atrybucji ma przypisany priorytet, przeglądarka wybierze źródło o najwyższym priorytecie .

Zbieranie danych

Reguła atrybucji dopasowana do odpowiedniego źródła jest wysyłana jako przesłanie przez przeglądarkę zgłoszenia do punktu końcowego raportowania na serwerze należącym do technologii reklamowej. (czasem nazywany punktem końcowym lub usługą odbioru). Te mogą być raportami na poziomie zdarzenia lub agregowanymi.

Raporty zbiorcze służą do generowania raportów podsumowujących. Raport agregowany to kombinacja danych zebranych z reklamy (w witrynie wydawcy) i danych o konwersjach (z witryny reklamodawcy), która jest generowana i szyfrowana przez przeglądarkę na urządzeniu użytkownika, zanim zostaną one zebrane przez technologię reklamową.

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

Jeśli interesują Cię tylko raporty na poziomie zdarzenia, to ostatni fragment i infrastrukturze, której potrzebujesz. Jeśli jednak chcesz generować raporty podsumowujące, musisz przetwarzać raporty agregowane, korzystając z dodatkowej usługi.

Generowanie raportu podsumowującego

Do generowania raportów podsumowujących służy funkcja Usługa agregacji (obsługiwane przez technologię reklamową) na potrzeby przetwarzania raportów zbiorczych. Agregacja Usługa dodaje szum, aby chronić prywatność użytkownika, i zwraca ostateczny raport podsumowujący.

Raporty agregowane są zbierane, grupowane i wysyłane do środowiska technologii reklamowych.
Ten diagram przedstawia przepływ asynchroniczny danych z punktu końcowego zbierania danych, grupowania raportów w usłudze agregacji należącej do technologii reklamowych.

Po grupowaniu zebranych raportów agregowanych wsad jest przetwarzany przez usługę agregacji. O koordynator przekazuje klucze odszyfrowywania tylko potwierdzonym wersjom agregacji. posprzedażna. Następnie usługa agregacji odszyfrowuje dane, agreguje je, i dodawanie szumu przed zwróceniem wyników jako raportu podsumowującego.

Zbiorcze raporty agregowane

Przed przetworzeniem raportów agregowanych należy je zgrupować. Grupa składa się ze strategicznie pogrupowanych raportów agregowanych. Twoja strategia będzie najkorzystniejsza prawdopodobnie dotyczą konkretnego okresu (np. dnia lub tygodnia). Ten 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 pozwalają uzyskać mniej szumów.
Porównaj oczekiwania 1 dzień i 1 tydzień. W ciągu godziny zobaczysz mniejszą wartość podsumowania i prawdopodobnie bardziej zaszumione wyniki. 1 dnia uzyskasz większą wartość podsumowania, więc prawdopodobnie będzie ona mniejsza.

Okresy wsadu mogą się zmienić w dowolnym momencie, aby zapewnić rejestrowanie konkretnych zdarzeń w których spodziewasz się większej liczby transakcji – np. w przypadku wyprzedaży rocznej. Okres grupowania można zmienić bez konieczności zmiany źródeł ani reguł atrybucji.

Usługa do agregacji

Usługa agregacji odpowiada za przetwarzanie agregowanych raportów na potrzeby wygenerować raport podsumowujący. Raporty agregowane są szyfrowane i można je edytować tylko odczytywane przez usługę agregacji, która działa w zaufanym środowisku wykonawczym (TEE).

Usługa agregacji prosi o klucze odszyfrowania od koordynatora. aby je odszyfrować i agregować. Po odszyfrowaniu i zagregowaniu wyniki są szumione, aby chronić prywatność, i zwracane jako raport podsumowujący.

Specjaliści mogą generować agregowane raporty nieszyfrowane, aby lokalnie przetestujesz usługę agregacji. Możesz też przeprowadzić testy za pomocą zaszyfrowanych raportów w AWS z enklawami Nitro.

Co dalej?

Chcemy z Panem/Panią prowadzić rozmowy w celu opracowania interfejsu API, sprawdza się w przypadku każdego.

Omów interfejs API

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

Eksperymentuj z interfejsem API

Możesz eksperymentować i brać udział w programie w rozmowie o Attribution Reporting API.