Omówienie raportów atrybucji dla urządzeń mobilnych

Prześlij opinię

Ostatnie aktualizacje

  • Zaktualizowaliśmy listę nadchodzących zmian i znanych problemów.
  • Wprowadziliśmy elastyczną konfigurację na poziomie zdarzenia Lite, która stanowi pomost do pełnego wdrożenia elastyczną konfigurację na poziomie zdarzenia,
  • Od września 2023 r., registerWebSource, registerWebTrigger, registerAppSource i registerAppTrigger muszą używać ciągów znaków dla pól, które: spodziewaj się wartości liczbowej (np. priority, source_event_id, debug_key, trigger_data, deduplication_key itp.)
  • W IV kwartale 2023 r. obsługa Google Cloud w interfejsie Android Attribution Reporting API mogą zostać dodane w celu generowania raportów podsumowujących za pomocą usługi agregacji w Google. Google Cloud, tutaj znajdziesz bardziej szczegółowy czas. Więcej informacji znajdziesz w przewodniku wdrażania Dowiedz się, jak skonfigurować usługę agregacji w Google Cloud.
  • Nowe limity stawek chroniące prywatność dla liczby unikalnych miejsc docelowych.
  • Zaktualizowana funkcjonalność filtrów reguły okresu ważności zostanie udostępniona w I kwartale 2024 r. Więcej informacji na ten temat znajdziesz w uwagach.

Omówienie

Obecnie rozwiązania do atrybucji i pomiarów na urządzeniach mobilnych często wykorzystują identyfikatory pochodzące z różnych źródeł, np. identyfikator wyświetlania reklam. Attribution Reporting API ma zapewniać lepszą ochronę prywatności użytkowników przez wyeliminowanie zależności od źródeł identyfikatory użytkowników, a także do obsługi kluczowych przypadków użycia atrybucji i konwersji w wielu aplikacjach i internecie.

Ten interfejs API ma poniższe mechanizmy strukturalne, które oferują platformę poprawie prywatności, co w dalszych sekcjach tej strony szczegóły:

Poprzednie mechanizmy ograniczają możliwość łączenia tożsamości użytkownika 2 z tych z różnych aplikacji lub domen.

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

  • Raportowanie konwersji: pomóż reklamodawcom mierzyć skuteczność kampanii, pokazując liczbę konwersji (reguł) i liczbę konwersji. (reguły) w różnych wymiarach, takich jak kampania, grupa reklam i kreację.
  • Optymalizacja: udostępnia raporty na poziomie zdarzenia, które wspomagają optymalizację wydatki na reklamę, dostarczając dane atrybucji dla poszczególnych wyświetleń, które można wykorzystać do trenowania modeli ML.
  • Wykrywanie nieprawidłowej aktywności: umożliwia przesyłanie raportów, które można wykorzystać w przypadku nieprawidłowej aktywności. wykrywanie i analizę ruchu oraz oszustw reklamowych.

Ogólnie interfejs Attribution Reporting API działa w ten sposób, który później tego dokumentu bardziej szczegółowo opisują te funkcje:

  1. Dział technologii reklamowych przechodzi proces rejestracji, za pomocą interfejsu Attribution Reporting API.
  2. Technologia reklamowa rejestruje źródła atrybucji – reklama liczby kliknięć i wyświetleń – za pomocą Attribution Reporting API.
  3. Technologia reklamowa rejestruje reguły, czyli konwersje użytkowników na aplikacji lub witryny reklamodawcy – za pomocą Attribution Reporting API.
  4. Interfejs Attribution Reporting API dopasowuje reguły do źródeł atrybucji: atrybucji konwersji – i co najmniej 1 reguła jest wysyłana poza urządzenie przez na poziomie zdarzenia zbiorcze raporty dla technologii reklamowych.
.

Dostęp do interfejsów Attribution Reporting API

Platformy technologii reklamowych muszą się zarejestrować, aby uzyskać dostęp do interfejsów Attribution Reporting API. Więcej informacji: Aby uzyskać więcej informacji, załóż konto Piaskownicy prywatności.

Rejestrowanie źródła atrybucji (kliknięcie lub wyświetlenie)

W interfejsie Attribution Reporting API kliknięcia i obejrzenia reklam są określane jako atrybucja . Aby zarejestrować kliknięcie lub wyświetlenie reklamy, wywołaj registerSource(). Ten interfejs API oczekuje tych parametrów:

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

