Omówienie raportu Atrybucja na urządzeniach mobilnych

Ostatnie aktualizacje

• Zaktualizowaliśmy listę nadchodzących zmian i znanych problemów.

• Wprowadzamy ponowne wysyłanie zapytań, nową funkcję kierowania, która zostanie udostępniona w II połowie 2025 roku. Ponowne wysyłanie zapytań umożliwia dostawcom technologii reklamowych wielokrotne przetwarzanie raportów z usługi agregacji, co pozwala na elastyczną analizę pod kątem różnych potrzeb związanych z pomiarami. Dołącz do dyskusji na GitHubie, aby dowiedzieć się więcej i przesłać opinię.

Przegląd

Obecnie rozwiązania do atrybucji i pomiarów na urządzeniach mobilnych często wykorzystują pochodzące z różnych źródeł identyfikatory, np. identyfikator wyświetlania reklam. Interfejs Attribution Reporting API ma zapewniać lepszą ochronę prywatności użytkowników dzięki wyeliminowaniu zależności od identyfikatorów użytkowników pochodzących od firm zewnętrznych oraz obsługiwać najważniejsze przypadki pomiaru konwersji i przypisywania udziału w konwersji w aplikacjach i internecie.

Ten interfejs API ma te mechanizmy strukturalne, które stanowią ramy dla zwiększania ochrony prywatności. W dalszych sekcjach tej strony opisujemy je bardziej szczegółowo:

• Ogranicza liczbę bitów dostępnych w raportach na poziomie zdarzenia.

• Umożliwia uzyskiwanie danych o konwersjach o większej dokładności tylko w raportach zbiorczych.

• Wprowadza limity liczby dostępnych wywołań (konwersji) i liczby dostawców technologii reklamowych, którzy mogą być powiązani z jednym źródłem atrybucji

• obejmuje różne techniki dodawania szumu,

Powyższe mechanizmy ograniczają możliwość łączenia tożsamości użytkownika w 2 różnych aplikacjach lub domenach.

Interfejs Attribution Reporting API obsługuje te przypadki użycia:

• Raportowanie konwersji: pomaga reklamodawcom mierzyć skuteczność kampanii, wyświetlając liczbę konwersji (wywołań) i wartości konwersji (wywołań) w różnych wymiarach, np. według kampanii, grupy reklam i kreacji.
• Optymalizacja: udostępniaj raporty na poziomie zdarzenia, które pomagają optymalizować wydatki na reklamy, dostarczając dane atrybucji dotyczące poszczególnych wyświetleń, które można wykorzystać do trenowania modeli ML.
• Wykrywanie nieprawidłowej aktywności: udostępnianie raportów, które można wykorzystać do wykrywania i analizowania nieprawidłowego ruchu i oszustw reklamowych.

Ogólnie interfejs Attribution Reporting API działa w ten sposób (szczegółowe informacje znajdziesz w dalszej części tego dokumentu):

1. Dostawca technologii reklamowych przechodzi proces rejestracji, aby korzystać z interfejsu Attribution Reporting API.
2. Technologia reklamowa rejestruje źródła atrybucji – kliknięcia lub wyświetlenia reklam – za pomocą interfejsu Attribution Reporting API.
3. Technologia reklamowa rejestruje wyzwalacze, czyli konwersje użytkowników w aplikacji lub witrynie reklamodawcy, za pomocą interfejsu Attribution Reporting API.
4. Interfejs Attribution Reporting API dopasowuje reguły do źródeł atrybucji – atrybucji konwersji – i wysyła co najmniej 1 regułę poza urządzenie za pomocą raportów na poziomie zdarzenia i z możliwością agregacji do dostawców technologii reklamowych.

Uzyskiwanie dostępu do interfejsów Attribution Reporting API

Aby uzyskać dostęp do interfejsów Attribution Reporting API, platformy technologii reklamowych muszą się zarejestrować. Więcej informacji znajdziesz w artykule Rejestracja konta Piaskownicy prywatności.

Rejestrowanie źródła atrybucji (kliknięcia lub wyświetlenia)

W interfejsie Attribution Reporting API kliknięcia i wyświetlenia reklam są nazywane źródłami atrybucji. Aby zarejestrować kliknięcie lub wyświetlenie reklamy, wywołaj funkcję registerSource(). Ten interfejs API oczekuje tych parametrów:

• Identyfikator URI źródła atrybucji: platforma wysyła żądanie do tego identyfikatora URI, aby pobrać metadane powiązane ze źródłem atrybucji.
• Zdarzenie wejściowe: obiekt InputEvent (w przypadku zdarzenia kliknięcia) lub null (w przypadku zdarzenia wyświetlenia).

Gdy interfejs API wyśle żądanie do identyfikatora URI źródła atrybucji, technologia reklamowa powinna odpowiedzieć metadanymi źródła atrybucji w nowym nagłówku HTTP Attribution-Reporting-Register-Source, który zawiera te pola:

• Identyfikator zdarzenia źródłowego: ta wartość reprezentuje dane na poziomie zdarzenia powiązane z tym źródłem atrybucji (kliknięciem lub wyświetleniem reklamy). Musi to być 64-bitowa liczba całkowita bez znaku sformatowana jako ciąg znaków.
• Miejsce docelowe: źródło, którego nazwa eTLD+1 lub nazwa pakietu aplikacji, w której występuje zdarzenie wywołujące.
• Czas wygaśnięcia (opcjonalnie): czas wygaśnięcia w sekundach, po którym źródło powinno zostać usunięte z urządzenia. Domyślna wartość to 30 dni, a minimalna i maksymalna to odpowiednio 1 dzień i 30 dni. Jest ona zaokrąglana do najbliższego dnia. Może być sformatowany jako 64-bitowa liczba całkowita bez znaku lub ciąg znaków.
• Okres raportowania zdarzeń (opcjonalnie): czas w sekundach po zarejestrowaniu źródła, w którym można tworzyć raporty o zdarzeniach dotyczące tego źródła. Jeśli okno raportu o zdarzeniu minęło, ale okres ważności jeszcze nie, wyzwalacz nadal może być dopasowany do źródła, ale raport o zdarzeniu nie jest wysyłany w przypadku tego wyzwalacza. Nie może być większa niż data wygaśnięcia. Może być sformatowany jako 64-bitowa liczba całkowita bez znaku lub ciąg znaków.
• Okres raportowania z możliwością agregacji (opcjonalnie): czas w sekundach po zarejestrowaniu źródła, w którym można tworzyć raporty z możliwością agregacji dla tego źródła. Nie może być większa niż data wygaśnięcia. Może być sformatowany jako 64-bitowa liczba całkowita bez znaku lub ciąg znaków.
• Priorytet źródła (opcjonalnie): służy do wybierania źródła atrybucji, z którym ma być powiązany dany aktywator, w przypadku gdy z aktywatorem może być powiązanych kilka źródeł atrybucji. Musi to być 64-bitowa liczba całkowita ze znakiem sformatowana jako ciąg znaków.
  
  Gdy zostanie odebrany sygnał, interfejs API znajdzie pasujące źródło atrybucji o najwyższej wartości priorytetu źródła i wygeneruje raport. Każda platforma technologii reklamowych może określić własną strategię ustalania priorytetów. Więcej informacji o tym, jak priorytet wpływa na atrybucję, znajdziesz w sekcji Przykład ustalania priorytetów.
  
  Wyższe wartości oznaczają wyższe priorytety.
• Okresy atrybucji instalacji i zdarzeń po instalacji (opcjonalne): służą do określania atrybucji zdarzeń po instalacji, które opisujemy w dalszej części tej strony.
• Filtrowanie danych (opcjonalne): służy do selektywnego filtrowania niektórych wywołań, co pozwala je ignorować. Więcej informacji znajdziesz w sekcji Filtry wyzwalaczy na tej stronie.
• Klucze agregacji (opcjonalnie): określ podział na segmenty, który ma być używany w raportach z możliwością agregacji.

Opcjonalnie odpowiedź metadanych źródła atrybucji może zawierać dodatkowe dane w nagłówku Przekierowania raportowania atrybucji. Dane zawierają adresy URL przekierowań, które umożliwiają wielu dostawcom technologii reklamowych rejestrowanie żądania.

Przewodnik dla deweloperów zawiera przykłady pokazujące, jak akceptować rejestrację źródła.

Poniższe kroki przedstawiają przykładowy przepływ pracy:

1. Pakiet SDK technologii reklamowej wywołuje interfejs API, aby zainicjować rejestrację źródła atrybucji, podając identyfikator URI, który interfejs API ma wywołać:

   registerSource(
       Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
       myClickEvent);
   

2. Interfejs API wysyła żądanie do https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA, używając jednego z tych nagłówków:

   <!-- For click events -->
   Attribution-Reporting-Source-Info: navigation
   
   <!-- For view events -->
   Attribution-Reporting-Source-Info: event
   

3. Serwer HTTPS tej platformy reklamowej odpowiada nagłówkami zawierającymi te informacje:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "234",
       "expiry": "60000",
       "priority": "5"
   }
   Attribution-Reporting-Redirect:
   https://adtechpartner1.example?their_ad_click_id=567
   Attribution-Reporting-Redirect:
   https://adtechpartner2.example?their_ad_click_id=890
   

4. Interfejs API wysyła żądanie do każdego adresu URL określonego w parametrze Attribution-Reporting-Redirect. W tym przykładzie określono 2 adresy URL partnerów technologicznych, więc interfejs API wysyła 1 żądanie do https://adtechpartner1.example?their_ad_click_id=567 i 1 żądanie do https://adtechpartner2.example?their_ad_click_id=890.

5. Serwer HTTPS tej platformy reklamowej odpowiada nagłówkami zawierającymi te informacje:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "789",
       "expiry": "120000",
       "priority": "2"
   }
   

Na podstawie żądań pokazanych w poprzednich krokach zarejestrowane są 3 źródła atrybucji nawigacji (kliknięć).

Rejestrowanie źródła atrybucji z komponentu WebView

WebView obsługuje przypadek użycia, w którym aplikacja renderuje reklamę w komponencie WebView. Odbywa się to przez bezpośrednie wywołanie registerSource() przez WebView. To wywołanie przypisuje źródło atrybucji do aplikacji zamiast do źródła najwyższego poziomu. Rejestrowanie źródeł z osadzonych treści internetowych w kontekście przeglądarki jest również obsługiwane. Zarówno wywołujący interfejs API, jak i aplikacje muszą dostosować ustawienia, aby to zrobić. Instrukcje dla wywołujących interfejs API znajdziesz w artykule Rejestrowanie źródła i wyzwalacza atrybucji w komponencie WebView, a instrukcje dla aplikacji – w artykule Rejestrowanie źródła i wyzwalacza atrybucji w komponencie WebView.