Gdy interfejs API wysyła żądanie do identyfikatora URI źródła atrybucji, technologia reklamowa powinna w odpowiedzi, przesyłając metadane źródła atrybucji w nowym nagłówku HTTP Attribution-Reporting-Register-Source z tymi polami:

  • Source event ID (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 być 64-bitową bez podpisu liczba całkowita w formacie ciągu znaków.
  • Miejsce docelowe: miejsce wylotu, którego domena eTLD+1 lub nazwa pakietu aplikacji, gdzie zdarzenia aktywującego.
  • Wygaśnięcie (opcjonalnie): wygasa w sekundach, gdy źródło powinno być usunięte z urządzenia. Wartość domyślna to 30 dni, a minimalna wartość to 1 dzień a maksymalna wartość to 30 dni. Ta wartość jest zaokrąglana do najbliższego dnia. Może być w postaci 64-bitowej nieoznaczonej liczby całkowitej lub ciągu znaków.
  • Okno raportu o zdarzeniach (opcjonalnie): czas trwania w sekundach po źródle. rejestracji, podczas którego mogą być tworzone raporty zdarzeń dla tego źródła. Jeśli raport zdarzenia już minął, ale jeszcze nie upłynął jego termin ważności, regułę można dopasować do źródła, ale raport zdarzeń wysłanych dla tego wyzwalacza. Nie może być większe niż data wygaśnięcia. Może być sformatowany jako albo 64-bitową nieoznaczoną liczbą całkowitą lub ciągiem znaków.
  • Okno raportu agregowanego (opcjonalnie): czas trwania w sekundach po źródle. rejestracji, podczas których mogą zostać utworzone raporty zbiorcze dotyczące tej źródła. Nie może być większe niż data wygaśnięcia. Może być sformatowana jako 64-bitowa. nieoznaczona liczba całkowita lub ciąg znaków.
  • Priorytet źródła (opcjonalny): służy do wyboru źródła atrybucji, dana reguła powinna być powiązana z, w przypadku, gdy istnieje wiele atrybucji źródeł powiązanych z regułą. Musi być 64-bitowy i podpisany. liczba całkowita w formacie ciągu znaków.

    Po otrzymaniu aktywatora interfejs API znajduje pasujące źródło atrybucji o najwyższej wartości priorytetu źródła i generuje raport. Każda platforma technologii reklamowych może zdefiniować własne i ustalania priorytetów. Więcej informacji o wpływie priorytetu atrybucję, znajdziesz w sekcji z przykładem określania priorytetów.Wyższa o

    wskazują wyższe priorytety.
  • Okna atrybucji instalacji i po instalacji (opcjonalnie): używane do: określać atrybucję dla zdarzeń po instalacji, opisane dalej na tej stronie.
  • Filtrowanie danych (opcjonalne): umożliwia selektywne filtrowanie niektórych reguł. i skuteczne ich ignorowanie. Więcej informacji: filtry reguł na tej stronie.
  • Klucze agregacji (opcjonalnie): określ segmentacji używany do raporty zbiorcze.

Opcjonalnie odpowiedź metadanych źródła atrybucji może zawierać dodatkowe dane w nagłówku Przekierowania raportowania atrybucji. Dane zawierają przekierowanie adresy URL, zezwolić wielu technikom reklamowym na zarejestrowanie żądania.

Przewodnik dla programistów zawiera przykłady, które pokazują, jak zaakceptuj rejestrację źródła.

Poniżej znajduje się przykładowy przepływ pracy:

  1. pakiet AdTech SDK wywołuje interfejs API, aby zainicjować rejestrację źródła atrybucji. określając identyfikator URI, który ma być wywoływany przez interfejs API:

    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, za pomocą jednego z następujących nagłówków:

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

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

  3. Serwer HTTPS tej technologii reklamowej odpowiada z nagłówkami zawierającymi:

    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 argumencie Attribution-Reporting-Redirect W tym przykładzie 2 adresy URL partnerów oferujących technologie reklamowe więc interfejs API wysyła jedno żądanie do https://adtechpartner1.example?their_ad_click_id=567 i jeszcze jedna prośba do: https://adtechpartner2.example?their_ad_click_id=890.

  5. Serwer HTTPS tej technologii reklamowej odpowiada z nagłówkami zawierającymi:

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

Zarejestrowane są 3 źródła atrybucji (kliknięcia) na podstawie widocznych w poprzednich krokach.

Rejestrowanie źródła atrybucji z WebView

WebView obsługuje przypadki użycia, w których aplikacja renderuje reklamę w komponencie WebView. Jest to obsługiwane przez komponent WebView bezpośrednio wywołujący registerSource() jako żądania w tle. To wywołanie wiąże źródło atrybucji z aplikacją zamiast punktu początkowego najwyższego poziomu. Rejestrowanie źródeł z umieszczonych treści internetowych w kontekście przeglądarki, zarówno wywołujące interfejs API, jak i aplikacje odpowiednio dostosować ustawienia. Patrz sekcja Rejestrowanie źródła atrybucji i aktywatora z WebView, w którym znajdziesz instrukcje dotyczące wywołujących interfejs API oraz Instrukcje znajdziesz w artykule Źródło atrybucji i rejestracja aktywatora z komponentu WebView. dla aplikacji.

Techniki reklamowe używają wspólnego kodu w internecie i komponencie WebView, więc WebView jest zgodny z HTTP 302. przekierowuje na platformę i przekazuje prawidłowe rejestracje. Nie planujemy obsługuje nagłówek Attribution-Reporting-Redirect w tym scenariuszu, ale skontaktuj się z nami, jeśli masz taki przypadek użycia.

Rejestrowanie reguły (konwersji)

Platformy technologii reklamowych mogą rejestrować reguły, takie jak instalacje czy konwersje. zdarzeń po instalacji za pomocą metody registerTrigger().

Metoda registerTrigger() oczekuje parametru Identyfikator URI aktywatora. Interfejs API wysyła do tego identyfikatora URI żądanie pobrania metadanych powiązanych z aktywatorem.

Interfejs API śledzi przekierowania. Odpowiedź serwera technologii reklamowych powinna zawierać tag HTTP nagłówek o nazwie Attribution-Reporting-Register-Trigger, który reprezentuje o co najmniej jednym zarejestrowanym aktywatorze. Treść nagłówka powinna być Zakodowany w formacie JSON oraz podaj te pola:

  • Dane reguły: dane do identyfikacji zdarzenia reguły (3 bity w przypadku kliknięć, 1 ). Musi być 64-bitową liczbą całkowitą ze znakiem w formacie ciągu znaków.
  • Priorytet reguły (opcjonalny): reprezentuje priorytet tej reguły. w porównaniu z innymi regułami dla tego samego źródła atrybucji. Musi być 64-bitowa. liczba całkowita ze znakiem w formacie ciągu znaków. Więcej informacji na temat priorytetu wpływa na raportowanie, zobacz sekcję z priorytetami.
  • Klucz deduplikacji (opcjonalny): używany do identyfikowania przypadków, w których reguła jest wielokrotnie rejestrowana przez tę samą platformę technologii reklamowych, to samo źródło atrybucji. Musi być 64-bitową liczbą całkowitą ze znakiem w formacie ciągu znaków.
  • Klucze agregacji (opcjonalnie): A lista słowników określająca klucze agregacji a które raporty agregujące powinny mieć zagregowaną wartość.
  • Wartości agregujące (opcjonalne): lista wartości, które w przypadku poszczególnych kluczy.
  • Filtry (opcjonalnie): służą do filtrowania selektywnego. lub danych wyzwalaczy. Więcej informacji: filtry reguł na tej stronie.

Opcjonalnie odpowiedź serwera technologii reklamowych może zawierać dodatkowe dane w kolumnie Nagłówek Attribution Reporting Redirects (Przekierowania raportowania atrybucji). Dane zawierają przekierowania, który zezwolić wielu technikom reklamowym na zarejestrowanie żądania.

Wielu techników reklamowych może zarejestrować to samo zdarzenie reguły za pomocą obu przekierowań w Attribution-Reporting-Redirect lub wiele wywołań funkcji Metoda registerTrigger(). Zalecamy użycie klucza deduplikacji. pozwalające uniknąć umieszczania w raportach zduplikowanych reguł w przypadku, gdy to samo AdTech zapewnia wiele odpowiedzi na to samo zdarzenie aktywujące. Więcej informacji o jak i kiedy używać klucza do usuwania duplikatów.

Przewodnik dla programistów zawiera przykłady, które pokazują, jak zaakceptuj rejestrację aktywatora.

Poniżej znajduje się przykładowy przepływ pracy:

  1. Pakiet AdTech SDK wywołuje interfejs API, aby zainicjować rejestrację za pomocą parametru wstępnie zarejestrowanego identyfikatora URI. Więcej informacji znajdziesz w artykule Zakładanie konta Piaskownicy prywatności. i informacjami o nich.

    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 technologii reklamowej odpowiada z nagłówkami zawierającymi:

    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 argumencie Attribution-Reporting-Redirect W tym przykładzie tylko jeden adres URL więc interfejs API wysyła żądanie do https://adtechpartner.example?app_install=567

  5. Serwer HTTPS tej technologii reklamowej odpowiada z nagłówkami zawierającymi:

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

    Zostały zarejestrowane 2 aktywatory na podstawie żądań z poprzednich kroków.

Funkcje atrybucji

W poniższych sekcjach znajdziesz informacje o dopasowaniu interfejsu Attribution Reporting API do źródeł atrybucji.

Zastosowano algorytm atrybucji z priorytetem źródła

Interfejs Attribution Reporting API wykorzystuje atrybucję priorytetową , aby dopasować regułę (konwersję) do źródła atrybucji.

Parametry priorytetu pozwalają dostosować atrybucję reguł źródła:

  • Możesz przypisać reguły do określonych zdarzeń reklamowych. Przykład: możesz skupić się na kliknięciach, a nie na wyświetleniach, na zdarzenia z konkretnych kampanii.
  • Możesz skonfigurować źródło i regułę atrybucji tak, aby, liczby żądań, więc istnieje większe prawdopodobieństwo, że będziesz otrzymywać raporty ważne dla Ciebie. Na przykład warto upewnić się, że elementy z możliwością określenia stawki konwersje lub konwersje o dużej wartości z większym prawdopodobieństwem pojawią się w tych raportów.

W przypadku, gdy wielu specjalistów od technologii reklamowych rejestruje źródło atrybucji, jak opisano poniżej, atrybucja ta odbywa się niezależnie dla z każdej technologii reklamowej. W przypadku każdej technologii reklamowej źródło atrybucji o najwyższym priorytecie jest powiązany ze zdarzeniem aktywującym. Jeśli istnieje wiele źródeł atrybucji z tym samym priorytetem API wybiera ostatnie zarejestrowane źródło atrybucji. Wszystkie inne, niezaznaczone źródła atrybucji, zostaną odrzucone. .

Filtry reguł

Rejestracja źródła i aktywatora obejmuje dodatkowe opcjonalne funkcje następujące:

  • Wybiórczo filtruj aktywatory, aby je ignorować.
  • Wybierz dane reguł dla raportów na poziomie zdarzenia opartych na danych źródłowych.
  • Zaznacz, aby wykluczyć regułę z raportów na poziomie zdarzenia.

Aby selektywnie filtrować reguły, technologia reklamowa może określać dane filtrowania, co obejmuje: kluczy i wartości podczas rejestracji źródła i wyzwalacza. Jeśli ten sam klucz to określony zarówno dla źródła, jak i dla wyzwalacza, to reguła będzie ignorowana, jeśli przecięcie zbiorów jest puste. Źródło może na przykład określać "product": ["1234"], gdzie product to klucz filtra, a 1234 to wartość. Jeśli filtr reguły jest ustawiona na "product": ["1111"], reguła jest ignorowana. W przypadku braku klucz filtra aktywatora pasujący do: product, filtry zostaną zignorowane.

Inny scenariusz, w którym platformy technologii reklamowych mogą zechcieć wybiórczo filtrować reguły jest wymuszanie krótszego okresu ważności. Po zarejestrowaniu się technika reklamowa może określać (w sekundach) okres ważności konwersji, w przypadku np. 7-dniowy okres ważności zostanie zdefiniowany jako: "_lookback_window": 604800 // 7d

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

Platformy technologii reklamowych mogą też wybierać dane reguł na podstawie danych zdarzeń źródłowych. Dla: przykład source_type jest automatycznie generowany przez interfejs API jako navigation lub event. Podczas rejestracji aktywatora można ustawić trigger_data jako jedną wartość w kolumnie "source_type": ["navigation"] i jako inną wartość dla pola "source_type": ["event"]

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

  • Element trigger_data nie jest określony.
  • Źródło i reguła określają ten sam klucz filtra, ale wartości nie są zgodne. Pamiętaj, że w tym przypadku reguła jest ignorowana zarówno na poziomie zdarzenia, do agregacji.

Atrybucja po instalacji

W niektórych przypadkach reguły po instalacji muszą być przypisane do elementu to samo źródło atrybucji, które przyczyniło się do instalacji, nawet jeśli zostały spełnione pozostałe warunki źródeł atrybucji, które wystąpiły niedawno.

Interfejs API obsługuje ten przypadek użycia, umożliwiając technikom reklamowym ustawienie wartości po instalacji okres atrybucji:

  • Podczas rejestrowania źródła atrybucji określ atrybucję instalacji okno, w którym spodziewana jest liczba instalacji (zwykle 2–7 dni, akceptowane od 1 do 30 dni). Podaj ten przedział czasu w sekundach.
  • Podczas rejestrowania źródła atrybucji określ atrybucję po instalacji okresu wyłączności, w którym powinny być powiązane ze źródłem atrybucji, które doprowadziło do instalacji (zwykle 7–30 dni, akceptowany zakres od 0 do 30 dni). Określ ten przedział czasu jako liczba sekund.
  • Interfejs Attribution Reporting API sprawdza, kiedy ma miejsce instalacja aplikacji. wewnętrznie przypisuje instalację do atrybucji z priorytetem źródła źródła. Instalacja nie jest jednak wysyłana do zespołu technicznego i nie jest uwzględniana platformy odpowiednie limity liczby żądań.
  • W przypadku każdej pobranej aplikacji dostępna jest weryfikacja instalacji aplikacji.
  • wszystkie przyszłe reguły, które wystąpią w oknie atrybucji po instalacji. są przypisywane do tego samego źródła atrybucji co zweryfikowana instalacja, o ile dane źródło atrybucji kwalifikuje się do wyświetlenia.

W przyszłości możemy rozszerzyć projekt o obsługę bardziej zaawansowanych modeli atrybucji.

W tabeli poniżej znajdziesz przykład wykorzystania technologii reklamowych po instalacji o pochodzeniu danych. Załóżmy, że wszystkie źródła i reguły atrybucji są rejestrowane przez ta sama sieć technologii reklamowych i wszystkie priorytety są takie same.

Zdarzenie Dzień, w którym wystąpiło zdarzenie Uwagi
Kliknij 1 1 install_attribution_window jest ustawiona na 172800 (2 dni), a post_install_exclusivity_window jest ustawiona na 864000 (10 dni)
Zweryfikowana instalacja 2 Interfejs API przypisuje wewnętrznie zweryfikowane instalacje, ale te instalacje nie są uznawane za aktywatory. W związku z tym żadne raporty nie są wysyłane na ten adres .
Aktywator 1 (pierwsze uruchomienie) 2 Pierwsza reguła została zarejestrowana przez technikę reklamową. W tym przykładzie jest to pierwsze uruchomienie, ale może to być dowolny typ reguły.
Przypisane do kliknięcia 1 (odpowiada atrybucji zweryfikowanej instalacji).
Kliknij 2 4 Stosuje te same wartości dla argumentu install_attribution_window oraz post_install_exclusivity_window. jako kliknięcie 1
Aktywator 2 (po instalacji) 5 Druga reguła zarejestrowana przez zespół technologii reklamowej. W tym przykładzie jest to konwersji po instalacji, np. zakupu.
Przypisane do kliknięcia 1 (odpowiada atrybucji zweryfikowanej instalacji).
Kliknięcie 2 zostało odrzucone i nie kwalifikuje się do przyszłej atrybucji.

Na liście poniżej znajdziesz dodatkowe uwagi dotyczące działania po instalacji źródło:

  • Jeśli zweryfikowana instalacja nie nastąpi w ciągu podanej liczby dni do install_attribution_window, atrybucja po instalacji nie jest stosowana.
  • Zweryfikowane instalacje nie są rejestrowane przez technologie reklamowe i nie są wysyłane w raportów. Nie są one wliczane do limitów liczby żądań związanych z technologią reklamową. Zweryfikowane instalacje są używane tylko do zidentyfikowania źródła atrybucji, któremu przypisywany jest atrybut instalacji.
  • W przykładzie z poprzedniej tabeli reguły 1 i 2 odpowiadają konwersji polegającej na pierwszym uruchomieniu i konwersji po instalacji. Technologie reklamowe platformy mogą rejestrować dowolny typ aktywatora. Innymi słowy, nie muszą to być reguły powiązane z pierwszym uruchomieniem.
  • Jeśli po post_install_exclusivity_window zarejestrowanych jest więcej aktywatorów kliknij 1, ale nadal kwalifikuje się do atrybucji, o ile nie wygasła i nie osiągnęła swojego limitu liczby żądań.
    • Kliknięcie 1 może nadal zostać utracone lub odrzucone, jeśli ma wyższy priorytet .
  • Jeśli aplikacja reklamodawcy zostanie odinstalowana i ponownie zainstalowana, ponowna instalacja będzie liczona jako nowa zweryfikowana instalacja.
  • Jeśli kliknięcie 1 było zdarzeniem wyświetlenia, zarówno „pierwsze uruchomienie”, i po instalacji które nadal są do niej przypisane. Interfejs API ogranicza atrybucję do jednego na wyświetlenie, z wyjątkiem atrybucji po instalacji, gdzie do dozwolone są 2 reguły na widok. W przypadku atrybucji po instalacji parametr technologia reklamowa może otrzymywać 2 różne okresy raportowania (na 2 dni lub na poziomie źródła, (wygaśnięcie).

Obsługiwane są wszystkie kombinacje ścieżek reguł aplikacji i witryn

Interfejs Attribution Reporting API umożliwia atrybucję następujących ścieżek reguł na jednym urządzeniu z Androidem:

  • App-to-app: użytkownik widzi reklamę w aplikacji i dokonuje konwersji lub inną zainstalowaną aplikację.
  • App-to-web: użytkownik widzi reklamę w aplikacji, a potem realizuje konwersję w aplikacji mobilnej lub przeglądarki aplikacji.
  • Web-to-app: użytkownik widzi reklamę w przeglądarce mobilnej lub aplikacji, a potem dokonuje konwersji w aplikacji.
  • Web-to-web: użytkownik widzi reklamę w przeglądarce mobilnej lub 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 dostępnych w internecie, takich jak: funkcję podobną do Attribution Reporting API w ramach Piaskownicy prywatności w internecie, który może wywoływać interfejsy API Androida, aby umożliwić atrybucję w aplikacjach i na stronach internetowych.

Dowiedz się więcej o zmianach, które muszą wprowadzić w swojej aplikacji technologie reklamowe i aplikacje, ścieżki aktywatorów dla pomiar w aplikacjach i witrynach.

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

Jedno źródło atrybucji może prowadzić do wielu reguł. Na przykład plik proces zakupu może obejmować „instalację aplikacji” wyzwalacz, co najmniej jeden element „dodaj do koszyka” reguły oraz „zakup”. . Każda reguła jest przypisana do co najmniej jednego źródeł atrybucji według algorytm atrybucji z priorytetem źródła, opisane dalej na tej stronie.

Istnieją limity liczby reguł, które można przypisać do pojedynczej atrybucji source; Więcej informacji znajdziesz w sekcji Wyświetlanie danych pomiarowych w raportów atrybucji. W sytuacjach, gdy jest większa niż te limity, warto wprowadzić priorytety które pozwalają generować najbardziej wartościowe wyzwalacze. Na przykład deweloperzy technologie reklamowe mogą traktować priorytetowo „zakup” reguły nadrzędne względem funkcji „add-to-cart” wyzwalaczy.

Aby obsługiwać tę logikę, można ustawić w aktywatorze osobne pole priorytetu, reguły o najwyższym priorytecie są wybierane przed zastosowaniem limitów. dla danego okna raportowania.

Zezwalaj wielu technikom reklamowym na rejestrowanie źródeł lub reguł atrybucji

Zwykle raporty atrybucji otrzymują więcej niż 1 technologia reklamowa, aby przeprowadzić deduplikację danych międzysieciowych. Dlatego interfejs API umożliwia technologii reklamowych, aby zarejestrować to samo źródło lub tę samą regułę atrybucji. Technologia reklamowa musi zarejestrują źródła i reguły atrybucji, aby otrzymywać wywołania zwrotne API, a atrybucja odbywa się wśród źródeł i reguł atrybucji, technologii reklamowych zarejestrowanych w interfejsie API.

Reklamodawcy, którzy chcą korzystać z usług firmy zewnętrznej do realizowania konwersji w wielu sieciach może kontynuować deduplikację, stosując technikę podobną do tej:

  • Skonfigurowanie własnego serwera do rejestrowania i odbierania raportów przez interfejs API.
  • Dalsze korzystanie z usług partnera świadczącego usługi pomiaru ruchu mobilnego.

Ź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 zapewnić dodatkowe pole Attribution-Reporting-Redirect w odpowiedzi, które reprezentuje zestaw adresów URL przekierowania do technologii reklamowej partnera.
  2. Interfejs API wywołuje następnie przekierowania, aby źródło atrybucji można było zarejestrowany przez partnera ds. technologii reklamowych.

W sekcji Attribution-Reporting-Redirect, a technologie reklamowe partnerów nie mogą określić własne pole Attribution-Reporting-Redirect.

Interfejs API zezwala też różnym technikom reklamowym na wywołanie registerSource().

Reguły

W przypadku rejestracji aktywatorów firmy zewnętrzne są obsługiwane w podobny sposób: w zakresie technologii reklamowych. mogą użyć dodatkowego pola Attribution-Reporting-Redirect lub każdy z nich może wywoływać metodę registerTrigger().

Gdy reklamodawca rejestruje to samo zdarzenie reguły za pomocą kilku technologii reklamowych, klucz deduplikacji. Klucz deduplikacji służy do wskazywania te powtarzające się zgłoszenia tego samego zdarzenia zarejestrowanego przez tę samą technologię reklamową platformy. Na przykład pakiet SDK może wywoływać interfejs API bezpośrednio do zarejestrować regułę, a jej adres URL w polu przekierowania innej technologii reklamowej . Jeśli nie podano klucza deduplikacji, mogą zostać zgłoszone zduplikowane aktywatory do każdej technologii reklamowej.

Obsługa zduplikowanych aktywatorów

Technologia reklamowa może zarejestrować tę samą regułę wielokrotnie za pomocą interfejsu API. Scenarios należy uwzględnić następujące elementy:

  • Użytkownik wykonuje to samo działanie (regułę) wiele razy. Przykład: użytkownik przegląda ten sam produkt wiele razy w jednym raporcie. okno.
  • Aplikacja reklamodawcy używa do pomiaru konwersji wielu pakietów SDK, wszystkie przekierowują do tej samej technologii reklamowej. Na przykład aplikacja reklamodawcy korzysta z dwóch partnerów świadczących usługi pomiarowe, MMP 1 i MMP 2. Obie platformy MMP przekierowują do technologii reklamowej nr 3. W przypadku wywołania reguły obie platformy MMP rejestrują ją w ramach atrybucji. Interfejs API do raportowania. Technologia reklamowa 3 otrzymuje 2 oddzielne przekierowania – jedno z adresu MMP nr 1 i 1 z MMP 2 – w przypadku tej samej reguły.

Istnieje kilka sposobów na pominięcie raportów na poziomie zdarzenia dotyczących: zduplikowanych reguł, by zmniejszyć prawdopodobieństwo przekroczenia limitów stawek stosowanych w raportach na poziomie zdarzenia. Zalecanym sposobem jest użycie klucza do deduplikacji.

Zalecana metoda: klucz deduplikacji

Zalecana metoda to przekazywanie przez aplikację reklamodawcy unikalnego usuwania duplikatów technologii reklamowych i pakietów SDK używanych do pomiaru konwersji. Gdy gdy następuje konwersja, aplikacja przekazuje klucz deduplikacji do technologii reklamowych lub pakietów SDK. Technologie reklamowe lub pakiety SDK przekazują klucz deduplikacji do przekierowań. za pomocą parametru w adresach URL określonych w polu Attribution-Reporting-Redirect.

Technologie reklamowe mogą zarejestrować tylko pierwszą regułę z danym zdarzeniem klucza deduplikacji albo zarejestrować wiele wyzwalaczy lub wszystkie aktywatory. Techniki reklamowe mogą określić deduplication_key podczas rejestrowania duplikatu wyzwalaczy.

Jeśli technika reklamowa zarejestruje wiele reguł z tym samym kluczem deduplikacji i w przypadku przypisanego źródła, na poziomie zdarzenia wysyłana jest tylko pierwsza zarejestrowana reguła raportów. Zduplikowane aktywatory są nadal wysyłane w zaszyfrowanych raportach zbiorczych.

Metoda alternatywna: technologie reklamowe uzgadniają typy reguł reklamowych dla poszczególnych reklamodawców

W sytuacjach, gdy specjaliści ds. technologii reklamowych nie chcą używać klucza do usuwania duplikatów aplikacja reklamodawcy nie może przekazać klucza deduplikacji, istnieje opcja alternatywna. Wszystkie technologie reklamowe, które mierzą konwersje dla danego reklamodawcy, muszą współpracować , aby zdefiniować różne typy reguł dla każdego reklamodawcy.

Technologie reklamowe, które inicjują wywołanie rejestracji (np. pakiety SDK), zawierają parametr w adresach URL określonych w funkcji Attribution-Reporting-Redirect, na przykład duplicate_trigger_id Ten parametr duplicate_trigger_id może zawierać takie jak nazwa pakietu SDK i typ reguły danego reklamodawcy. Technologie reklamowe mogą wysyłać podzbiór tych zduplikowanych reguł do raportów na poziomie zdarzenia. Specjaliści ds. technologii reklamowych mogą też uwzględnić w kluczach agregacji ten atrybut duplicate_trigger_id.

Przykład atrybucji międzysieciowej

W przykładzie w tej sekcji reklamodawca używa 2 wyświetlanych reklam platform technicznych (Ad tech A i Ad tech B) oraz jednego partnera świadczącego usługi pomiaru (MMP).

Przed rozpoczęciem korzystania z narzędzia Technologia reklamowa A, Technologia reklamowa B i MMP muszą przejść proces rejestracji. Attribution Reporting API. Zapoznaj się z sekcją Rejestrowanie konta Piaskownicy prywatności znajdziesz więcej informacji.

Na liście poniżej przedstawiamy hipotetyczny zestaw działań użytkownika, które między poszczególnymi dniami oraz jak interfejs Attribution Reporting API obsługuje te działania w kontekście technologii reklamowej A, technologii reklamowej B i MMP:

Dzień 1: użytkownik klika reklamę wyświetlaną przez AdTech A

Technologia reklamowa A wywołuje metodę registerSource() za pomocą identyfikatora URI. Interfejs API wysyła żądanie do identyfikator URI, a kliknięcie jest rejestrowane przy użyciu metadanych z biblioteki AdTech A odpowiedź serwera.

Technologia reklamowa A zawiera też identyfikator URI platformy MMP w pliku Attribution-Reporting-Redirect nagłówek. Interfejs API wysyła żądanie do identyfikatora URI platformy MMP, po czym kliknięcie zostaje zarejestrowane z metadanymi z odpowiedzi serwera MMP.

Dzień 2: użytkownik klika reklamę wyświetlaną przez AdTech B

Technologia reklamowa B wywołuje funkcję registerSource() za pomocą identyfikatora URI. Interfejs API wysyła żądanie do identyfikator URI, a kliknięcie jest rejestrowane przy użyciu metadanych z biblioteki Techniki B odpowiedź serwera.

Podobnie jak technologia reklamowa A, technologia reklamowa B również uwzględnia identyfikator URI MMP w Nagłówek Attribution-Reporting-Redirect. Interfejs API wysyła żądanie do platformy MMP identyfikator URI i kliknięcie jest rejestrowane z metadanymi z serwera MMP, .

Dzień 3. Użytkownik ogląda reklamę wyświetloną przez technologię reklamową A

Interfejs API reaguje w taki sam sposób jak pierwszego dnia, z tym że zarejestrowany w usługach AdTech A i MMP.

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

MMP wywołuje metodę registerTrigger() za pomocą identyfikatora URI. Interfejs API wysyła żądanie do a konwersja zostanie zarejestrowana z metadanymi z serwera MMP. .

MMP zawiera też identyfikatory URI technologii reklamowej A i Technologii reklamowej B w Nagłówek Attribution-Reporting-Redirect. Interfejs API wysyła żądania do technologii reklamowych A. i serwerach AdTech B, a konwersja jest odpowiednio rejestrowana przez metadanych z odpowiedzi serwera.

Poniższy diagram przedstawia proces opisany na poprzedniej liście:

Przykład działania Attribution Reporting API reaguje na serię działań użytkownika.

Atrybucja działa w ten sposób:

  • Technologia reklamowa A ustawia priorytet kliknięć względem wyświetleń i dlatego otrzymuje instalacja przypisana do kliknięcia pierwszego dnia.
  • Technologia reklamowa B uzyskuje instalację przypisywaną drugiego dnia.
  • MMP ustawia priorytet kliknięć nad liczbą wyświetleń i uzyskuje instalacje przypisanego kliknięciu drugiego dnia. kliknięcia drugiego dnia mają najwyższy priorytet, najnowsze zdarzenie reklamowe.

Atrybucja międzysieciowa bez przekierowań

Zalecamy korzystanie z przekierowań, aby umożliwić rejestrację wielu technikom reklamowym. źródła i reguły atrybucji, zdajemy sobie sprawę, że w niektórych sytuacjach ponieważ używanie przekierowań jest niemożliwe. W tej sekcji znajdziesz szczegółowe informacje na temat atrybucja międzysieciowa bez przekierowań.

Przepływ wysokiego poziomu

  1. Podczas rejestracji źródła sieć technologii reklamowej udostępnia źródło. kluczy agregacji.
  2. Po rejestracji reguły reklamodawca lub partner świadczący usługi pomiaru wybiera elementów kluczowych po stronie źródła i określa ich konfigurację atrybucji.
  3. Atrybucja jest oparta na konfiguracji atrybucji, udostępnionych kluczach i wszelkich źródłach zarejestrowane przez tego reklamodawcę lub partnera świadczącego usługi pomiaru. (np. z innej sieci technologii reklamowej, która ma włączone przekierowania).
  4. Jeśli reguła jest przypisana do źródła z reklamy wyświetlającej się bez przekierowania reklamodawcy lub partnera świadczącego usługi pomiaru mogą otrzymać dane zbiorcze, który łączy źródło i kluczowe elementy określone w kroku 2.

Rejestracja źródła

Po rejestracji źródła sieć technologii reklamowej może udostępnić dane źródłowych kluczy agregacji lub podzbioru ich źródłowych kluczy agregacji zamiast (przekierowanie). Technologia reklamowa nie jest wymagana do użycia tych źródeł kluczy we własnych raportach zbiorczych i mogą deklarować je wyłącznie w imieniu reklamodawcę lub partnera świadczącego usługi pomiaru.

Udostępnione klucze agregacji są dostępne dla każdej technologii reklamowej, która rejestruje regułę dla temu samemu reklamodawcy. Jednak to zależy od technologii, która wyświetla reklamy, i od reguły technologii reklamowej do pomiarów, aby współpracować nad rodzajem kluczy agregacji, ich nazw i dekodowania kluczy do czytelnych wymiarów.

Rejestracja aktywatora

Po rejestracji aktywacji technologia reklam pomiarowych wybiera klucz po stronie źródła elementów, które mają być stosowane do każdego kluczowego elementu reguły, w tym elementów udostępnianych przez wyświetlanie reklam technika.

Dodatkowo technologia reklam pomiarowych musi określić kaskadę logikę atrybucji za pomocą nowego wywołania interfejsu API konfiguracji atrybucji. W tej konfiguracji technologia reklamowa może określać priorytet i wygaśnięcie źródła oraz filtry dla źródeł, które nie mają wglądu w nie (np. źródła, które nie korzystały z przekierowań).

Atrybucja

Interfejs Attribution Reporting API zapewnia skuteczność ostatniej interakcji z priorytetem źródła atrybucja technologii reklamowych na podstawie ich konfiguracji atrybucji, udostępnione klucze i zarejestrowane źródła. Na przykład:

  • Użytkownik kliknął reklamy wyświetlane przez technologie reklamowe A, B, C i D. Wtedy użytkownik zainstalował aplikację reklamodawcy, która korzysta z usług partnera ds. technologii reklamowych zajmujących się pomiarami (MMP).
  • Technologia reklamowa A przekierowuje swoje źródła do platformy MMP.
  • Technologie reklamowe B i C nie przekierowują, ale udostępniają klucze agregujące.
  • AdTech D nie przekierowuje ani nie udostępnia kluczy agregacji.

MMP rejestruje źródło z Techniki reklamowej A i definiuje konfigurację atrybucji która obejmuje technologię reklamową B i technologię reklamową D.

Atrybucja MMP obejmuje teraz:

  • Technologia reklamowa A, ponieważ MMP zarejestrował źródło z przekierowania tej technologii reklamowej.
  • Technologia reklamowa B, ponieważ udostępnia klucze technologii reklamowych B, a MMP uwzględnił je w swoich wynikach. konfiguracji atrybucji.

Atrybucja w MMP nie uwzględnia:

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

Debugowanie

Aby umożliwić debugowanie atrybucji międzysieciowej bez przekierowań: dostępne jest dodatkowe pole shared_debug_key, które można skonfigurować przez techników reklamowych rejestracji źródła. Jeśli została ustawiona w pierwotnej rejestracji źródła, zostanie ona również ustawiona w odpowiednim źródle derywowanym jako debug_key podczas rejestracji aktywatora do atrybucji międzysieciowej bez przekierowań. Ten klucz debugowania jest dołączony jako source_debug_key w raportach zbiorczych i zdarzeniach.

Ta funkcja debugowania będzie obsługiwana tylko w przypadku atrybucji międzysieciowej bez w tych sytuacjach:

  • Pomiar konwersji z aplikacji do aplikacji, gdzie AdId to dozwolone
  • Pomiar konwersji z aplikacji do witryny w przypadku, gdy identyfikator AdId jest dozwolony i dopasowywany zarówno źródła aplikacji, jak i reguły witryny,
  • Pomiar liczby stron internetowych w sieci (w ramach tego samego przeglądarka) gdy ar_debug występuje zarówno w źródle, jak i w aktywatorze

Wykrywanie klucza na potrzeby atrybucji międzysieciowej bez przekierowań

Kluczowe odkrywanie ma usprawnić sposób, w jaki technologie reklamowe (zwykle MMP) wdrażają jego konfigurację atrybucji na potrzeby atrybucji międzysieciowej, lub kilku techników wyświetlania reklam korzysta ze wspólnych kluczy agregacji (jak opisano w Atrybucja międzysieciowa bez przekierowań powyżej).

Gdy MMP wysyła zapytania do usługi agregacji, aby wygenerować raporty podsumowujące dla: kampanii zawierających źródła pochodne, usługa agregacji wymaga od MMP określ listę możliwych kluczy jako dane wejściowe zadania agregacji. W niektórych lista potencjalnych kluczy agregacji źródeł może być bardzo długa lub nieznane. Obszerne listy możliwych klawiszy trudno jest śledzić, a dodatkowo że ich przetwarzanie może być dość skomplikowane i kosztowne. Weź pod uwagę te kwestie Przykłady:

  • Lista wszystkich możliwych kluczy jest długa:
    • Sieć reklamowa wyświetlająca reklamy realizuje złożoną inicjatywę pozyskiwania użytkowników z 20 kampanii, z których każda zawiera 10 grup reklam, z 5 kreacjami, które są odświeżane 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 wydawców nie jest znana na początku kampanii.
    • Reklamodawca działa w wielu sieciach reklamowych, które nieprzekierowywanie do MMP w momencie rejestracji źródła; każda wyświetlana reklama ma inną strukturę kluczy i wartości, które mogą nie być udostępnione z wyprzedzeniem organizacji MMP.

Wraz z wprowadzeniem kluczowych funkcji:

  • Usługa agregacji nie wymaga już pełnego wyliczania możliwych kluczy agregacji.
  • Zamiast podawać pełną listę możliwych kluczy, MMP może utworzyć pusty (lub częściowo pusty) zestaw kluczy i ustawić próg, tak aby tylko (niezadeklarowane wstępnie) klucze o wartościach przekraczających próg są uwzględniane w dane wyjściowe.
  • MMP otrzymuje raport podsumowujący, który zawiera zaszumione wartości dla kluczy, które mają wartości udziału powyżej ustalonego progu. Raport może też zawierać informacje klucze, z którymi nie są powiązane żadne działania użytkowników i są czyste.
  • MMP używa pola x_network_bit_mapping w rejestracji aktywującej do: określić, która technologia reklamowa odpowiada danemu kluczowi.
  • Dzięki temu MMP może skontaktować się z odpowiednią technologią wyświetlania reklam, aby zrozumieć wartości. w kluczu źródłowym.

Podsumowując, wykrywanie kluczy umożliwia MMP uzyskiwanie kluczy agregacji bez Poznanie ich z wyprzedzeniem i unikanie przetwarzania dużej liczby kluczy źródłowych kosztem dodatkowego szumu.

Wyświetlanie danych pomiarowych w raportach atrybucji

Interfejs Attribution Reporting API obsługuje następujące typy raportów bardziej szczegółowo na tej stronie:

  • Raporty na poziomie zdarzenia odnoszą się do źródło atrybucji (kliknięcie lub wyświetlenie) z ograniczoną ilością wysokiej jakości danych wyzwalacza.
  • Raporty zbiorcze nie muszą być ze sobą powiązane. z określonym źródłem atrybucji. Raporty te zawierają bogatsze informacje, są bardziej precyzyjne niż w raportach na poziomie zdarzenia, ale dotyczą tylko w postaci zbiorczej.

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

Raporty na poziomie zdarzenia

Po przypisaniu reguły do źródła atrybucji raport na poziomie zdarzenia generowane i przechowywane na urządzeniu, dopóki nie będzie można go przesłać z powrotem do wywołania zwrotnego w trakcie jednego z przedziały czasu wysyłania raportów, omówiono to dokładniej w dalszej części tej strony.

Raporty na poziomie zdarzenia są przydatne, gdy potrzebnych jest bardzo mało informacji . Dane aktywatora na poziomie zdarzenia są ograniczone do 3 bitów danych reguły w przypadku kliknięć, co oznacza, że do reguły można przypisać jedną z ośmiu kategorii, liczbę wyświetleń. Raporty na poziomie zdarzenia nie obsługują też kodowania wysokiej jakości dane po stronie reguły, np. konkretna cena lub czas reguły. Atrybucja odbywa się na jednym urządzeniu, więc nie można przypisywać danych na różne urządzenia. w raportach na poziomie zdarzenia.

Raport na poziomie zdarzenia zawiera takie informacje jak:

  • Miejsce docelowe: nazwa pakietu aplikacji reklamodawcy lub eTLD+1, gdzie reguła jest uruchamiana. miało miejsce
  • Attribution Source ID (Identyfikator źródła atrybucji): ten sam identyfikator źródła atrybucji, który był używany w przypadku: rejestrowanie źródła atrybucji
  • Typ reguły: 1 lub 3 bity danych reguły o niskiej jakości, w zależności od typ źródła atrybucji

Mechanizmy chroniące prywatność stosowane do wszystkich raportów

W przypadku priorytetów dotyczących źródeł atrybucji stosowane są podane niżej limity i wyzwalacze.

Ograniczenia liczby technologii reklamowych

Liczba techników reklamowych, które mogą rejestrować lub otrzymywać raporty, są ograniczone z poziomu interfejsu API z aktualną propozycją:

  • 100 technologii reklamowych ze źródłami atrybucji na {źródłową aplikację, aplikację docelową, 30 days, device}.
  • 10 technologii reklamowych z przypisanymi regułami na {źródłową aplikację, aplikację docelową, 30 days, device}.
  • 20 specjalistów technicznych może zarejestrować 1 źródło atrybucji lub regułę (przy użyciu Attribution-Reporting-Redirect).

Limity liczby niepowtarzalnych miejsc docelowych

Ograniczenia te utrudniają specjalistom ds. technologii reklamowych łączenie się, wysyłając zapytanie jak duża liczba aplikacji do poznania sposobu korzystania z aplikacji przez danego użytkownika.

  • We wszystkich zarejestrowanych źródłach i technikach reklamowych interfejs API nie obsługuje już ponad 200 unikalnych miejsc docelowych na aplikację źródłową na minutę.
  • We wszystkich zarejestrowanych dla jednej technologii reklamowej interfejs API obsługuje maksymalnie 50 unikalnych miejsca docelowe na aplikację źródłową na minutę. Ten limit uniemożliwia jednej technologii reklamowej przez wykorzystanie całego budżetu podanego wcześniej limitu stawek.

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

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

Platforma technologii reklamowych może rejestrować źródła tylko z jednego źródła w aplikacji wydawcy, na danym urządzeniu, w tym samym dniu. Ten limit liczby żądań uniemożliwia technikom reklamowym korzystanie z wielu źródeł raportowania w celu uzyskania dostępu do dodatkowych na ochronę prywatności.

Rozważ ten scenariusz, w którym jedna technologia reklamowa chce używać wielu źródeł raportowania, aby rejestrować źródła w aplikacji wydawcy na 1 urządzeniu.

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

Drugie źródło, czyli źródło raportowania 2 dla technologii reklamowych A, zostanie odrzucone przez API. Źródło raportowania 2 AdTech A nie byłaby w stanie zarejestrować na tym samym urządzeniu w aplikacji B aż do następnego dnia.

Limity czasu oczekiwania i częstotliwości

Aby ograniczyć wyciek tożsamości użytkownika między {source, miejscem docelowym} API ogranicza ilość wszystkich informacji wysyłanych w danym czasie dla użytkownika.

Obecna propozycja polega na ograniczeniu każdej technologii reklamowej do 100 przypisanych reguł na każdą {źródłowa aplikacja, aplikacja docelowa, 30 dni, urządzenie}.

Liczba unikalnych miejsc docelowych

Interfejs API ogranicza liczbę miejsc docelowych, które technika reklamowa może zmierzyć. Im niższy limit, tym trudniej technologii reklamowej wykorzystać interfejs API, aby do pomiaru aktywności użytkowników związanej z przeglądaniem, która nie jest powiązana z wyświetlanymi reklamami.

Obecna propozycja polega na ograniczeniu każdej technologii reklamowej do 100 różnych miejsc docelowych niewygasłe źródła na aplikację źródłową.

Mechanizmy chroniące prywatność stosowane w raportach na poziomie zdarzenia

Ograniczona wierność danych aktywatora

Interfejs API udostępnia 1 bit dla reguł związanych z wyświetlaniem i 3 bity dla kliknięć wyzwalaczy. Źródła atrybucji nadal obsługują pełne 64 bity metadanych.

Należy ocenić, czy i jak ograniczać informacje wyrażone w regułach więc korzystają z ograniczonej liczby bitów dostępnych w raportach na poziomie zdarzenia.

Struktura szumu dotyczącego prywatności różnicowej

Celem tego interfejsu API jest umożliwienie pomiarów na poziomie zdarzenia w celu dostosowania do wymagań związanych z prywatnością różnicową przez wykorzystanie w odpowiedzi k-losowych odpowiedzi do wygenerowania zaszumione dane wyjściowe dla każdego zdarzenia źródłowego.

Szum jest stosowany do określania, czy zdarzenie źródła atrybucji jest raportowane zgodnie z prawdą. Źródło atrybucji jest zarejestrowane na urządzeniu z prawdopodobieństwem $ 1-p $, które źródło atrybucji jest rejestrowane jak zwykle, a z prawdopodobieństwem $ p $, że urządzenie losowo wybiera spośród wszystkich możliwych stanów wyjściowych interfejsu API (w tym w ogóle niczego nie zgłosić lub zgłosić kilka fałszywych zgłoszeń).

Odpowiedzią k-losową jest algorytm, w którym różnicowa jest wartość ypsilon prywatne, jeśli jest spełnione to równanie:

\[ p = \frac{k}{k + e^ε - 1} \]

W przypadku niskich wartości · rzeczywista wartość wyjściowa jest chroniona przez składnię k-randomizowaną reagowania na nie. Dokładne parametry szumu są w trakcie opracowywania i podlegają i wprowadzimy zmiany na podstawie opinii użytkowników, w związku z czym obecnie proponujemy:

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

Limity dostępnych reguł (konwersji)

Istnieją limity liczby reguł na źródło atrybucji. aktualna propozycja następujących dokumentów:

  • 1–2 reguły dla źródeł atrybucji wyświetleń reklamy (2 reguły dostępne tylko w w przypadku atrybucji po instalacji)
  • 3 reguły źródeł atrybucji reklam kliknięć
.

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

Raporty na poziomie zdarzenia dotyczące źródeł atrybucji wyświetleń reklamy są wysyłane godzinę po wygasa. Tę datę ważności możesz skonfigurować, ale nie może ona być mniejsza niż 1 lub ponad 30 dni. Jeśli 2 reguły są przypisane do wyświetlenia reklamy źródła atrybucji (za pomocą atrybucji po instalacji), powinny być wysyłane w okresach raportowania określonych poniżej.

W przypadku źródeł atrybucji kliknięć reklamy nie można konfigurować raportów na poziomie zdarzenia. są wysyłane przed wygaśnięciem źródła lub po jego wygaśnięciu, w określonych momentach względnych do daty rejestracji źródła. Czas upływający między źródłem atrybucji a jest dzielony na wiele okien raportowania. Każde okno raportowania ma termin (od czasu źródła atrybucji). Po zakończeniu każdego raportu urządzenie zbiera wszystkie wyzwalacze, które wystąpiły od momentu poprzedniego okna raportowania i wyśle zaplanowany raport. Interfejs API obsługuje w tych oknach raportowania:

  • 2 dni: urządzenie zbiera wszystkie wyzwalacze, które wystąpiły maksymalnie przez 2 dni. dni po zarejestrowaniu źródła atrybucji. Raport jest wysyłany po 2 dniach i godzinę po zarejestrowaniu źródła atrybucji.
  • 7 dni: urządzenie zbiera wszystkie aktywatory, które wystąpiły dłużej niż 2 dni. ale nie później niż 7 dni od zarejestrowania źródła atrybucji. Raport jest wysyłany 7 dni i 1 godzinę po tym, jak źródło atrybucji zostanie zarejestrowano.
  • Niestandardowy okres zdefiniowany przez parametr „expiry” atrybutu źródła danych o atrybucji. Raport jest wysyłany po upływie godziny od określonego czasu wygaśnięcia obecnie się znajdujesz. Ta wartość nie może być mniejsza niż 1 dzień ani dłuższa niż 30 dni.
.

Elastyczna konfiguracja na poziomie zdarzenia

Domyślna konfiguracja raportowania na poziomie zdarzenia jest zalecana dla techników reklamowych od razu po rozpoczęciu testów praktycznych, ale nie jest idealnym rozwiązaniem w każdym przypadku przypadków. Interfejs Attribution Reporting API będzie obsługiwać opcjonalne i bardziej elastyczne funkcje pozwala technikom reklamowym uzyskać większą kontrolę nad strukturą swoje raporty na poziomie zdarzenia i są w stanie maksymalnie wykorzystać te dane.

Ta dodatkowa elastyczność zostanie wprowadzona w raportach atrybucji Interfejs API składa się z dwóch etapów:

  • Etap 1. Elastyczne konfigurowanie na poziomie zdarzenia Lite
    • Ta wersja stanowi podzbiór wszystkich funkcji i można ją używane niezależnie od etapu 2.
  • Etap 2. Pełna wersja elastycznej konfiguracji na poziomie zdarzenia

Etap 1 (poziom zdarzenia elastycznego Lite) można wykorzystać do:

  • Aby zmienić częstotliwość generowania raportów, określ liczbę okien raportowania.
  • Zróżnicuj liczbę atrybucji na rejestrację źródła
  • Ogranicz ilość całkowitego szumu, zmniejszając powyższe parametry
  • Skonfiguruj okna raportowania zamiast używać domyślnych ustawień

Etap 2 (W pełni elastyczny poziom zdarzenia) można wykorzystać do wykonania wszystkich możliwości w fazie 1 oraz:

  • Zmieniaj moc zbioru danych reguły w raporcie
  • Ogranicz ilość całkowitego szumu, zmniejszając moc zbioru danych reguły

Zmniejszenie jednego wymiaru konfiguracji domyślnej umożliwia technologii reklamowej zwiększyć inny wymiar. Z kolei łączna ilość szumu w zdarzeniu można zmniejszyć przez zmniejszenie netto tych parametrów.

Oprócz dynamicznego ustawiania poziomu szumu na podstawie wybranej technologii reklamowej , zostaną wprowadzone pewne limity parametrów, aby uniknąć dużych obliczeń koszty i konfiguracje ze zbyt dużą liczbą stanów wyjściowych (gdzie szum zwiększy się znacznie obniżył się). Oto przykładowy zestaw ograniczeń. Zachęcamy do przesyłania opinii na [propozycja projektu][50]:

  • Maksymalnie 20 raportów łącznie (globalnie i na dane aktywatora)
  • Maksymalnie 5 możliwych okien raportowania na dane aktywatora
  • Maksymalnie 32 moc zbioru danych aktywatora (nie dotyczy fazy 1. Lite Elastyczny poziom zdarzenia)

Pamiętaj, że gdy technicy reklamowe zaczną korzystać z tej funkcji, stosowanie wartości ekstrema może powodować dużą ilość szumu lub nierejestrację, jeśli poziom prywatności jest nie spełniono.

Raporty agregowane

Aby korzystać z raportów agregowanych, musisz skonfigurować swoje konto w chmurze zacznij otrzymywać raporty agregowane.

Raporty agregowane pozwalają uzyskać bardziej precyzyjne dane aktywujące z urządzenia wykracza poza możliwości raportów na poziomie zdarzenia. Te dane o wyższej dokładności można poznać tylko w ramach zagregowanych i nie są powiązane z konkretnym wyzwalaczem lub użytkownikiem. Klucze agregacji mogą mieć maksymalnie 128 danych. Umożliwia to agregowanie raportów na potrzeby w następujący sposób:

  • Raporty dotyczące wartości reguł, takich jak przychody
  • Obsługa większej liczby typów aktywatorów

Raporty agregowane używają tego samego priorytetu źródła jak raporty na poziomie zdarzenia, ale obsługują więcej konwersji po kliknięciu lub wyświetleniu.

ogólny wygląd interfejsu Attribution Reporting API, który przygotowuje i wysyła dane; na tym diagramie widać raporty do zagregowania:

  1. Urządzenie wysyła do zespołu technicznego reklam zaszyfrowane raporty zbiorcze. W technologie reklamowe nie mogą korzystać z tych raportów bezpośrednio.
  2. Technologia reklamowa wysyła do usługi agregacji grupę raportów agregowanych. do agregacji.
  3. Usługa agregacji odczytuje grupę raportów agregowanych, odszyfrowuje agreguje je.
  4. Ostateczne dane zbiorcze są wysyłane z powrotem do technologii reklamowej w raport podsumowujący
.
Proces używany w interfejsie Attribution Reporting API do przygotowywania i wysyłania raportów zbiorczych.

Raporty agregowane zawierają następujące dane związane ze źródłami atrybucji:

  • Miejsce docelowe: nazwa pakietu aplikacji lub adres URL witryny eTLD+1, gdzie reguła powoduje miało miejsce.
  • Data: data, kiedy zdarzenie reprezentowane przez źródło atrybucji. .
  • Ładunek: wartości aktywatorów zbieranych jako zaszyfrowane pary klucz-wartość, które jest używana w zaufanej usłudze agregacji do i agregacji danych.

Usługi agregacji

Poniższe usługi zapewniają funkcję agregacji i pomagają chronić przed nieodpowiednim dostępem do danych agregacji.

Usługami tymi zarządzają różne podmioty. Zostały one opisane bardziej szczegółowo szczegóły w dalszej części tej strony:

  • Usługa agregacji jest jedyną usługą, z której specjaliści ds. technologii reklamowych powinni wykonywać wdrożenia.
  • Zarządzanie kluczami i raport agregowany księgowość jest świadczona przez tzw. koordynatorów. Ci koordynatorzy potwierdzają, że kod jest publicznie dostępny kod udostępniony przez Google oraz że wszyscy użytkownicy usługi agregacji mają ten sam klucz agregowanych raportów księgowych.
Usługa agregacji

Platformy technologii reklamowych muszą z wyprzedzeniem wdrożyć usługę agregacji, która jest oparta na plikach binarnych dostarczonych przez Google.

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

  • Daje on pewność, że kod działający w TEE to konkretny oferowany plik binarny przez Google. Jeśli ten warunek nie zostanie spełniony, usługa agregacji nie może uzyskać dostęp do kluczy odszyfrowywania potrzebnych do działania.
  • Zapewnia bezpieczeństwo podczas trwającego procesu i odizoluje go od źródeł zewnętrznych monitorowania ani ingerencji w nie.

Te korzyści w zakresie bezpieczeństwa zwiększają bezpieczeństwo usługi agregacji poufnych operacji, takich jak dostęp do zaszyfrowanych danych.

Więcej informacji na temat projektowania, przepływu pracy i zabezpieczeń usługi agregacji, patrz dokument dotyczący usługi agregacji w GitHubie.

System zarządzania kluczami (KMS)

Ta usługa sprawdza, czy usługa agregacji działa w zatwierdzonej wersji pliku binarnego, a następnie udostępnia usługę agregacji w branży technologii reklamowych poprawne klucze odszyfrowywania ich danych aktywatorów.

Uwzględnianie w raportach agregowanych

Ta usługa śledzi, jak często usługa agregacji technologii reklamowych uzyskuje dostęp do określony aktywator – który może zawierać wiele kluczy agregacji – i ogranicza dostęp; do odpowiedniej liczby odszyfrowywania. Zapoznaj się z usługą agregacji dla interfejsu Attribution Reporting API.

Interfejs API do agregacji raportów

Interfejs API do tworzenia treści publikowanych w raportach agregowanych wykorzystuje tę samą podstawę API jak podczas rejestrowania źródła atrybucji w raportach na poziomie zdarzenia. W dalszej części tego artykułu znajdziesz opis rozszerzeń API.

Rejestrowanie agregowanych danych źródłowych

Gdy interfejs API wysyła żądanie do identyfikatora URI źródła atrybucji, technologia reklamowa może zarejestrować listę kluczy agregacji o nazwie histogram_contributions przez odpowiadając z nowym polem o nazwie aggregation_keys w nagłówku HTTP Attribution-Reporting-Register-Source z kluczem jako key_name i wartością jako key_piece:

  • (Klucz) Nazwa klucza: ciąg znaków nazwy klucza. Używany jako klucz łączenia do w połączeniu z klawiszami po stronie aktywatora, by utworzyć ostateczny klucz.
  • (Wartość) Klucz: wartość ciągów bitowych klucza.

Ostatni klucz zasobnika histogramu jest w pełni zdefiniowany w czasie aktywatora przez wykonanie operacji binarnych LUB na tych częściach i elementach po stronie aktywatora.

Klucze końcowe mogą mieć maksymalnie 128 bitów. klucze są dłuższe niż to obcięte. Oznacza to, że ciągi szesnastkowe w pliku JSON powinny być ograniczone do maksymalnie 32 cyfry.

Dowiedz się więcej o strukturze kluczy agregacji i sposobie ich przechowywania. możesz skonfigurować klucze agregacji.

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

  • Agregować liczbę konwersji na poziomie kampanii
  • Zbiorcze wartości zakupów 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 aktywatora agregującego

Rejestracja aktywatora obejmuje 2 dodatkowe pola.

Pierwsze pole służy do zarejestrowania listy kluczy zbiorczych w aktywatorze z boku strony. Dostawca technologii reklamowych powinien odpowiedzieć, przesyłając pole aggregatable_trigger_data w nagłówku HTTP Attribution-Reporting-Register-Trigger, z te pola w przypadku każdego klucza zbiorczego na liście:

  • Fragment klucza: wartość ciągów bitowych klucza.
  • Klucze źródłowe: lista ciągów tekstowych z nazwami stron źródła atrybucji. z którymi należy połączyć klucz aktywujący, by utworzyć klucze końcowe.

Drugie pole służy do zarejestrowania listy wartości, które powinny do każdego klawisza. Dostawca technologii reklamowych powinien odpowiedzieć, przesyłając pole aggregatable_values w nagłówku HTTP Attribution-Reporting-Register-Trigger. Drugie pole to służy do rejestrowania listy wartości, które powinny mieć udział w każdym kluczu, które mogą być liczbami całkowitymi z zakresu $ [1, 2^{16}] $.

Każda reguła może wnosić wiele zmian w raportach agregowanych. łączna kwota darowizn na dane wydarzenie źródłowe jest ograniczona wartością 1 USD , który stanowi maksymalną sumę udziałów (wartości) we wszystkich kluczy zbiorczych dla danego źródła. $ L1 $ odnosi się do czułości lub normy L1 wyników histogramu na zdarzenie źródłowe. Przekroczenie tych limitów do dyskretnego pomijania kolejnych elementów. Początkowa propozycja to ustawienie wartości $ L1 $ na 2^{16} USD (65536 USD).

Szum w usłudze agregacji jest skalowany proporcjonalnie do tego parametru. Dlatego zalecane jest odpowiednie skalowanie raportowanych wartości dla dla danego klucza zbiorczego na podstawie przydzielonej do niego części budżetu L1 USD. Ten pomaga zagwarantować, że raporty zbiorcze zachowają najwyższy możliwy poziom i efektywność przy stosowaniu szumu. Mechanizm ten jest bardzo elastyczny i obsługują wiele strategii agregacji.

W przykładzie poniżej budżet na potrzeby prywatności jest dzielony równo między campaignCounts i geoValue, dzieląc darowiznę równą 1 USD na każdą z tych grup:

// 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
    }
}