Technologie reklamowe używają wspólnego kodu w przypadku internetu i widoku WebView, dlatego widok WebView postępuje zgodnie z przekierowaniami HTTP 302 i przekazuje prawidłowe rejestracje na platformę. W tym scenariuszu nie planujemy obsługi nagłówka Attribution-Reporting-Redirect, ale jeśli masz przypadek użycia, którego to dotyczy, skontaktuj się z nami.

Rejestrowanie aktywatora (konwersji)

Platformy technologii reklamowych mogą rejestrować wyzwalacze, czyli konwersje takie jak instalacje lub zdarzenia po instalacji, za pomocą metody registerTrigger().

Metoda registerTrigger() oczekuje parametru Identyfikator URI czynnika uruchamiającego. Interfejs API wysyła żądanie do tego identyfikatora URI, aby pobrać metadane powiązane z wyzwalaczem.

Interfejs API śledzi przekierowania. Odpowiedź serwera technologii reklamowej powinna zawierać nagłówek HTTP o nazwie Attribution-Reporting-Register-Trigger, który zawiera informacje o co najmniej jednym zarejestrowanym wyzwalaczu. Zawartość nagłówka powinna być zakodowana w formacie JSON i zawierać te pola:

• Dane reguły: dane identyfikujące zdarzenie reguły (3 bity w przypadku kliknięć, 1 bit w przypadku wyświetleń). Musi to być 64-bitowa liczba całkowita ze znakiem sformatowana jako ciąg znaków.

• Priorytet reguły (opcjonalnie): określa priorytet tej reguły w porównaniu z innymi regułami dla tego samego źródła atrybucji. Musi to być 64-bitowa liczba całkowita ze znakiem sformatowana jako ciąg znaków. Więcej informacji o tym, jak priorytet wpływa na raportowanie, znajdziesz w sekcji Priorytetyzacja.

• Klucz usuwania duplikatów (opcjonalny): służy do identyfikowania przypadków, w których ta sama platforma technologii reklamowych rejestruje ten sam wyzwalacz wiele razy w przypadku tego samego źródła atrybucji. Musi to być 64-bitowa liczba całkowita ze znakiem sformatowana jako ciąg znaków.

• Klucze agregacji (opcjonalne): lista słowników, które określają klucze agregacji i które raporty podlegające agregacji powinny mieć zagregowaną wartość.

• Wartości agregacji (opcjonalne): lista kwot wartości, które składają się na każdy klucz.

• Filtry (opcjonalne): służą do selektywnego filtrowania wywołań lub danych wywołań. Więcej informacji znajdziesz w sekcji Filtry wyzwalaczy na tej stronie.

Opcjonalnie odpowiedź serwera technologii reklamowej może zawierać dodatkowe dane w nagłówku Attribution Reporting Redirects. Dane zawierają adresy URL przekierowania, które umożliwiają rejestrowanie żądania przez wiele technologii reklamowych.

Wiele platform reklamowych może rejestrować to samo zdarzenie wywołujące za pomocą przekierowań w polu Attribution-Reporting-Redirect lub wielu wywołań metody registerTrigger(). Aby uniknąć uwzględniania w raportach zduplikowanych aktywatorów w sytuacji, gdy ta sama platforma reklamowa dostarcza wiele odpowiedzi na to samo zdarzenie aktywujące, zalecamy używanie pola klucz usuwania duplikatów. Dowiedz się więcej o tym, jak i kiedy używać klucza deduplikacji.

Przewodnik dla deweloperów zawiera przykłady pokazujące, jak akceptować rejestrację wyzwalacza.

Poniższe kroki przedstawiają przykładowy przepływ pracy:

1. Pakiet SDK technologii reklamowej wywołuje interfejs API, aby zainicjować rejestrację wyzwalacza za pomocą wstępnie zarejestrowanego URI. Więcej informacji znajdziesz w artykule Rejestracja konta w Piaskownicy prywatności.

   registerTrigger(
       Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));
   

2. Interfejs API wysyła żądanie do https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA.

3. Serwer HTTPS tej platformy reklamowej odpowiada nagłówkami zawierającymi te informacje:

   Attribution-Reporting-Register-Trigger: {
       "event_trigger_data": [{
       "trigger_data": "1122",
       // This returns 010 for click-through conversions (CTCs) and 0 for
       // view-through conversions (VTCs) in reports
       "priority": "3",
       "deduplication_key": "3344"
       }],
   }
   Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567
   

4. Interfejs API wysyła żądanie do każdego adresu URL określonego w parametrze Attribution-Reporting-Redirect. W tym przykładzie podano tylko 1 adres URL, więc interfejs API wysyła żądanie do https://adtechpartner.example?app_install=567.

5. Serwer HTTPS tej platformy reklamowej odpowiada nagłówkami zawierającymi te informacje:

   Attribution-Reporting-Register-Trigger: {
   "event_trigger_data":[{
     "trigger_data": "5566",
     "priority": "3",
     "deduplication_key": "3344"
   }]
   }
   

   Na podstawie żądań z poprzednich kroków rejestrowane są 2 reguły.

Funkcje atrybucji

W kolejnych sekcjach wyjaśniamy, jak interfejs Attribution Reporting API dopasowuje wyzwalacze konwersji do źródeł atrybucji.

Zastosowano algorytm atrybucji z priorytetem źródeł

Interfejs Attribution Reporting API używa algorytmu atrybucji z priorytetem źródła, aby dopasować zdarzenie (konwersję) do źródła atrybucji.

Parametry priorytetu umożliwiają dostosowywanie atrybucji wywołań do źródeł:

• Możesz przypisywać wyzwalacze do określonych zdarzeń reklamowych. Możesz na przykład bardziej skupić się na kliknięciach niż na wyświetleniach lub na zdarzeniach z określonych kampanii.
• Możesz skonfigurować źródło atrybucji i wywoływać zdarzenia w taki sposób, aby w przypadku osiągnięcia limitów szybkości otrzymywać raporty, które są dla Ciebie ważniejsze. Możesz na przykład chcieć mieć pewność, że w tych raportach częściej pojawiają się konwersje, za które można ustalać stawki, lub konwersje o wysokiej wartości.

Jeśli wiele dostawców technologii reklamowych zarejestruje źródło atrybucji (jak opisano dalej na tej stronie), atrybucja następuje niezależnie w przypadku każdego z nich. Każdy dostawca technologii reklamowych przypisuje zdarzenie wywołujące do źródła atrybucji o najwyższym priorytecie. Jeśli istnieje wiele źródeł atrybucji o tym samym priorytecie, interfejs API wybiera ostatnie zarejestrowane źródło atrybucji. Wszystkie inne źródła atrybucji, które nie zostały wybrane, są odrzucane i nie kwalifikują się już do atrybucji wyzwalanej w przyszłości.

Filtry reguł

Rejestracja źródła i reguły obejmuje dodatkowe funkcje opcjonalne, które umożliwiają:

• Selektywnie filtruj niektóre wyzwalacze, skutecznie je ignorując.
• Wybierz dane wyzwalające dla raportów na poziomie zdarzenia na podstawie danych źródłowych.
• Możesz wykluczyć wywołanie z raportów na poziomie zdarzenia.

Aby selektywnie filtrować wyzwalacze, dostawca technologii reklamowych może podczas rejestracji źródła i wyzwalacza określić dane filtra składające się z kluczy i wartości. Jeśli ten sam klucz jest określony zarówno w przypadku źródła, jak i wyzwalacza, wyzwalacz jest ignorowany, jeśli część wspólna jest pusta. Na przykład źródło może określić "product": ["1234"], gdzie product to klucz filtra, a 1234 to wartość. Jeśli filtr wyzwalacza jest ustawiony na "product": ["1111"], wyzwalacz jest ignorowany. Jeśli nie ma klucza filtra wyzwalacza pasującego do product, filtry są ignorowane.

Innym scenariuszem, w którym platformy technologii reklamowych mogą chcieć selektywnie filtrować wyzwalacze, jest wymuszenie krótszego okresu ważności. Podczas rejestracji wywołania dostawca technologii reklamowej może określić (w sekundach) okres ważności od momentu wystąpienia konwersji. Na przykład 7-dniowy okres ważności można zdefiniować w ten sposób: "_lookback_window": 604800 // 7d

Aby określić, czy filtr pasuje, interfejs API najpierw sprawdzi okres ważności. Jeśli jest dostępny, czas od zarejestrowania źródła musi być mniejszy lub równy czasowi trwania okresu ważności.

Platformy technologii reklamowych mogą też wybierać dane uruchamiające na podstawie danych zdarzenia źródłowego. Na przykład source_type jest generowany automatycznie przez interfejs API jako navigation lub event. Podczas rejestracji aktywatora wartość trigger_data można ustawić jako jedną wartość dla "source_type": ["navigation"] i inną wartość dla "source_type": ["event"].

Wyzwalacze są wykluczane z raportów na poziomie zdarzenia, jeśli spełniony jest któryś z tych warunków:

• Nie określono wartości trigger_data.
• Źródło i wyzwalacz określają ten sam klucz filtra, ale wartości nie pasują do siebie. Pamiętaj, że w tym przypadku wyzwalacz jest ignorowany zarówno w raportach na poziomie zdarzenia, jak i w raportach z możliwością agregacji.

Atrybucja po instalacji

W niektórych przypadkach wyzwalacze po instalacji muszą być przypisywane do tego samego źródła atrybucji, które spowodowało instalację, nawet jeśli istnieją inne kwalifikujące się źródła atrybucji, które wystąpiły później.

Interfejs API może obsługiwać ten przypadek użycia, umożliwiając dostawcom technologii reklamowych ustawienie okresu atrybucji po instalacji:

• Podczas rejestrowania źródła atrybucji określ przedział czasu atrybucji instalacji, w którym oczekiwane są instalacje (zwykle 2–7 dni, akceptowany zakres to 1–30 dni). Określ to okno czasowe w sekundach.
• Podczas rejestrowania źródła atrybucji określ okno wyłączności atrybucji po instalacji, w którym wszystkie zdarzenia wywołujące po instalacji powinny być powiązane ze źródłem atrybucji, które spowodowało instalację (zwykle 7–30 dni, akceptowany zakres to 0–30 dni). Określ to okno czasowe w sekundach.
• Interfejs Attribution Reporting API sprawdza, kiedy następuje instalacja aplikacji, i wewnętrznie przypisuje ją do źródła atrybucji o najwyższym priorytecie. Nie jest on jednak wysyłany do dostawców technologii reklamowych i nie wlicza się do limitów częstotliwości poszczególnych platform.
• Weryfikacja instalacji aplikacji jest dostępna w przypadku każdej pobranej aplikacji.
• Wszystkie przyszłe wyzwalacze, które wystąpią w okresie atrybucji po instalacji, są przypisywane do tego samego źródła atrybucji co zweryfikowana instalacja, o ile to źródło atrybucji jest kwalifikujące się.