Poprzedni przykład generuje następujące dane na histogram:

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

Współczynniki skalowania można odwrócić w celu uzyskania prawidłowych wartości, stosowany szum modulo:

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

Prywatność różnicowa

Celem tego interfejsu API jest opracowanie platformy obsługującej różnie prywatnych pomiarów zbiorczych. Aby to osiągnąć, dodaj proporcje szumu do budżetu 1 USD, np. wybrania szumu o tym rozkładzie:

\[ Laplace(\frac{L1}{ε}) \]

Integracja interfejsów Protected Audience API i Attribution Reporting API

Integracja interfejsów API w ramach raportów Protected Audience i Attribution interfejsy API pozwalają reklamodawcom ocenić skuteczność atrybucji w różnych taktyki remarketingowe, by dowiedzieć się, jakie typy odbiorców generują najwyższy ROI.

Dzięki integracji różnych interfejsów API Adtechs może:

  • Utwórz mapę klucz-wartość identyfikatorów URI, która będzie używana w obu tych miejscach 1) raportowanie interakcji oraz 2) rejestracja źródła.
  • Uwzględnij CustomAudience w mapowaniu klucza po stronie źródłowej na potrzeby agregacji raportowania podsumowującego (za pomocą Attribution Reporting API).

Gdy użytkownik zobaczy lub kliknie reklamę:

  • Adres URL służący do zgłaszania tych interakcji z użyciem Protected Audience API również można wykorzystać do zarejestrowania wyświetlenia lub kliknięcia jako kwalifikującego się źródła w Attribution Reporting API.
  • Technologia reklamowa może przekazywać niestandardową listę odbiorców (lub inne odpowiednie informacje o reklamie, takie jak miejsce docelowe reklamy lub czas oglądania), Adres URL umożliwiający przekazanie tych metadanych do raportów podsumowujących, gdy technologia reklamowa sprawdza łączną skuteczność kampanii.