W przyszłości możemy rozważyć rozszerzenie tej funkcji o bardziej zaawansowane modele atrybucji.

W tabeli poniżej znajdziesz przykład tego, jak dostawcy technologii reklamowych mogą korzystać z atrybucji po instalacji. Załóżmy, że wszystkie źródła i wyzwalacze atrybucji są rejestrowane przez tę samą sieć technologii reklamowych, a wszystkie priorytety są takie same.

Poniżej znajdziesz dodatkowe uwagi dotyczące atrybucji po instalacji:

• Jeśli zweryfikowana instalacja nie nastąpi w ciągu liczby dni określonej przez install_attribution_window, atrybucja po instalacji nie zostanie zastosowana.
• Zweryfikowane instalacje nie są rejestrowane przez technologie reklamowe ani wysyłane w raportach. Nie są one wliczane do limitów częstotliwości platformy reklamowej. Zweryfikowane instalacje są używane tylko do identyfikowania źródła atrybucji, któremu przypisuje się instalację.
• W przykładzie z poprzedniej tabeli reguła 1 i reguła 2 reprezentują odpowiednio pierwsze otwarcie i konwersję po instalacji. Platformy technologii reklamowej mogą jednak rejestrować dowolny typ wyzwalacza. Innymi słowy, pierwsze zdarzenie nie musi być zdarzeniem polegającym na pierwszym uruchomieniu aplikacji.
• Jeśli po wygaśnięciu post_install_exclusivity_window zarejestrowano więcej wywołań, kliknięcie 1 nadal kwalifikuje się do atrybucji, o ile nie wygasło i nie osiągnęło limitów liczby żądań.
  • Kliknięcie 1 może nadal zostać utracone lub odrzucone, jeśli zarejestrowane zostanie źródło atrybucji o wyższym priorytecie.
• Jeśli aplikacja reklamodawcy zostanie odinstalowana i ponownie zainstalowana, ponowna instalacja zostanie uznana za nową zweryfikowaną instalację.
• Jeśli kliknięcie 1 było zdarzeniem wyświetlenia, zarówno „pierwsze uruchomienie”, jak i wyzwalacze po instalacji są nadal przypisywane do tego kliknięcia. Interfejs API ogranicza atrybucję do jednego wywołania na wyświetlenie, z wyjątkiem atrybucji po instalacji, w przypadku której dozwolone są maksymalnie 2 wywołania na wyświetlenie. W przypadku atrybucji po instalacji platforma reklamowa może otrzymać 2 różne okresy raportowania (po 2 dniach lub po wygaśnięciu źródła).

Obsługiwane są wszystkie kombinacje ścieżek wyzwalania w aplikacji i w internecie.

Interfejs Attribution Reporting API umożliwia atrybucję tych ścieżek wyzwalania na jednym urządzeniu z Androidem:

• App-to-app: użytkownik widzi reklamę w aplikacji, a potem dokonuje konwersji w tej aplikacji lub w innej zainstalowanej aplikacji.
• App-to-web: użytkownik widzi reklamę w aplikacji, a potem dokonuje konwersji w przeglądarce mobilnej lub w przeglądarce w aplikacji.
• Web-to-app: użytkownik widzi reklamę w przeglądarce mobilnej lub w przeglądarce w aplikacji, a potem dokonuje konwersji w aplikacji.
• Web-to-web: użytkownik widzi reklamę w przeglądarce mobilnej lub w przeglądarce w aplikacji, a potem dokonuje konwersji w tej samej przeglądarce lub w innej przeglądarce na tym samym urządzeniu.

Umożliwiamy przeglądarkom obsługę nowych funkcji internetowych, takich jak funkcje podobne do interfejsu Attribution Reporting API w Piaskownicy prywatności na potrzeby internetu, które mogą wywoływać interfejsy API Androida, aby umożliwić atrybucję w aplikacjach i internecie.

Dowiedz się, jakie zmiany muszą wprowadzić technologie reklamowe i aplikacje, aby obsługiwać ścieżki wyzwalania w przypadku pomiarów w aplikacjach i internecie.

Nadawanie priorytetu wielu wyzwalaczom dla jednego źródła atrybucji

Jedno źródło atrybucji może prowadzić do wielu wywołań. Na przykład ścieżka zakupu może obejmować regułę „instalacja aplikacji”, co najmniej jedną regułę „dodanie do koszyka” i regułę „zakup”. Każdy wyzwalacz jest przypisywany do co najmniej 1 źródła atrybucji zgodnie z algorytmem atrybucji z priorytetem źródła, który opisujemy dalej na tej stronie.

Istnieją limity liczby wywołań, które można przypisać do jednego źródła atrybucji. Więcej informacji znajdziesz w sekcji Wyświetlanie danych pomiarowych w raportach o atrybucji poniżej.

W przypadku, gdy poza tymi limitami występuje wiele wywołań, warto wprowadzić logikę ustalania priorytetów, aby odzyskać najcenniejsze wywołania. Na przykład deweloperzy technologii reklamowych mogą chcieć priorytetowo traktować wyzwalacze „zakup” zamiast wyzwalaczy „dodaj do koszyka”.

Aby obsługiwać tę logikę, w przypadku wyzwalacza można ustawić osobne pole priorytetu. W danym oknie raportowania przed zastosowaniem limitów wybierane są wyzwalacze o najwyższym priorytecie.

Zezwalanie wielu dostawcom technologii reklamowych na rejestrowanie źródeł lub wyzwalaczy atrybucji

Raporty atrybucji otrzymuje zwykle więcej niż 1 technologia reklamowa, aby przeprowadzać deduplikację międzysieciową. Dlatego interfejs API umożliwia wielu dostawcom technologii reklamowych rejestrowanie tego samego źródła lub wyzwalacza atrybucji. Dostawca technologii reklamowych musi zarejestrować zarówno źródła atrybucji, jak i wyzwalacze, aby otrzymywać z interfejsu API wywołania zwrotne. Atrybucja jest przeprowadzana wśród źródeł atrybucji i wyzwalaczy zarejestrowanych przez dostawcę technologii reklamowych w interfejsie API.

Reklamodawcy, którzy chcą korzystać z usług firmy zewnętrznej do deduplikacji w różnych sieciach, mogą nadal to robić, stosując podobną technikę:

• Skonfigurowanie serwera wewnętrznego do rejestrowania i odbierania raportów z interfejsu API.
• Dalsze korzystanie z usług dotychczasowego partnera ds. pomiarów mobilnych.

Źródła atrybucji

Przekierowania źródła atrybucji są obsługiwane w metodzie registerSource():

1. Technologia reklamowa, która wywołuje metodę registerSource(), może w odpowiedzi podać dodatkowe pole Attribution-Reporting-Redirect, które zawiera zestaw adresów URL przekierowania technologii reklamowej partnera.
2. Następnie interfejs API wywołuje adresy URL przekierowania, aby źródło atrybucji mogło zostać zarejestrowane przez technologie reklamowe partnera.

W polu Attribution-Reporting-Redirect można podać wiele adresów URL technologii reklamowych partnerów, a partnerzy nie mogą określać własnego pola Attribution-Reporting-Redirect.

Interfejs API umożliwia też różnym technologiom reklamowym wywoływanie funkcji registerSource().

Aktywatory

W przypadku rejestracji wyzwalacza obsługiwane są podobnie: dostawcy technologii reklamowych mogą używać dodatkowego pola Attribution-Reporting-Redirect lub wywoływać metodę registerTrigger().

Jeśli reklamodawca używa wielu technologii reklamowych do rejestrowania tego samego zdarzenia wywołującego, należy użyć klucza deduplikacji. Klucz deduplikacji służy do rozróżniania powtarzających się raportów o tym samym zdarzeniu zarejestrowanym przez tę samą platformę technologii reklamowej. Na przykład firma technologiczna zajmująca się reklamami może wywołać interfejs API bezpośrednio z pakietu SDK, aby zarejestrować wyzwalacz i umieścić swój adres URL w polu przekierowania wywołania innej firmy technologicznej zajmującej się reklamami. Jeśli nie podasz klucza deduplikacji, zduplikowane wywołania mogą być zgłaszane do każdej platformy reklamowej jako niepowtarzalne.

Obsługa zduplikowanych aktywatorów

Technologia reklamowa może zarejestrować ten sam wyzwalacz w interfejsie API wiele razy. Scenariusze obejmują m.in.:

• Użytkownik wielokrotnie wykonuje to samo działanie (regułę). Na przykład użytkownik przegląda ten sam produkt wielokrotnie w tym samym oknie raportowania.
• Aplikacja reklamodawcy używa wielu pakietów SDK do pomiaru konwersji, które przekierowują do tej samej platformy reklamowej. Na przykład aplikacja reklamodawcy korzysta z 2 partnerów pomiarowych: MMP 1 i MMP 2. Obie platformy MMP przekierowują do technologii reklamowej 3. Gdy nastąpi wywołanie, obie platformy MMP rejestrują je w interfejsie Attribution Reporting API. Technologia reklamowa nr 3 otrzymuje wtedy 2 osobne przekierowania – jedno z platformy MMP nr 1 i jedno z platformy MMP nr 2 – w odpowiedzi na ten sam wyzwalacz.

W takich przypadkach istnieje kilka sposobów na pominięcie raportów na poziomie zdarzenia dotyczących zduplikowanych wywołań, aby zmniejszyć prawdopodobieństwo przekroczenia limitów szybkości stosowanych do raportów na poziomie zdarzenia. Zalecamy użycie klucza deduplikacji.

Zalecana metoda: klucz deduplikacji

Zalecana metoda polega na przekazywaniu przez aplikację reklamodawcy unikalnego klucza deduplikacji do wszystkich technologii reklamowych lub pakietów SDK, których używa do pomiaru konwersji. Gdy nastąpi konwersja, aplikacja przekazuje klucz deduplikacji do dostawców technologii reklamowych lub pakietów SDK. Te technologie reklamowe lub pakiety SDK przekazują następnie klucz deduplikacji do przekierowań za pomocą parametru w adresach URL określonych w Attribution-Reporting-Redirect.

Dostawcy technologii reklamowych mogą zarejestrować tylko pierwszą regułę z danym kluczem deduplikacji lub zarejestrować wiele reguł albo wszystkie reguły. Podczas rejestrowania zduplikowanych wywołań dostawcy technologii reklamowych mogą określić deduplication_key.