Więcej informacji o tym, jak włączyć tę funkcję w ramach Protected Audience API, znajdziesz w odpowiedniej sekcji objaśnienia Protected Audience API.

Przykłady priorytetów rejestracji, atrybucji i raportowania

Ten przykład pokazuje zestaw interakcji użytkowników i definicję technologii reklamowej Priorytety źródła atrybucji i reguły mogą mieć wpływ na przypisane raporty. W W tym przykładzie zakładamy, że:

  • Wszystkie źródła i reguły atrybucji są rejestrowane przez tę samą technologię reklamową. temu samemu reklamodawcy.
  • Wszystkie źródła i reguły atrybucji mają miejsce podczas pierwszego zdarzenia (w ciągu 2 dni od pierwszego wyświetlenia reklam w aplikacji wydawcy).

Weź pod uwagę sytuację, w której użytkownik wykonuje te czynności:

  1. Użytkownik widzi reklamę. Technologie reklamowe rejestrują źródło atrybucji w interfejsie API. z priorytetem 0 (widok nr 1).
  2. Użytkownik widzi reklamę zarejestrowaną z priorytetem 0 (widok nr 2).
  3. Użytkownik klika reklamę zarejestrowaną z priorytetem 1 (kliknięcie 1).
  4. Użytkownik dokonuje konwersji (otwiera stronę docelową) w aplikacji reklamodawcy. Technologia reklamowa rejestruje regułę za pomocą interfejsu API o priorytecie 0 (konwersja 1).
    • Gdy reguły są rejestrowane, interfejs API przeprowadza atrybucję, a dopiero potem generowania raportów.
    • Dostępne są 3 źródła atrybucji: widok 1, widok 2 kliknij 1. Interfejs API przypisuje temu wyzwalaczowi kliknięcie nr 1, ponieważ jest to o najwyższym priorytecie i najnowszych.
    • Widok 1 i widok 2 zostały odrzucone i nie można ich już wyświetlać w przyszłości o pochodzeniu danych.
  5. użytkownik dodaje produkt do koszyka w aplikacji reklamodawcy, priorytet równy 1 (konwersja 2).
    • Kliknięcie nr 1 jest jedynym kwalifikującym się źródłem atrybucji. Atrybuty interfejsu API aby kliknąć 1 opcję.
  6. użytkownik dodaje produkt do koszyka w aplikacji reklamodawcy, priorytet równy 1 (konwersja 3).
    • Kliknięcie nr 1 jest jedynym kwalifikującym się źródłem atrybucji. Atrybuty interfejsu API aby kliknąć 1 opcję.
  7. użytkownik dodaje produkt do koszyka w aplikacji reklamodawcy, priorytet równy 1 (konwersja 4).
    • Kliknięcie nr 1 jest jedynym kwalifikującym się źródłem atrybucji. Atrybuty interfejsu API aby kliknąć 1 opcję.
  8. użytkownik dokonuje zakupu w aplikacji reklamodawcy, który jest zarejestrowany z priorytetem; 2 (konwersja 5).
    • Kliknięcie nr 1 jest jedynym kwalifikującym się źródłem atrybucji. Atrybuty interfejsu API aby kliknąć 1 opcję.