Jeśli dostawca technologii reklamowych zarejestruje wiele wywołań z tym samym kluczem deduplikacji i przypisanym źródłem, w raportach na poziomie zdarzenia zostanie wysłane tylko pierwsze zarejestrowane wywołanie. Zduplikowane wyzwalacze są nadal wysyłane w zaszyfrowanych raportach podlegających agregacji.

Metoda alternatywna: dostawcy technologii reklamowych uzgadniają typy wywołań dla poszczególnych reklamodawców

W sytuacjach, gdy dostawcy technologii reklamowych nie chcą używać klucza deduplikacji lub gdy aplikacja reklamodawcy nie może go przekazać, istnieje alternatywna opcja. Wszystkie technologie reklamowe mierzące konwersje danego reklamodawcy muszą współpracować ze sobą, aby określać różne typy wywołań dla każdego reklamodawcy.

Technologie reklamowe, które inicjują wywołanie rejestracji wyzwalacza, np. pakiety SDK, umieszczają w adresach URL określonych w Attribution-Reporting-Redirect parametr, np. duplicate_trigger_id. Ten parametr duplicate_trigger_id może zawierać informacje takie jak nazwa pakietu SDK i typ wywołania dla danego reklamodawcy. Dostawcy technologii reklamowej mogą następnie wysyłać podzbiór tych zduplikowanych reguł do raportów na poziomie zdarzenia. Technologie reklamowe mogą też uwzględniać ten element duplicate_trigger_id w kluczach agregacji.

Przykład atrybucji międzysieciowej

W przykładzie opisanym w tej sekcji reklamodawca korzysta z 2 platform technologii reklamowych (technologia reklamowa A i technologia reklamowa B) oraz 1 partnera pomiarowego (MMP).

Na początek technologia reklamowa A, technologia reklamowa B i platforma MMP muszą zarejestrować się, aby korzystać z interfejsu Attribution Reporting API. Więcej informacji znajdziesz w artykule Rejestracja konta w Piaskownicy prywatności.

Poniższa lista zawiera hipotetyczną serię działań użytkownika, które występują w odstępie jednego dnia, oraz sposób, w jaki interfejs Attribution Reporting API obsługuje te działania w przypadku technologii reklamowej A, technologii reklamowej B i platformy MMP:

Dzień 1: użytkownik klika reklamę wyświetloną przez technologię reklamową A.

Technologia reklamowa A wywołuje funkcję registerSource() za pomocą swojego identyfikatora URI. Interfejs API wysyła żądanie do adresu URI, a kliknięcie jest rejestrowane z metadanymi z odpowiedzi serwera technologii reklamowej A.

Technologia reklamowa A zawiera też w nagłówku Attribution-Reporting-Redirect identyfikator URI platformy MMP. Interfejs API wysyła żądanie do identyfikatora URI MMP, a kliknięcie jest rejestrowane z metadanymi z odpowiedzi serwera MMP.

Dzień 2: użytkownik klika reklamę wyświetloną przez technologię reklamową B

Dostawca technologii reklamowych B wywołuje registerSource() za pomocą swojego identyfikatora URI. Interfejs API wysyła żądanie do identyfikatora URI, a kliknięcie jest rejestrowane z metadanymi z odpowiedzi serwera dostawcy technologii reklamowej B.

Podobnie jak dostawca technologii reklamowych A, dostawca technologii reklamowych B również umieścił w Attribution-Reporting-Redirect nagłówku identyfikator URI platformy MMP. Interfejs API wysyła żądanie do adresu URI platformy MMP, a kliknięcie jest rejestrowane z metadanymi z odpowiedzi serwera platformy MMP.

Dzień 3: użytkownik wyświetla reklamę obsługiwaną przez technologię reklamową A

Interfejs API odpowiada w taki sam sposób jak w dniu 1, z tym że wyświetlenie jest rejestrowane w przypadku technologii reklamowej A i platformy MMP.

Dzień 4. Użytkownik instaluje aplikację, która do pomiaru konwersji używa platformy MMP.

Platforma MMP wywołuje registerTrigger() za pomocą swojego identyfikatora URI. Interfejs API wysyła żądanie na adres URL, a konwersja jest rejestrowana z metadanymi z odpowiedzi serwera MMP.

MMP zawiera też identyfikatory URI technologii reklamowych A i B w nagłówku Attribution-Reporting-Redirect. Interfejs API wysyła żądania do serwerów technologii reklamowych A i B, a konwersja jest rejestrowana odpowiednio z metadanymi z odpowiedzi serwera.

Proces opisany na powyższej liście przedstawia ten diagram:

Atrybucja działa w ten sposób:

• Technologia reklamowa A ustawia priorytet kliknięć wyższy niż wyświetleń, dlatego instalacja jest przypisywana do kliknięcia z dnia 1.
• Technologia reklamowa B przypisuje instalację do dnia 2.
• Platforma MMP ustawia wyższy priorytet kliknięć niż wyświetleń i przypisuje instalację do kliknięcia z dnia 2. Kliknięcie z dnia 2 ma najwyższy priorytet, ponieważ jest to najnowsze zdarzenie związane z reklamą.

Atrybucja międzysieciowa bez przekierowań

Zalecamy stosowanie przekierowań, aby umożliwić różnym technologiom reklamowym rejestrowanie źródeł i wyzwalaczy atrybucji, ale zdajemy sobie sprawę, że w niektórych przypadkach używanie przekierowań może być niemożliwe. W tej sekcji dowiesz się, jak obsługiwać atrybucję w różnych sieciach bez przekierowań.

Przepływ zadań wysokiego poziomu

1. Podczas rejestracji źródła sieć technologii reklamowych wyświetlająca reklamy udostępnia klucze agregacji źródła.
2. Podczas rejestracji wyzwalacza reklamodawca lub partner pomiarowy wybiera, których kluczowych elementów po stronie źródła użyć, i określa konfigurację atrybucji.
3. Atrybucja jest oparta na konfiguracji atrybucji, kluczach udostępnionych i wszystkich źródłach, które zostały zarejestrowane przez reklamodawcę lub partnera pomiarowego (np. z innej sieci technologii reklamowych, która włączyła przekierowania).
4. Jeśli zdarzenie jest przypisane do źródła z technologii reklamowej wyświetlającej reklamy bez przekierowania, reklamodawca lub partner pomiarowy może otrzymać raport zbiorczy, który łączy źródło i kluczowe elementy zdarzenia zdefiniowane w kroku 2.

Rejestracja źródła

Podczas rejestracji źródła sieć technologii reklamowych wyświetlających reklamy może zamiast przekierowywać udostępniać klucze agregacji źródła lub ich podzbiór. Technologia wyświetlania reklam nie musi używać tych kluczy źródłowych we własnych raportach z możliwością agregacji i może je deklarować tylko w imieniu reklamodawcy lub partnera pomiarowego, jeśli jest to konieczne.

Udostępnione klucze agregacji są dostępne dla każdej platformy reklamowej, która zarejestruje wywołanie dla tego samego reklamodawcy. Jednak to technologia reklamowa wyświetlająca reklamy i technologia reklamowa pomiaru wywołania muszą współpracować w zakresie określania, jakich typów kluczy agregacji potrzebują, jakie są ich nazwy i jak dekodować klucze na czytelne wymiary.

Rejestracja aktywatora

Podczas rejestracji wyzwalacza technologia reklamowa pomiaru wybiera, które części klucza po stronie źródła mają być stosowane do poszczególnych części klucza wyzwalacza, w tym części udostępniane przez technologie reklamowe wyświetlania.

Dodatkowo technologia reklamowa do pomiarów musi też określić logikę atrybucji kaskadowej za pomocą nowego wywołania interfejsu API konfiguracji atrybucji. W tej konfiguracji dostawca technologii reklamowych może określić priorytet źródła, datę wygaśnięcia i filtry dla źródeł, do których nie miał dostępu (np. źródeł, które nie używały przekierowania).

Atrybucja

Interfejs Attribution Reporting API przeprowadza atrybucję według ostatniego kliknięcia z nadawaniem priorytetu źródłom w przypadku technologii reklamowych do pomiaru na podstawie ich konfiguracji atrybucji, kluczy wspólnych i wszelkich zarejestrowanych przez nie źródeł. Na przykład:

• Użytkownik kliknął reklamy wyświetlane przez technologie reklamowe A, B, C i D. Użytkownik zainstalował aplikację reklamodawcy, która korzysta z usług firmy uczestniczącej w programie Measurement Ad Tech Partner (MMP).
• Technologia reklamowa A przekierowuje swoje źródła do platformy MMP.
• Technologie reklamowe B i C nie przekierowują, ale udostępniają klucze agregacji.
• Technologia reklamowa D nie przekierowuje ani nie udostępnia kluczy agregacji.

Platforma MMP rejestruje źródło z technologii reklamowej A i definiuje konfigurację atrybucji, która obejmuje technologie reklamowe B i D.

Atrybucja w przypadku platformy MMP obejmuje teraz:

• Technologia reklamowa A, ponieważ platforma MMP zarejestrowała źródło z przekierowania tej technologii.
• Dostawca technologii reklamowych B, ponieważ udostępnił klucze, a platforma MMP uwzględniła go w konfiguracji atrybucji.

Atrybucja w przypadku platformy MMP nie obejmuje:

• Technologia reklamowa C, ponieważ platforma MMP nie uwzględniła jej w konfiguracji atrybucji.
• Technologia reklamowa D, ponieważ nie przekierowała ani nie udostępniła kluczy agregacji.

Debugowanie

Aby ułatwić debugowanie atrybucji w wielu sieciach bez przekierowań, dostawcy technologii reklamowych mogą ustawić dodatkowe pole shared_debug_key podczas rejestracji źródła. Jeśli zostanie ustawiony w rejestracji pierwotnego źródła, zostanie też ustawiony w odpowiednim źródle pochodnym jako debug_key podczas rejestracji wyzwalacza na potrzeby atrybucji w różnych sieciach bez przekierowań. Ten klucz debugowania jest dołączany jako source_debug_key w raportach o zdarzeniach i raportach zbiorczych.

Ta funkcja debugowania będzie obsługiwana tylko w przypadku atrybucji w wielu sieciach bez przekierowań w tych sytuacjach:

• Pomiar w przypadku aplikacji, w których dozwolony jest identyfikator AdID
• Pomiar przy przechodzeniu z aplikacji do witryny, w którym dozwolony jest identyfikator reklamowy i dopasowywanie w źródle aplikacji i w wyzwalaczu internetowym.
• Pomiar w internecie (w tej samej aplikacji przeglądarki), gdy w źródle i w wyzwalaczu występuje parametr ar_debug.