Raporty na poziomie zdarzenia mają następujące cechy:

  • Domyślnie trzy pierwsze reguły przypisane do kliknięcia i pierwszej reguły są wysyłane do danego widoku po upływie odpowiedniego okresu raportowania.
  • Jeśli w okresie raportowania istnieją reguły o wyższym , mają one pierwszeństwo i zastępują najnowszą regułę.
  • W poprzednim przykładzie technologia reklamowa otrzymuje 3 raporty zdarzeń po 2-dniowe okno raportowania: konwersja nr 2, konwersja nr 3 i konwersja 5,
    • Wszystkie te 5 reguł są przypisane do kliknięcia nr 1. Domyślnie interfejs API wysyłać raporty dotyczące pierwszych 3 reguł: konwersji 1, konwersji 2 i 3.
    • Priorytet konwersji nr 4 (1) jest jednak wyższy niż konwersji nr 1 priorytet (0). Raport o zdarzeniach konwersji 4 zastępuje konwersję 1 raport o zdarzeniach.
    • Poza tym priorytet konwersji nr 5 (2) jest wyższy niż jakiegokolwiek innego . Raport o zdarzeniach konwersji nr 5 zastępuje raport konwersji nr 4 na mogą zostać wysłane.

Raporty agregowane charakteryzują się tymi cechami:

  • Zaszyfrowane, zbiorcze raporty są wysyłane do zespołu technicznego reklam, gdy tylko są dostępne kilka godzin po zarejestrowaniu reguł.

    Jako zespół technologii reklamowych tworzysz grupy odbiorców na podstawie informacji niezaszyfrowane w raportach zbiorczych. Te informacje są zawarte w w polu shared_info raportu skumulowanego wraz z sygnaturą czasową i źródła raportowania. Nie możesz grupować na podstawie żadnych zaszyfrowanych informacji w pary klucz-wartość agregacji. Oto kilka prostych strategii, które możesz zastosować: raportów zbiorczych codziennie lub co tydzień. W idealnym przypadku partie powinny zawierać co najmniej 100 raportów w każdym.

  • To, kiedy i jak zbierać zbiorcze raporty lub wysłać je do usługi agregacji.

  • W porównaniu do raportów na poziomie zdarzenia zaszyfrowane raporty agregowane mogą przypisać do źródła więcej wyzwalaczy.

  • W poprzednim przykładzie wysyłanych jest 5 raportów zbiorczych, po jednym na każdy .

Raporty dotyczące debugowania przejściowych

Attribution Reporting API to nowy, dość skomplikowany sposób atrybucji bez identyfikatorów różnych aplikacji. W związku z tym wspieramy mechanizmu przejściowego pozwalającego uzyskać więcej informacji o raportach atrybucji, gdy identyfikator wyświetlania reklam jest dostępny (użytkownik nie zrezygnował z personalizacji); używając identyfikatora wyświetlania reklam, a aplikacja wydawcy lub reklamodawcy zadeklarowała identyfikator AdID. uprawnienia). Zapewnia to, że interfejs API jest w pełni zrozumiały jego wdrożenia, pomóc w usuwaniu błędów i łatwiej porównywać wydajność alternatywnych rozwiązań opartych na identyfikatorze wyświetlania reklam. Istnieją 2 typy raportów debugowania: atrybucja-sukces i szczegółowy opis.

Szczegółowe informacje o debugowaniu znajdziesz w przewodniku po raportach debugowania przejściowych. raportów z pomiarami między aplikacją a stroną internetową.

Raporty z debugowania o sukcesie atrybucji

Rejestracje źródłowe i aktywatory akceptują nowe 64-bitowe pole debug_key (sformatowany jako ciąg znaków), który wypełnia technika reklamowa. source_debug_key i Dane trigger_debug_key są przekazywane bez zmian zarówno na poziomie zdarzenia, jak i na poziomie zbiorczym raportów.