Odkrywanie kluczy na potrzeby atrybucji międzysieciowej bez przekierowań

Odkrywanie kluczy ma na celu uproszczenie sposobu, w jaki platformy technologii reklamowych (zwykle MMP) wdrażają konfigurację atrybucji na potrzeby atrybucji w wielu sieciach, gdy co najmniej jedna platforma technologii reklamowych wyświetlających reklamy używa wspólnych kluczy agregacji (zgodnie z opisem w sekcji Atrybucja w wielu sieciach bez przekierowań powyżej).

Gdy platforma MMP wysyła do usługi do agregacji zapytanie o wygenerowanie raportów podsumowujących dotyczących kampanii, które obejmują źródła pochodne, usługa do agregacji wymaga, aby platforma MMP określiła listę możliwych kluczy jako dane wejściowe zadania agregacji. W niektórych przypadkach lista potencjalnych kluczy agregacji źródła może być bardzo długa lub nieznana. Śledzenie dużych list możliwych kluczy jest trudne, a ich przetwarzanie może być dość złożone i kosztowne. Oto przykłady:

• Lista wszystkich możliwych kluczy jest długa:
  • Sieć reklamowa realizuje złożoną inicjatywę pozyskiwania użytkowników, która obejmuje 20 kampanii, z których każda zawiera 10 grup reklam, a każda grupa reklam – 5 kreacji odświeżanych co tydzień na podstawie skuteczności.
• Lista wszystkich możliwych kluczy jest nieznana:
  • Sieć reklamowa wyświetla reklamy w wielu aplikacjach mobilnych, w których pełna lista identyfikatorów aplikacji wydawcy nie jest znana w momencie uruchomienia kampanii.
  • Reklamodawca korzysta z wielu sieci reklamowych, które nie przekierowują do platformy MMP podczas rejestracji źródła. Każda sieć reklamowa ma inną strukturę kluczy i wartości, które mogą nie być wcześniej udostępniane platformie MMP.

Wraz z wprowadzeniem funkcji wykrywania kluczy:

• Usługa agregacji nie wymaga już pełnego wyliczenia możliwych kluczy agregacji.
• Zamiast podawać pełną listę możliwych kluczy, platforma MMP może utworzyć pusty (lub częściowo pusty) zbiór kluczy i ustawić próg, tak aby w danych wyjściowych były uwzględniane tylko klucze (niezadeklarowane wcześniej), których wartości przekraczają ten próg.
• Platforma MMP otrzymuje raport zbiorczy zawierający zaszumione wartości kluczy, które mają wartości składowe powyżej ustawionego progu. Raport może też zawierać klucze, które nie są powiązane z rzeczywistymi danymi od użytkowników i są jedynie zaszumione.
• Platforma MMP używa pola x_network_bit_mapping w rejestracji wyzwalacza, aby określić, która technologia reklamowa odpowiada któremu kluczowi.
• MMP może wtedy skontaktować się z odpowiednią platformą reklamową, aby poznać wartości w kluczu źródłowym.

Podsumowując, wykrywanie kluczy umożliwia platformom MMP uzyskiwanie kluczy agregacji bez wcześniejszej wiedzy o nich i unikanie przetwarzania dużej liczby kluczy źródłowych kosztem dodanego szumu.

Przekierowania łańcuchowe

Dostawca technologii reklamowych może używać interfejsu Attribution Reporting API do wykonywania wielu rejestracji źródła i aktywatora za pomocą jednego wywołania interfejsu API rejestracji, podając wiele nagłówków Attribution-Reporting-Redirect w odpowiedzi serwera HTTPS rejestracji źródła lub aktywatora.

W odpowiedzi serwera platforma reklamowa może też umieścić pojedynczy nagłówek Location (przekierowanie 302) z adresem URL, który z kolei prowadzi do kolejnej rejestracji, aż do osiągnięcia określonego limitu.

Oba typy nagłówków są opcjonalne i można z nich zrezygnować, jeśli przekierowania nie są potrzebne. Możesz podać jeden lub oba rodzaje nagłówków. Żądania rejestracji źródła i wyzwalacza (w tym przekierowania) są ponawiane w przypadku awarii sieci. Liczba ponownych prób na żądanie jest ograniczona do stałej wartości, aby uniknąć znaczącego wpływu na urządzenie.

Przekierowania nie są akceptowane w przypadku funkcji registerWebSource i registerWebTrigger używanych przez przeglądarki. Więcej informacji znajdziesz w przewodniku wdrażania w przypadku witryn i aplikacji.

Wyświetlanie danych pomiarowych w raportach atrybucji

Interfejs Attribution Reporting API umożliwia generowanie tych typów raportów, które są szczegółowo opisane poniżej:

• Raporty na poziomie zdarzenia łączą konkretne źródło atrybucji (kliknięcie lub wyświetlenie) z ograniczoną liczbą bitów danych aktywujących o wysokiej wierności.
• Raporty, które można agregować, nie są koniecznie powiązane z określonym źródłem atrybucji. Raporty te dostarczają bogatszych i dokładniejszych danych o wyzwalaczach niż raporty na poziomie zdarzenia, ale są one dostępne tylko w formie zbiorczej.

Te 2 rodzaje raportów uzupełniają się nawzajem i można ich używać jednocześnie.

Raporty na poziomie zdarzenia

Gdy wyzwalacz zostanie przypisany do źródła atrybucji, generowany jest raport na poziomie zdarzenia, który jest przechowywany na urządzeniu, dopóki nie będzie można go odesłać do adresu URL wywołania zwrotnego każdego dostawcy technologii reklamowej w jednym z okien czasowych wysyłania raportów, które zostały szczegółowo opisane w dalszej części tej strony.

Raporty na poziomie zdarzenia są przydatne, gdy potrzebujesz bardzo mało informacji o wywołaniu. Dane wyzwalacza na poziomie zdarzenia są ograniczone do 3 bitów danych wyzwalacza w przypadku kliknięć (co oznacza, że wyzwalacz można przypisać do jednej z 8 kategorii) i 1 bitu w przypadku wyświetleń. Raporty na poziomie zdarzenia nie obsługują też kodowania danych o wysokiej wierności po stronie wywołania, takich jak konkretna cena lub czas wywołania. Atrybucja odbywa się na urządzeniu, więc w raportach na poziomie zdarzenia nie ma obsługi analizy na różnych urządzeniach.

Raport na poziomie zdarzenia zawiera takie dane jak:

• Miejsce docelowe: nazwa pakietu aplikacji reklamodawcy lub eTLD+1, w którym wystąpił wyzwalacz.
• Identyfikator źródła atrybucji: ten sam identyfikator źródła atrybucji, który został użyty do zarejestrowania źródła atrybucji.
• Typ wyzwalacza: 1 lub 3 bity danych wyzwalacza o niskiej wierności, w zależności od typu źródła atrybucji

Mechanizmy ochrony prywatności stosowane we wszystkich raportach

Poniższe limity są stosowane po uwzględnieniu priorytetów dotyczących źródeł atrybucji i wyzwalaczy.

Ograniczenia liczby technologii reklamowych

Liczba dostawców technologii reklamowych, którzy mogą rejestrować się w interfejsie API lub otrzymywać z niego raporty, jest ograniczona. Obecnie proponujemy te limity:

• 100 technologii reklamowych ze źródłami atrybucji na {aplikację źródłową, aplikację docelową, 30 dni, urządzenie}.
• 10 technologii reklamowych z przypisanymi aktywatorami na {aplikację źródłową, aplikację docelową, 30 dni, urządzenie}.
• 20 dostawców technologii reklamowych może zarejestrować pojedyncze źródło lub wyzwalacz atrybucji (za pomocąAttribution-Reporting-Redirect).

Limity liczby unikalnych miejsc docelowych

Te limity utrudniają współpracę zestawowi technologii reklamowych, które mogą wysyłać zapytania do dużej liczby aplikacji, aby poznać zachowania użytkownika związane z korzystaniem z aplikacji.

• We wszystkich zarejestrowanych źródłach i we wszystkich technologiach reklamowych interfejs API obsługuje maksymalnie 200 niepowtarzalnych miejsc docelowych na aplikację źródłową na minutę.
• W przypadku wszystkich zarejestrowanych źródeł interfejs API obsługuje maksymalnie 50 niepowtarzalnych miejsc docelowych na aplikację źródłową na minutę w przypadku jednej technologii reklamowej. Ten limit zapobiega wykorzystaniu przez jednego dostawcę technologii reklamowych całego budżetu z poprzednio wspomnianego limitu częstotliwości.

Wygasłe źródła nie wliczają się do limitów liczby żądań.

1 źródło raportowania na aplikację źródłową dziennie

Dana platforma technologii reklamowych może używać tylko jednego źródła raportowania do rejestrowania źródeł w aplikacji wydawcy na danym urządzeniu w tym samym dniu. Ten limit częstotliwości uniemożliwia dostawcom technologii reklamowych korzystanie z wielu źródeł raportowania w celu uzyskania dostępu do dodatkowego budżetu na ochronę prywatności.

Rozważmy ten scenariusz, w którym jedna platforma reklamowa chce używać wielu źródeł raportowania do rejestrowania źródeł w aplikacji wydawcy na jednym urządzeniu.

1. Pochodzenie raportowania 1 technologii reklamowej A rejestruje źródło w aplikacji B.
2. 12 godzin później źródło raportowania technologii reklamowej A (2) próbuje zarejestrować źródło w aplikacji B.

Drugie źródło, czyli pochodzenie raportowania 2 technologii reklamowej A, zostanie odrzucone przez interfejs API. Pochodzenie raportowania 2 dostawcy technologii reklamowej A nie będzie mogło zarejestrować źródła na tym samym urządzeniu w aplikacji B do następnego dnia.

Okresy oczekiwania i limity liczby żądań

Aby ograniczyć wyciek tożsamości użytkownika między parą {source, destination}, API ogranicza ilość informacji wysyłanych przez użytkownika w danym okresie.

Obecna propozycja zakłada ograniczenie liczby przypisanych wywołań do 100 na każdą technologię reklamową w przypadku {aplikacji źródłowej, aplikacji docelowej, 30 dni, urządzenia}.

Liczba unikalnych miejsc docelowych

Interfejs API ogranicza liczbę miejsc docelowych, które może próbować mierzyć dostawca technologii reklamowych. Im niższy limit, tym trudniej jest platformie reklamowej używać interfejsu API do pomiaru aktywności użytkowników w internecie, która nie jest powiązana z wyświetlaniem reklam.