Jeśli raport zostanie utworzony przy użyciu zarówno źródłowych, jak i aktywujących kluczy debugowania, duplikat raport o debugowaniu jest wysyłany z niewielkim opóźnieniem do Punkt końcowy .well-known/attribution-reporting/debug/report-event-attribution. raporty o debugowaniu są identyczne ze zwykłymi raportami, w tym oba pola z kluczem debugowania. Uwzględnienie tych kluczy w obu strumieniach pozwala powiązać zwykłe raporty z oddzielnym strumieniem raportów na temat debugowania.

  • W przypadku raportów na poziomie zdarzenia:
    • Zduplikowane raporty na temat debugowania są wysyłane z ograniczonym opóźnieniem, dlatego nie są pominięte przez limity dostępnych reguł, które umożliwiają technologie reklamowe aby poznać wpływ tych limitów na raporty na poziomie zdarzenia.
    • Raporty na poziomie zdarzenia powiązane z fałszywymi zdarzeniami wywołującymi nie mają trigger_debug_key Dzięki temu technologie reklamowe mogą lepiej zrozumieć, w interfejsie API jest stosowany szum.
  • W przypadku raportów agregowanych:
    • Będziemy obsługiwać nowe pole debug_cleartext_payload, które zawiera odszyfrowanego ładunku tylko wtedy, gdy zarówno source_debug_key, jak i Ustawiono: trigger_debug_key.

Szczegółowe raporty z debugowania

Szczegółowe raporty na temat debugowania pozwalają programistom monitorować niektóre błędy lub źródła atrybucji. Raporty debugowania są wysyłane z niewielkim opóźnieniem po wystąpieniu źródła atrybucji lub po zarejestrowaniu się w ,Punkt końcowy well-known/attribution-reporting/debug/verbose.

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

  • Typ: przyczyna wygenerowania raportu. Zobacz pełną listę szczegółowych raportów.
    • Istnieją zwykle raporty szczegółowe i generują raporty szczegółowe.
    • Szczegółowe raporty źródłowe wymagają udostępnienia identyfikatora wyświetlania reklam aplikacji wydawcy i generować szczegółowe raporty wymagają identyfikatora wyświetlania reklam dostępnych w aplikacji reklamodawcy.
    • Uruchamiaj szczegółowe raporty (z wyjątkiem trigger-no-matching-source) może opcjonalnie zawierać source_debug_key. Możesz go uwzględnić tylko wtedy, gdy identyfikator wyświetlania reklam jest też dostępny w aplikacji wydawcy.
  • Treść: treść raportu zależna od jego typu.

Technologie reklamowe muszą wyrazić zgodę na otrzymywanie szczegółowych raportów z debugowania debug_reporting w polu słownika w Attribution-Reporting-Register_Source i Nagłówki: Attribution-Reporting-Register-Trigger.

  • Szczegółowe raporty źródłowe wymagają zaakceptowania tylko w nagłówku rejestracji źródła.
  • Raporty na temat debugowania reguły wymagają wyrażenia zgody tylko w nagłówku rejestracji aktywatora.

Jak korzystać z raportów debugowania

Jeśli miała miejsce konwersja (zgodnie z obecnym systemem pomiarowym) otrzymaliśmy raport debugowania dla tej konwersji, co oznacza, że reguła została udało się zarejestrować.

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

Jeśli nic nie jest zgodne, może to wynikać z kilku powodów.

Działa zgodnie z oczekiwaniami:

  • Zachowania w interfejsie API chroniące prywatność:
    • Użytkownik przekroczył limit liczby zgłoszeń, przez co kolejne raporty nie być wysyłane w danym okresie; lub źródło zostało usunięte z powodu oczekującego limit miejsca docelowego.
    • W przypadku raportów na poziomie zdarzenia: wyniki są generowane w sposób losowy. (szumu) i został stłumiony, możesz też otrzymać losowy raport.
    • W przypadku raportów na poziomie zdarzenia: limit trzech (w przypadku kliknięć) lub jeden (dla wyświetlenia), a kolejne raporty nie będą miały lub niższy niż w istniejących raportach.
    • Przekroczono limity udziału w raportach agregowanych.
  • Logika biznesowa zdefiniowana przez technicznie reklamy:
    • Reguła jest odfiltrowywana przez filtry lub reguły priorytetów.
  • opóźnienia lub interakcje z dostępem do sieci (np. gdy użytkownik zmienia wyłączone przez dłuższy czas).

Niezamierzone przyczyny:

  • Problemy z implementacją:
    • Nagłówek źródłowy jest nieprawidłowo skonfigurowany.
    • Nagłówek aktywatora jest nieprawidłowo skonfigurowany.
    • Inne problemy z konfiguracją.
  • Problemy z urządzeniem lub siecią:
    • Awarie z powodu warunków sieciowych.
    • Źródłowa odpowiedź rejestracji lub rejestracji aktywatora nie dociera do klienta.
    • Błąd interfejsu API.

Co wziąć pod uwagę w przyszłości pytania otwarte

Interfejs Attribution Reporting API jest w trakcie opracowywania. Badamy też przyszłość potencjalnych funkcji, takich jak modele atrybucji niezwiązanej z ostatnim kliknięciem oraz konwersje na różnych urządzeniach przypadków użycia pomiarów.

Chcielibyśmy też poznać opinie społeczności na temat kilku problemów:

  1. Czy są jakieś przypadki użycia, w których chcesz, aby interfejs API wysyłał raporty dotyczące zweryfikowana instalacja? Raporty te byłyby uwzględniane w raportach na temat platform technologii reklamowych odpowiednie limity liczby żądań.
  2. Czy przewidujesz jakieś problemy z przekazaniem danych InputEvent z aplikacji? do rejestracji źródła przy użyciu technologii reklamowych?
  3. Czy masz specjalne przypadki użycia atrybucji w przypadku wstępnie załadowanych aplikacji lub ponownie zainstalowane aplikacje?