Obecna propozycja polega na ograniczeniu liczby różnych miejsc docelowych dla każdej technologii reklamowej do 100 w przypadku źródeł, które nie wygasły, w każdej aplikacji źródłowej.

Mechanizmy ochrony prywatności stosowane w raportach na poziomie zdarzenia

Ograniczona dokładność danych wywołujących

Interfejs API udostępnia 1 bit w przypadku wyzwalaczy konwersji po wyświetleniu i 3 bity w przypadku wyzwalaczy konwersji po kliknięciu. Źródła atrybucji nadal obsługują pełne 64 bity metadanych.

Zastanów się, czy i jak ograniczyć informacje zawarte w warunkach, aby działały one z ograniczoną liczbą bitów dostępnych w raportach na poziomie zdarzenia.

Ramy szumu do ochrony prywatności różnicowej

Celem tego interfejsu API jest umożliwienie pomiarów na poziomie zdarzenia, które spełniają lokalne wymagania dotyczące prywatności różnicowej, poprzez używanie odpowiedzi k-losowych do generowania zaszumionych danych wyjściowych dla każdego zdarzenia źródłowego.

Szum jest stosowany w przypadku zdarzenia źródłowego atrybucji, które jest raportowane zgodnie z prawdą. Źródło atrybucji jest rejestrowane na urządzeniu z prawdopodobieństwem $ 1-p$, że zostanie zarejestrowane w normalny sposób, oraz z prawdopodobieństwem $ p$, że urządzenie losowo wybierze jeden ze wszystkich możliwych stanów wyjściowych interfejsu API (w tym brak raportowania lub raportowanie wielu fałszywych raportów).

Odpowiedź k-losowa to algorytm, który jest epsilon-różnicowo prywatny, jeśli spełnione jest to równanie:

W przypadku małych wartości ε prawdziwe dane wyjściowe są chronione przez mechanizm k-randomizowanych odpowiedzi. Dokładne parametry szumu są w trakcie opracowywania i mogą ulec zmianie na podstawie opinii. Obecnie proponujemy te wartości:

• p=0,24% w przypadku źródeł nawigacji
• p=0,00025% w przypadku źródeł zdarzeń

Limity dotyczące dostępnych reguł (konwersji)

Istnieją limity liczby wyzwalaczy na źródło atrybucji. Obecnie proponujemy następujące limity:

• 1–2 reguły w przypadku źródeł atrybucji wyświetleń reklam (2 reguły są dostępne tylko w przypadku atrybucji po instalacji)
• 3 wyzwalacze źródeł atrybucji reklam po kliknięciu

Określone przedziały czasowe wysyłania raportów (domyślne działanie)

Raporty na poziomie zdarzenia dotyczące źródeł atrybucji wyświetleń reklam są wysyłane godzinę po wygaśnięciu źródła. Datę ważności można skonfigurować, ale nie może ona być krótsza niż 1 dzień ani dłuższa niż 30 dni. Jeśli 2 reguły są przypisane do źródła atrybucji wyświetlenia reklamy (za pomocą atrybucji po instalacji), raporty na poziomie zdarzenia mogą być wysyłane w określonych poniżej odstępach czasu okna raportowania.

Raportów na poziomie zdarzenia dotyczących źródeł atrybucji kliknięć reklam nie można skonfigurować. Są one wysyłane przed wygaśnięciem źródła lub w momencie jego wygaśnięcia, w określonych momentach w czasie w stosunku do momentu zarejestrowania źródła. Czas między źródłem atrybucji a wygasaniem jest dzielony na kilka okien raportowania. Każde okno raportowania ma termin (zgodny z czasem źródła atrybucji). Po zakończeniu każdego okresu raportowania urządzenie zbiera wszystkie wywołania, które wystąpiły od poprzedniego okresu raportowania, i wysyła zaplanowany raport. Interfejs API obsługuje te okresy raportowania:

• 2 dni: urządzenie zbiera wszystkie wywołania, które wystąpiły najpóźniej 2 dni po zarejestrowaniu źródła atrybucji. Raport jest wysyłany 2 dni i 1 godzinę po zarejestrowaniu źródła atrybucji.
• 7 dni: urządzenie zbiera wszystkie wyzwalacze, które wystąpiły ponad 2 dni, ale nie więcej niż 7 dni po zarejestrowaniu źródła atrybucji. Raport jest wysyłany 7 dni i 1 godzinę po zarejestrowaniu źródła atrybucji.
• niestandardowy okres określony przez atrybut „expiry” źródła atrybucji. Raport jest wysyłany godzinę po upływie określonego czasu wygaśnięcia. Ta wartość nie może być mniejsza niż 1 dzień ani większa niż 30 dni.

Elastyczna konfiguracja na poziomie zdarzenia

Domyślna konfiguracja raportowania na poziomie zdarzenia jest zalecana dostawcom technologii reklamowej na początek testów, ale może nie być idealna we wszystkich przypadkach użycia. Interfejs Attribution Reporting API będzie obsługiwać opcjonalne i bardziej elastyczne konfiguracje, dzięki czemu dostawcy technologii reklamowych będą mieć większą kontrolę nad strukturą raportów na poziomie zdarzenia i będą mogli maksymalizować użyteczność danych.

Ta dodatkowa elastyczność zostanie wprowadzona w interfejsie Attribution Reporting API w 2 fazach:

• Etap 1. Uproszczona konfiguracja elastycznego poziomu zdarzenia
  • Ta wersja zawiera podzbiór pełnych funkcji i może być używana niezależnie od etapu 2.
• Etap 2. Pełna wersja elastycznej konfiguracji na poziomie zdarzenia

Etap 1 (uproszczony elastyczny poziom zdarzeń) może być używany do:

• Zmieniaj częstotliwość raportów, określając liczbę okresów raportowania.
• Zmieniaj liczbę atrybucji na rejestrację źródła
• Zmniejsz całkowitą ilość szumu, zmniejszając wartości powyższych parametrów.
• Konfigurowanie okresów raportowania zamiast korzystania z wartości domyślnych

Etap 2 (pełna elastyczność na poziomie zdarzenia) umożliwia korzystanie ze wszystkich funkcji z etapu 1 oraz:

• Zmieniać moc zbioru danych wywołujących w raporcie
• Zmniejsz ilość szumu, zmniejszając liczność danych wyzwalających.

Zmniejszenie jednego wymiaru domyślnej konfiguracji pozwala technologii reklamowej zwiększyć inny wymiar. Możesz też zmniejszyć łączną ilość szumu w raporcie na poziomie zdarzenia, zmniejszając parametry wymienione wcześniej.

Oprócz dynamicznego ustawiania poziomów szumu na podstawie wybranej konfiguracji technologii reklamowej będziemy mieć pewne limity parametrów, aby uniknąć wysokich kosztów obliczeniowych i konfiguracji z zbyt dużą liczbą stanów wyjściowych (w których szum znacznie wzrośnie). Oto przykładowy zestaw ograniczeń. Zachęcamy do przesyłania opinii na temat propozycji projektu:

• Maksymalnie 20 raportów łącznie na całym świecie i w przypadku każdego parametru trigger_data
• Maksymalnie 5 możliwych okresów raportowania na trigger_data
• Maksymalna moc zbioru danych wywołujących to 32 (nie dotyczy fazy 1: Lite Elastyczny poziom zdarzenia).

Gdy dostawcy technologii reklamowych zaczną korzystać z tej funkcji, pamiętaj, że używanie wartości ekstremalnych może powodować dużą ilość szumu lub brak rejestracji, jeśli nie zostaną spełnione poziomy ochrony prywatności.

Raporty, które można agregować

Zanim zaczniesz korzystać z raportów z możliwością agregacji, musisz skonfigurować konto w chmurze i zacząć otrzymywać takie raporty.

Raporty z możliwością agregacji dostarczają dokładniejsze dane o wyzwalaczach z urządzenia szybciej niż raporty na poziomie zdarzenia. Te bardziej precyzyjne dane można uzyskać tylko w formie zbiorczej i nie są one powiązane z konkretnym wywołaniem ani użytkownikiem. Klucze agregacji mają maksymalnie 128 bitów, co umożliwia raportom z możliwością agregacji obsługę przypadków użycia raportowania, takich jak:

• Raporty dotyczące wartości wyzwalających, np. przychodów
• Obsługa większej liczby typów reguł

Raporty zbiorcze korzystają z tej samej logiki atrybucji z określaniem priorytetów źródeł co raporty na poziomie zdarzenia, ale obsługują więcej konwersji przypisanych do kliknięcia lub wyświetlenia.

Ogólna struktura przygotowywania i wysyłania raportów z możliwością agregacji przez interfejs Attribution Reporting API, przedstawiona na diagramie, jest następująca:

1. Urządzenie wysyła zaszyfrowane raporty do firmy zajmującej się technologiami reklamowymi. W środowisku produkcyjnym firmy te nie mogą bezpośrednio korzystać z tych raportów.
2. Dostawca technologii reklamowej wysyła do usługi do agregacji partię raportów z możliwością agregacji w celu ich agregacji.
3. Usługa do agregacji odczytuje partię raportów, które można agregować, odszyfrowuje je i agreguje.
4. Końcowe dane zbiorcze są odsyłane do dostawcy technologii reklamowej w raporcie podsumowującym.

Raporty z możliwością agregacji zawierają te dane dotyczące źródeł atrybucji:

• Miejsce docelowe: nazwa pakietu aplikacji lub adres URL witryny eTLD+1, w której wystąpił wyzwalacz.
• Data: data wystąpienia zdarzenia reprezentowanego przez źródło atrybucji.
• Ładunek: wartości wyzwalaczy zbierane jako zaszyfrowane pary klucz-wartość, które są używane w zaufanej usłudze do agregacji do obliczania agregacji.

Usługi agregacji

Te usługi zapewniają funkcje agregacji danych i chronią przed nieuprawnionym dostępem do zagregowanych danych.

Usługi te są zarządzane przez różne podmioty, które opisujemy szczegółowo w dalszej części tej strony:

• Usługa do agregacji to jedyna usługa, którą dostawcy technologii reklamowych powinni wdrożyć.
• Usługi zarządzania kluczami i rozliczania raportów zbiorczych są obsługiwane przez zaufane podmioty zewnętrzne, zwane koordynatorami. Koordynatorzy potwierdzają, że kod uruchamiający usługę agregacji to publicznie dostępny kod dostarczony przez Google oraz że wszyscy użytkownicy usługi agregacji mają ten sam klucz i są objęci usługami rozliczania raportów podlegających agregacji.

Usługa agregacji

Platformy technologii reklamowych muszą z wyprzedzeniem wdrożyć usługę agregacji opartą na plikach binarnych dostarczonych przez Google.

Ta usługa agregacji działa w zaufanym środowisku wykonawczym (TEE) hostowanym w chmurze. TEE zapewnia te korzyści w zakresie bezpieczeństwa:

• Dzięki temu masz pewność, że kod działający w środowisku TEE to konkretny plik binarny oferowany przez Google. Jeśli ten warunek nie zostanie spełniony, usługa agregacji nie będzie mieć dostępu do kluczy deszyfrujących, których potrzebuje do działania.
• Zapewnia bezpieczeństwo procesu, izolując go od zewnętrznego monitorowania lub manipulacji.

Dzięki tym zaletom w zakresie bezpieczeństwa usługa agregacji może bezpieczniej wykonywać operacje wymagające dostępu do danych wrażliwych, np. zaszyfrowanych.

Więcej informacji o projektowaniu, przepływie pracy i kwestiach związanych z bezpieczeństwem usługi agregacji znajdziesz w dokumencie dotyczącym usługi agregacji na GitHubie.

Usługa zarządzania kluczami

Ta usługa sprawdza, czy usługa agregacji korzysta z zatwierdzonej wersji pliku binarnego, a następnie udostępnia usłudze reklamowej prawidłowe klucze odszyfrowywania danych o zdarzeniach.

Rozliczanie raportów zbiorczych

Ta usługa śledzi, jak często usługa agregacji technologii reklamowej uzyskuje dostęp do określonego wyzwalacza, który może zawierać wiele kluczy agregacji, i ogranicza dostęp do odpowiedniej liczby odszyfrowań. Szczegółowe informacje znajdziesz w projekcie usługi do agregacji na potrzeby interfejsu Attribution Reporting API.

Interfejs Aggregatable Reports API

Interfejs API do tworzenia wkładów w raportach zbiorczych korzysta z tej samej podstawy interfejsu API co rejestrowanie źródła atrybucji w przypadku raportów na poziomie zdarzenia. W sekcjach poniżej opisujemy rozszerzenia interfejsu API.

Rejestrowanie danych źródłowych, które można agregować

Gdy interfejs API wysyła żądanie do identyfikatora URI źródła atrybucji, dostawca technologii reklamowej może zarejestrować listę kluczy agregacji o nazwie histogram_contributions, odpowiadając nowym polem o nazwie aggregation_keys w nagłówku HTTP Attribution-Reporting-Register-Source, gdzie klucz to key_name, a wartość to key_piece:

• (Key) Nazwa klucza: ciąg znaków z nazwą klucza. Używany jako klucz łączenia do łączenia z kluczami po stronie wyzwalacza w celu utworzenia klucza końcowego.
• (Wartość) Klucz: wartość klucza w postaci ciągu bitów.

Ostateczny klucz do przedziału histogramu jest w pełni definiowany w momencie wywołania przez wykonanie operacji OR na tych częściach i częściach po stronie wywołania.

Klucze końcowe są ograniczone do maksymalnie 128 bitów. Klucze dłuższe niż ten limit są obcinane. Oznacza to, że ciągi szesnastkowe w JSON powinny mieć maksymalnie 32 cyfry.

Dowiedz się więcej o strukturze kluczy agregacji i o tym, jak je skonfigurować.

W tym przykładzie technologia reklamowa używa interfejsu API do zbierania tych informacji:

• Zbiorcze liczby konwersji na poziomie kampanii
• Zbieranie wartości zakupu na poziomie geograficznym

// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

Rejestrowanie aktywowanego zdarzenia z możliwością agregacji

Rejestracja wyzwalacza obejmuje 2 dodatkowe pola.

Pierwsze pole służy do rejestrowania listy kluczy agregacji po stronie wyzwalacza. Technologia reklamowa powinna odpowiedzieć, podając pole aggregatable_trigger_data w nagłówku HTTP Attribution-Reporting-Register-Trigger, z tymi polami dla każdego klucza zbiorczego na liście:

• Klucz: ciąg bitów będący wartością klucza.
• Klucze źródłowe: lista ciągów tekstowych z nazwami kluczy po stronie źródła atrybucji, z którymi należy połączyć klucz aktywatora, aby utworzyć klucze końcowe.

Drugie pole służy do rejestrowania listy wartości, które powinny być uwzględniane w przypadku każdego klucza. Technologia reklamowa powinna odpowiedzieć, podając pole aggregatable_values w nagłówku HTTP Attribution-Reporting-Register-Trigger. Drugie pole służy do rejestrowania listy wartości, które powinny być uwzględniane w przypadku każdego klucza. Mogą to być liczby całkowite z zakresu $ [1, 2^{16}] $.

Każdy wyzwalacz może mieć wiele wkładów w raporty zbiorcze. Łączna kwota wkładów w dowolne zdarzenie źródłowe jest ograniczona przez parametr $ L1 $, który jest maksymalną sumą wkładów (wartości) we wszystkich kluczach agregacji dla danego źródła. $ L1 $ to czułość lub norma L1 wkładów histogramu dla każdego zdarzenia źródłowego. Przekroczenie tych limitów powoduje, że przyszłe wpisy są pomijane. Początkowa propozycja to ustawienie wartości $ L1 $ na $ 2^{16} $ (65536).

Szum w usłudze agregacji jest skalowany proporcjonalnie do tego parametru. Z tego powodu zalecamy odpowiednie skalowanie wartości raportowanych dla danego klucza zbiorczego na podstawie części budżetu $ L1 $ do niego przypisanego. Dzięki temu zagregowane raporty zachowują najwyższą możliwą dokładność po zastosowaniu szumu. Ten mechanizm jest bardzo elastyczny i może obsługiwać wiele strategii agregacji.

W tym przykładzie budżet ochrony prywatności jest dzielony po równo między campaignCounts i geoValue przez podzielenie wkładu $ L1 $ do każdego z nich:

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

Powyższy przykład generuje te wartości histogramu:

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

Czynniki skalowania można odwrócić, aby uzyskać prawidłowe wartości, z wyjątkiem szumu, który jest stosowany:

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

Prywatność różnicowa

Celem tego interfejsu API jest stworzenie platformy, która może obsługiwać pomiary zbiorcze z różnicową ochroną prywatności. Można to osiągnąć, dodając szum proporcjonalny do budżetu $ L1 $, np. wybierając szum o następującym rozkładzie:

Integracja interfejsów Protected Audience API i Attribution Reporting API

Integracja między interfejsami Protected Audience API i Attribution Reporting API umożliwia firmom technologicznym z branży reklamowej ocenę skuteczności atrybucji w przypadku różnych taktyk remarketingu, aby dowiedzieć się, które typy odbiorców zapewniają najwyższy zwrot z inwestycji.

Dzięki tej integracji interfejsów API platformy reklamowe mogą:

• Utwórz mapę klucz-wartość identyfikatorów URI, która będzie używana zarówno do 1) raportowania interakcji, jak i 2) rejestracji źródła.
• W mapowaniu kluczy po stronie źródła uwzględnij CustomAudience w przypadku raportowania podsumowującego (przy użyciu interfejsu Attribution Reporting API).

Gdy użytkownik zobaczy lub kliknie reklamę:

• Adres URL używany do raportowania tych interakcji za pomocą interfejsu Protected Audience API będzie też używany do rejestrowania wyświetlenia lub kliknięcia jako kwalifikującego się źródła w interfejsie Attribution Reporting API.
• Technologia reklamowa może przekazywać listę odbiorców niestandardowych (lub inne istotne informacje kontekstowe o reklamie, takie jak miejsce docelowe reklamy czy czas wyświetlania) za pomocą tego adresu URL, aby te metadane mogły być uwzględniane w raportach zbiorczych, gdy technologia reklamowa analizuje zbiorczą skuteczność kampanii.

Więcej informacji o tym, jak to działa w przypadku Protected Audience, znajdziesz w odpowiedniej sekcji wyjaśnienia interfejsu Protected Audience API.

Przykłady priorytetu rejestracji, atrybucji i raportowania

Ten przykład przedstawia zestaw interakcji użytkowników oraz sposób, w jaki zdefiniowane przez technologię reklamową priorytety źródła atrybucji i wyzwalacza mogą wpływać na raporty o atrybucji. W tym przykładzie zakładamy, że:

• Wszystkie źródła i wyzwalacze atrybucji są rejestrowane przez tę samą technologię reklamową na potrzeby tego samego reklamodawcy.
• Wszystkie źródła i wyzwalacze atrybucji występują w pierwszym oknie raportowania zdarzeń (w ciągu 2 dni od pierwszego wyświetlenia reklam w aplikacji wydawcy).

Rozważmy przypadek, w którym użytkownik wykonuje te czynności:

1. Użytkownik widzi reklamę. Technologia reklamowa rejestruje źródło atrybucji w interfejsie API z priorytetem 0 (wyświetlenie 1).
2. Użytkownik widzi reklamę zarejestrowaną z priorytetem 0 (wyświetlenie 2).
3. Użytkownik klika reklamę zarejestrowaną z priorytetem 1 (kliknięcie nr 1).
4. Użytkownik dokonuje konwersji (trafia na stronę docelową) w aplikacji reklamodawcy. Technologia reklamowa rejestruje w interfejsie API wywołanie z priorytetem 0 (konwersja 1).
   • Gdy wyzwalacze zostaną zarejestrowane, interfejs API najpierw przeprowadza atrybucję, a potem generuje raporty.
   • Dostępne są 3 źródła atrybucji: wyświetlenie 1, wyświetlenie 2 i kliknięcie 1. Interfejs API przypisuje ten wyzwalacz do kliknięcia 1, ponieważ ma ono najwyższy priorytet i jest najnowsze.
   • Widok 1 i widok 2 zostaną odrzucone i nie będą już kwalifikować się do przyszłej atrybucji.
5. Użytkownik dodaje produkt do koszyka w aplikacji reklamodawcy zarejestrowanej z priorytetem 1 (konwersja nr 2).
   • Kliknięcie 1 jest jedynym kwalifikującym się źródłem atrybucji. Interfejs API przypisuje ten aktywator do kliknięcia 1.
6. Użytkownik dodaje produkt do koszyka w aplikacji reklamodawcy zarejestrowanej z priorytetem 1 (konwersja nr 3).
   • Kliknięcie 1 jest jedynym kwalifikującym się źródłem atrybucji. Interfejs API przypisuje ten aktywator do kliknięcia 1.
7. Użytkownik dodaje produkt do koszyka w aplikacji reklamodawcy zarejestrowanej z priorytetem 1 (konwersja nr 4).
   • Kliknięcie 1 jest jedynym kwalifikującym się źródłem atrybucji. Interfejs API przypisuje ten aktywator do kliknięcia 1.
8. Użytkownik dokonuje zakupu w aplikacji reklamodawcy zarejestrowanej z priorytetem 2 (konwersja nr 5).
   • Kliknięcie 1 jest jedynym kwalifikującym się źródłem atrybucji. Interfejs API przypisuje ten aktywator do kliknięcia 1.

Raporty na poziomie zdarzenia mają te cechy:

• Domyślnie pierwsze 3 wyzwalacze przypisane do kliknięcia i pierwszy wyzwalacz przypisany do wyświetlenia są wysyłane po upływie odpowiednich okien raportowania.
• Jeśli w okresie raportowania zarejestrowane są wyzwalacze o wyższym priorytecie, mają one pierwszeństwo i zastępują ostatni wyzwalacz.
• W powyższym przykładzie po 2-dniowym oknie raportowania technologia reklamowa otrzymuje 3 raporty o zdarzeniach dotyczące konwersji nr 2, 3 i 5.
  • Wszystkie 5 reguł jest przypisanych do kliknięcia 1. Domyślnie interfejs API wysyła raporty dotyczące pierwszych 3 wyzwalaczy: konwersji 1, konwersji 2 i konwersji 3.
  • Priorytet konwersji 4 (1) jest jednak wyższy niż priorytet konwersji 1 (0). Raport o zdarzeniu konwersji 4 zastępuje raport o zdarzeniu konwersji 1 i jest wysyłany.
  • Dodatkowo priorytet konwersji 5 (2) jest wyższy niż w przypadku innych wywołań. Raport o zdarzeniu konwersji nr 5 zastępuje raport o zdarzeniu konwersji nr 4, który ma zostać wysłany.

Raporty, które można agregować, mają te cechy:

• Zaszyfrowane raporty z możliwością agregacji są wysyłane do dostawcy technologii reklamowej od razu po przetworzeniu, czyli kilka godzin po zarejestrowaniu wyzwalaczy.

  Jako dostawca technologii reklamowych tworzysz partie na podstawie informacji, które są dostępne w niezaszyfrowanej formie w raportach zbiorczych. Te informacje znajdują się w polu shared_info w raporcie z możliwością agregacji i obejmują sygnaturę czasową oraz źródło raportowania. Nie możesz tworzyć partii na podstawie żadnych zaszyfrowanych informacji w parach klucz-wartość klucza agregacji. Podstawowe strategie, które możesz zastosować, to grupowanie raportów codziennie lub co tydzień. Najlepiej, aby każda partia zawierała co najmniej 100 raportów.

• To dostawca technologii reklamowej decyduje, kiedy i jak grupować raporty z możliwością agregacji i wysyłać je do usługi agregującej.

• W porównaniu z raportami na poziomie zdarzenia zaszyfrowane raporty z możliwością agregacji mogą przypisywać do źródła więcej wywołań.

• W powyższym przykładzie wysyłanych jest 5 raportów z możliwością agregacji – po jednym na każdy zarejestrowany wyzwalacz.

Raporty debugowania przejściowego

Interfejs Attribution Reporting API to nowy i dość złożony sposób pomiaru atrybucji bez identyfikatorów między aplikacjami. W związku z tym wprowadzamy mechanizm przejściowy, który pozwala uzyskać więcej informacji o raportach o atrybucji w przypadku, gdy identyfikator reklamowy jest dostępny (użytkownik nie zrezygnował z personalizacji przy użyciu identyfikatora reklamowego, a aplikacja wydawcy lub reklamodawcy zadeklarowała uprawnienia do identyfikatora reklamowego). Dzięki temu podczas wdrażania interfejsu API można w pełni zrozumieć jego działanie, wyeliminować wszelkie błędy i łatwiej porównać skuteczność z alternatywnymi rozwiązaniami opartymi na identyfikatorach reklamowych. Dostępne są 2 rodzaje raportów debugowania: attribution-success i verbose.

Więcej informacji o debugowaniu raportów z pomiarami w przypadku przejść z aplikacji do witryny i z witryny do aplikacji znajdziesz w przewodniku po raportach debugowania w okresie przejściowym.

Raporty debugowania atrybucji

Rejestracje źródła i wyzwalacza akceptują nowe 64-bitowe pole debug_key (sformatowane jako ciąg tekstowy), które wypełnia technologia reklamowa. Znaki source_debug_key i trigger_debug_key są przekazywane bez zmian zarówno w raportach na poziomie zdarzenia, jak i w raportach zbiorczych.

Jeśli raport zostanie utworzony z użyciem kluczy debugowania źródła i wyzwalacza, zduplikowany raport debugowania zostanie wysłany z niewielkim opóźnieniem do punktu końcowego .well-known/attribution-reporting/debug/report-event-attribution. Raporty debugowania są identyczne z normalnymi raportami i zawierają oba pola klucza debugowania. Umieszczenie tych kluczy w obu rodzajach raportów umożliwia powiązanie zwykłych raportów z osobnym strumieniem raportów debugowania.

• W przypadku raportów na poziomie zdarzenia:
  • Zduplikowane raporty debugowania są wysyłane z niewielkim opóźnieniem, więc nie są pomijane przez limity dostępne wyzwalacze. Dzięki temu dostawcy technologii reklamowej mogą zrozumieć wpływ tych limitów na raporty na poziomie zdarzenia.
  • Raporty na poziomie zdarzenia powiązane z fałszywymi zdarzeniami wyzwalającymi nie będą zawierać symbolu trigger_debug_key. Dzięki temu platformy reklamowe mogą lepiej zrozumieć, w jaki sposób w interfejsie API stosowane są szumy.
• W przypadku raportów, które można agregować:
  • Będziemy obsługiwać nowe pole debug_cleartext_payload, które zawiera odszyfrowany ładunek, tylko wtedy, gdy ustawione są zarówno parametry source_debug_key, jak i trigger_debug_key.

Szczegółowe raporty debugowania

Szczegółowe raporty debugowania umożliwiają deweloperom monitorowanie niektórych błędów w rejestracjach źródła atrybucji lub wyzwalacza. Te raporty debugowania są wysyłane z niewielkim opóźnieniem po zarejestrowaniu źródła atrybucji lub wywołania do .well-known/attribution-reporting/debug/verbose punkt końcowy.

Każdy szczegółowy raport zawiera te pola:

• Typ: co spowodowało wygenerowanie raportu. Zobacz pełną listę typów szczegółowych raportów.
  • Ogólnie rzecz biorąc, istnieją szczegółowe raporty o źródłach i szczegółowe raporty o wyzwalaczach.
  • Raporty szczegółowe dotyczące źródła wymagają, aby identyfikator wyświetlania reklam był dostępny dla aplikacji wydawcy, a raporty szczegółowe dotyczące wywoływania wymagają, aby identyfikator wyświetlania reklam był dostępny dla aplikacji reklamodawcy.
  • Szczegółowe raporty o wyzwalaniu (z wyjątkiem trigger-no-matching-source) mogą opcjonalnie zawierać source_debug_key. Można go uwzględnić tylko wtedy, gdy identyfikator wyświetlania reklam jest też dostępny w aplikacji wydawcy.
• Treść: treść raportu, która zależy od jego typu.

Dostawcy technologii reklamowych muszą wyrazić zgodę na otrzymywanie szczegółowych raportów debugowania, korzystając z nowego pola słownika debug_reporting w nagłówkach Attribution-Reporting-Register_Source i Attribution-Reporting-Register-Trigger.

• Szczegółowe raporty o źródłach wymagają zgody tylko w nagłówku rejestracji źródła.
• Raporty debugowania reguł wymagają włączenia tylko w nagłówku rejestracji reguły.

Jak korzystać z raportów debugowania

Jeśli konwersja miała miejsce (zgodnie z dotychczasowym systemem pomiarowym) i otrzymano raport debugowania dotyczący tej konwersji, oznacza to, że wyzwalacz został zarejestrowany.

W przypadku każdego raportu atrybucji do debugowania sprawdź, czy otrzymujesz zwykły raport atrybucji, który pasuje do 2 kluczy debugowania.

Jeśli nie ma dopasowania, może to być spowodowane kilkoma czynnikami.

Działa zgodnie z oczekiwaniami:

• Zachowania interfejsu API chroniące prywatność:
  • Użytkownik osiągnie limit liczby raportów, co spowoduje, że wszystkie kolejne raporty nie będą wysyłane w danym okresie, lub źródło zostanie usunięte z powodu limitu oczekujących miejsc docelowych.
  • W przypadku raportów na poziomie zdarzenia: raport podlega losowej odpowiedzi (szumowi) i jest pomijany lub możesz otrzymać raport wygenerowany losowo.
  • W przypadku raportów na poziomie zdarzenia: osiągnięto limit 3 raportów (w przypadku kliknięć) lub 1 raportu (w przypadku wyświetleń), a kolejne raporty nie mają ustawionego jawnego priorytetu lub mają priorytet niższy niż istniejące raporty.
  • Przekroczono limity udziału w przypadku raportów, które można agregować.
• Logika biznesowa zdefiniowana przez technologię reklamową:
  • Wywołanie zostało odfiltrowane za pomocą filtrów lub reguł priorytetu.
• opóźnienia lub interakcje związane z dostępnością sieci (np. użytkownik wyłącza urządzenie na dłuższy czas);

Niezamierzone przyczyny:

• Problemy z wdrożeniem:
  • Nagłówek źródła jest nieprawidłowo skonfigurowany.
  • Nagłówek aktywatora jest nieprawidłowo skonfigurowany.
  • Inne problemy z konfiguracją.
• Problemy z urządzeniem lub siecią:
  • Błędy spowodowane warunkami sieci.
  • Odpowiedź na rejestrację źródła lub wywołania nie dociera do klienta.
  • błąd interfejsu API,

Przyszłe kwestie i otwarte pytania

Prace nad interfejsem Attribution Reporting API wciąż trwają. Badamy też potencjalne przyszłe funkcje, takie jak modele atrybucji niezwiązane z ostatnim kliknięciem i przypadki użycia pomiarów na różnych urządzeniach.

Chcielibyśmy też poznać opinię społeczności na temat kilku kwestii:

1. Czy są jakieś przypadki użycia, w których chcesz, aby interfejs API wysyłał raporty dotyczące zweryfikowanej instalacji? Raporty te będą wliczane do limitów częstotliwości poszczególnych platform technologii reklamowych.
2. Czy przewidujesz jakieś trudności z przekazywaniem InputEvent z aplikacji do technologii reklamowej na potrzeby rejestracji źródła?
3. Czy masz jakieś specjalne przypadki użycia atrybucji w przypadku wstępnie załadowanych lub ponownie zainstalowanych aplikacji?