Raportowanie atrybucji: pomiary obejmujące wiele aplikacji i witryn

bookmark_border Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Ostatnie aktualizacje

• Dodano sekcję o tym, jak korzystać z tymczasowych raportów debugowania.
• Dodaliśmy instrukcje dotyczące dodawania do listy dozwolonych źródeł internetowych.

Ścieżki reguł

Jak opisano w propozycji interfejsu Attribution Reporting API, interfejs ten umożliwia przypisywanie tych ścieżek aktywacji na jednym urządzeniu z Androidem: Tutaj definiujemy internet jako: (1) samodzielną przeglądarkę działającą na Androidzie (np. Chrome) lub (2) komponent WebView działający w aplikacji na Androida.

• App-to-app: użytkownik widzi reklamę w aplikacji, a potem dokonuje konwersji w tej aplikacji lub innej zainstalowanej aplikacji.
• App-to-web: użytkownik widzi reklamę w aplikacji, a potem dokonuje konwersji w internecie.
• Web-to-app::użytkownik widzi reklamę w internecie, a potem dokonuje konwersji w aplikacji.
• Web-to-web: użytkownik widzi reklamę w internecie, a potem dokonuje konwersji w internecie.

Powyższe ścieżki wyzwalaczy odpowiadają tym wymaganiom:

• Dla specjalistów ds. technologii reklamowych: aktualizacje wywołań interfejsu API i raportowania w celu umożliwienia ścieżek z aplikacji do internetu.
• Aplikacje i przeglądarki: możliwość przekazywania rejestracji źródeł atrybucji w internecie oraz uruchamiania skryptów internetowych na Androidzie.

Z tego dokumentu dowiesz się, jak rozszerzyliśmy interfejs Attribution Reporting API, aby obsługiwał ścieżki uruchamiania typu aplikacja–sieć, sieć–aplikacja i sieć–sieć. Zawiera on też opis zmian, które firmy technologiczne i aplikacje reklamowe muszą wprowadzić, aby spełniać wymagania dotyczące obsługi tych ścieżek.

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 na konto Piaskownicy prywatności.

Gdy proces rejestracji zostanie zakończony, interfejs API odrzuci rejestrację, jeśli otrzyma wywołanie rejestracji niezarejestrowanej.

Podczas rejestracji platformy technologii reklamowych powinny się upewnić, że rejestrują wszystkie adresy URL serwera, których mogą używać w aplikacji i internecie do rejestrowania źródeł i wyzwalania atrybucji. Obsługiwane są różne adresy URL rejestracji serwera, ale tylko jedno źródło danych. To źródło danych pochodzi z domeny jednego z adresów URL rejestracji serwera.

Zmiany dotyczące technologii reklamowych

Ta sekcja dotyczy zmian dla technologii reklamowych korzystających z interfejsu Attribution Reporting API.

Zmiany w rejestracji i atrybucji

Podczas rejestrowania źródła atrybucji firmy zajmujące się technologiami reklamowymi podają pole docelowe, które jest nazwą pakietu aplikacji, w której występuje zdarzenie uruchamiające. Aby umożliwić pomiar danych z aplikacji do witryny, planujemy obsługiwać 1 pole miejsca docelowego aplikacji (nazwa pakietu aplikacji) i 1 pole miejsca docelowego w internecie (eTLD+1).

Podczas rejestrowania źródeł atrybucji ani wyzwalaczy w internecie interfejs API nie obsługuje przekierowań, ponieważ każda aplikacja zawierająca treści internetowe może mieć własny model uprawnień. Każda aplikacja jest odpowiedzialna za przekierowania (jeśli są obsługiwane) i wywoływanie interfejsów API kontekstu sieci w przypadku każdego przeskoku przekierowania.

Ponadto ta integracja umożliwia technologiom reklamowym stosowanie logiki atrybucji w przypadku aplikacji w przypadku źródeł atrybucji internetowych. Możesz na przykład określić okna atrybucji po instalacji w źródle atrybucji internetowej.

Otrzymywanie raportów z aplikacji i witryn

Interfejs Attribution Reporting API na Androida może wysyłać raporty o konwersjach zarówno w aplikacji, jak i w internecie. Jeśli dostawcy technologii reklamowych nie chcą dopasowywać danych o wyzwalaczach i kluczy-wartości w przypadku witryn i aplikacji, mogą rozróżniać konwersje w witrynie i aplikacji:

• W przypadku raportów na poziomie zdarzenia będziemy obsługiwać pole docelowego, które określa, czy wywołanie nastąpiło w internecie (pole docelowe to eTLD+1) czy w aplikacji (pole docelowe to nazwa pakietu aplikacji).
• W przypadku raportów możliwych do zsumowania docel jest wysyłany w postaci zwykłego tekstu.

Wpływ pomiarów w internecie na przejścia z reklamy do witryny

Aplikacje decydują, kiedy przekazać rejestrację do interfejsu Attribution Reporting API. Należy wziąć pod uwagę kilka kwestii:

• Czy na tym urządzeniu jest dostępny interfejs Attribution Reporting API? Udostępnimy aplikacjom nowy sygnał, który zwróci informację, czy interfejs Attribution Reporting API jest dostępny na danym urządzeniu. Więcej informacji o tym, jak aplikacje mogą przekazać rejestrację do interfejsu Attribution Reporting API, znajdziesz w sekcji z informacjami o zmianach w aplikacji.
• Jaki odsetek źródeł i wyzwalaczy atrybucji powinien być przekazywany do interfejsu API? Decyzja zostanie podjęta przez każdą aplikację lub technologię reklamową, jeśli aplikacja zezwala na wybór. Jeśli aplikacja ma własne rozwiązanie analityczne, możesz użyć go zamiast Google Analytics. Przekazywanie wszystkich rejestracji źródeł i wyzwalaczy do interfejsu Attribution Reporting API na Androida (jeśli jest dostępny) umożliwia uzyskanie najbardziej dokładnych danych o przypisaniu w aplikacji i w internecie.

Ten przykład pokazuje, jak aplikacje w przeglądarce mogą współpracować z interfejsem Attribution Reporting API, aby zapewnić dokładne pomiary, gdy użytkownik kliknie reklamę zarówno w aplikacji w przeglądarce, jak i w innej aplikacji:

• W dniu 1 użytkownik klika reklamę w aplikacji przeglądarki.
  • Aplikacja przeglądarki może używać własnego rozwiązania do pomiarów lub przekazać rejestrację kliknięcia reklamy internetowej do interfejsu Attribution Reporting API.
• Dzień 2. Użytkownik klika reklamę w aplikacji innej niż przeglądarka.
  • Kliknięcie jest rejestrowane w interfejsie API jako źródło atrybucji. Aplikacja przeglądarki nie ma dostępu do tego kliknięcia, ponieważ zdarzenie miało miejsce w innej aplikacji.
• W 3 dniu użytkownik dokonuje konwersji w aplikacji przeglądarki.
  • Jeśli aplikacja przeglądarki rejestruje kliknięcie i konwersję za pomocą własnego rozwiązania do pomiarów i przekazuje te informacje do interfejsu AttributionReporting API, mało prawdopodobne, aby technologia reklamowa mogła usuwać duplikaty raportów o konwersjach w różnych rozwiązaniach do pomiarów. Ponadto technologia reklamowa może wykorzystywać limity szybkości aplikacji przeglądarki i limity szybkości interfejsu Attribution Reporting API. Dlatego zalecamy, aby aplikacje przekazywały wszystkie zdarzenia reklamowe i konwersje zarejestrowane w interfejsie API, jeśli jest on dostępny.

Rejestrowanie źródła atrybucji i jej aktywatora w komponencie WebView

Jeśli aplikacja używa WebView do wyświetlania treści z internetu, a nie reklamy na Androida, może ubiegać się o dodanie do listy dozwolonych (registerWebSource()) i podać adres domeny najwyższego poziomu witryny, która ma być powiązana ze źródłem atrybucji, zamiast nazwy pakietu aplikacji.

Podobnie jak przeglądarki, WebView obsługuje registerWebTrigger() w przypadku rejestracji zdarzeń, co powoduje powiązanie zdarzenia z pochodzącym z poziomu najwyższego źródłem. WebView nie obsługuje rejestrowania wyzwalacza aplikacji. Jeśli chcesz to zrobić, skontaktuj się z nami. Pełną listę obsługiwanych przez WebView kombinacji znajdziesz w artykule Źródło atrybucji i rejestracja wyzwalacza z WebView.

W przeciwieństwie do przeglądarek WebView obsługuje rejestrację tylko w ramach nagłówka Attribution-Reporting-Eligible, jeśli jest dostępny interfejs Attribution Reporting API na Androida. Jeśli interfejs Attribution Reporting API na Androida jest niedostępny, WebView nie ustawia nagłówka Attribution-Reporting-Eligible i nie rejestruje żadnych zdarzeń.

Aby zarejestrować źródło atrybucji lub jej wyzwalacz za pomocą systemu operacyjnego:

• Technologie reklamowe powinny odpowiadać na rejestracje źródeł za pomocą nagłówka Attribution-Reporting-Register-OS-Source, który inicjuje dodatkowe wywołanie interfejsu API z WebView do registerSource() lub registerWebSource().
• Technologia reklam może też odpowiadać na rejestracje uruchamiane za pomocą nagłówka Attribution-Reporting-Register-OS-Trigger, który inicjuje dodatkowe wywołanie interfejsu API z WebView do registerWebTrigger() lub registerTrigger().

Pamiętaj, że jeśli odpowiedź nie zawiera poprzednich nagłówków lub zawiera nagłówki Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger, mimo że rejestracja przez internet nie jest obsługiwana, cała rejestracja się nie powiedzie.

Szczegółowe informacje o tym, czy WebView będzie używać wartości registerSource() / registerWebSource() i registerTrigger() / registerWebTrigger() (a także o tym, jak zmienić to zachowanie), znajdziesz w artykule Źródło atrybucji i rejestrowanie zdarzeń z WebView.

Raporty przejściowe dotyczące debugowania

Interfejs Attribution Reporting API obsługuje opcjonalną funkcję tymczasowych raportów debugowania, która umożliwia specjalistom ds. technologii reklamowych uzyskanie dodatkowych informacji o raportach atrybucji, gdy jest dostępny identyfikator reklamowy. Istnieją 2 typy raportów debugowania: attribution-success i verbose. Te raporty są obsługiwane w przypadku atrybucji między aplikacjami i w internecie. Oba typy raportów zawierają te same informacje. Jedyną różnicą jest to, że w przypadku wysyłania raportów debugowania wymagane są uprawnienia.

W przypadku atrybucji z sieci do sieci, która występuje w ramach jednej aplikacji (np. w tej samej aplikacji przeglądarki), raporty o skuteczności atrybucji i raporty szczegółowe są dostępne tylko wtedy, gdy dostępne są pliki cookie innych firm, a nie na podstawie dostępności identyfikatora reklamowego.

W przypadku atrybucji między aplikacjami (z aplikacji do witryny, z witryny do aplikacji i z witryny do witryny) raporty attribution-success i verbose są dostępne, jeśli identyfikator AdID jest dostępny po stronie aplikacji, a technologia reklamowa może przekazać ten sam (prawidłowy) identyfikator po stronie internetowej.

W późniejszym przykładzie przejścia z aplikacji do witryny źródło znajduje się w aplikacji wydawcy, ale wyzwalacz występuje w witrynie reklamodawcy w aplikacji przeglądarkowej.

Aby włączyć raportowanie debugowania skuteczności powiązania w przypadku kampanii z przekierowaniem na stronę internetową, musisz spełnić te warunki:

• Użytkownik nie może zrezygnować z personalizacji za pomocą identyfikatora wyświetlania reklam.
• Aplikacja wydawcy musi mieć zadeklarowane uprawnienia identyfikatora wyświetlania reklam.
• Technologia reklamowa musi przekazać wartość AdID w rejestracji wyzwalacza (z kontekstu sieci web)

Aby włączyć szczegółowe raporty debugowania w przypadku aplikacji na stronie internetowej:

• Raporty szczegółowe dotyczące źródeł zależą tylko od uprawnień po stronie wydawcy. Aby móc wysyłać szczegółowe raporty o źródłach, użytkownik nie może zrezygnować z personalizacji na podstawie identyfikatora AdID, a aplikacja wydawcy musi mieć zadeklarowane uprawnienia do AdID.
• Szczegółowe raporty o wyzwalaczach zależą tylko od uprawnień po stronie wyzwalacza (w tym przykładzie po stronie sieci). Aby mogły być wysyłane szczegółowe raporty, w przeglądarce muszą być dostępne pliki cookie innych firm.
• W przypadku szczegółowych raportów o wywołaniu, które mogą opcjonalnie zawierać identyfikator source_debug_key, identyfikator source_debug_key jest uwzględniany, jeśli jest dostępny dla aplikacji wydawcy.

Pamiętaj, że w każdym przypadku technologia reklamowa musi wyrazić zgodę na otrzymywanie szczegółowych raportów debugowania za pomocą pola słownika debug_reporting w nagłówkach źródła i wyzwalacza rejestracji.

Zmiany dotyczące aplikacji

Będziemy obsługiwać przypisywanie udziału w konwersji w aplikacjach i na stronach internetowych, umożliwiając aplikacjom przekazywanie rejestracji źródeł przypisywania udziału w konwersji i wyzwalaczy internetowych do interfejsu Attribution Reporting API na Androidzie za pomocą nowego zestawu wywołań interfejsu API kontekstu internetowego.

Po wykonaniu czynności rejestracyjnych opisanych w następnych sekcjach źródła i wyzwalacze atrybucji w aplikacji i w witrynie są przechowywane na urządzeniu, a interfejs Attribution Reporting API może wykonywać atrybucję ostatniego kontaktu z użytkownikiem z uwzględnieniem priorytetu źródeł w aplikacji i w witrynie.

W propozycji Piaskownicy prywatności w internecie znajdziesz przykład integracji przeglądarek z interfejsem Attribution Reporting API na Androida, która umożliwia pomiary w różnych aplikacjach i w internecie. W ramach propozycji przeglądarka doda te nagłówki żądania:

• Attribution-Reporting-Eligible informuje, czy obsługa atrybucji jest dostępna na poziomie systemu operacyjnego. W tym przypadku nagłówek wskazuje, czy interfejs Attribution Reporting API jest dostępny na urządzeniu z Androidem.
• W razie dostępności dostawcy technologii reklamowych mogą opcjonalnie odpowiadać za pomocą interfejsu Attribution-Reporting-Register-OS-Source, który inicjuje dodatkowy wywołanie interfejsu API z aplikacji przeglądarki do interfejsu registerWebSource().
• Technologie reklamowe mogą też odpowiadać na rejestracje wyzwalaczy za pomocą nagłówka Attribution-Reporting-Register-OS-Trigger, który inicjuje dodatkowe wywołanie interfejsu API z aplikacji przeglądarki do registerWebTrigger().

Rejestrowanie źródła atrybucji

Podczas rejestrowania źródła atrybucji aplikacje mogą wywołać funkcję registerWebSource(), która oczekuje tych parametrów:

• Identyfikatory URI źródeł atrybucji: platforma wysyła żądanie do każdego identyfikatora URI z tej listy, aby pobrać metadane powiązane ze źródłem atrybucji.
  
  Każdy identyfikator URI powinien być opatrzony flagą logiczną Debug, która wskazuje, czy klucze debugowania podane przez techników powinny zostać uwzględnione w raporcie.
• Zdarzenie wejścia: obiekt InputEvent (w przypadku zdarzenia kliknięcia) lub null (w przypadku zdarzenia wyświetlenia).
• Źródło: źródło, w którym wystąpiło źródło (witryna wydawcy).
• Destynacja w urządzeniu: nazwa pakietu aplikacji, w której występuje zdarzenie uruchamiające.
• Docelowa strona internetowa: eTLD+1, w której odbywa się zdarzenie uruchamiające.
• Zweryfikowany cel: identyfikator URI docelowego systemu operacyjnego lub witryny używany do nawigacji po kliknięciu przez użytkownika.

Gdy interfejs API wysyła żądanie do identyfikatora URI źródła atrybucji, dostawca technologii reklamowej powinien odpowiedzieć metadanymi źródła atrybucji w nagłówku HTTP,Attribution-Reporting-Register-Source. Ten nagłówek używa tych samych pól co rejestracja źródła atrybucji z aplikacji do aplikacji, z kilkoma wyjątkami:

• Interfejs API sprawdza, czy miejsca docelowe określone przez technologię reklamową są zgodne z miejscami docelowymi określonymi przez aplikację. Jeśli miejsca docelowe są różne, interfejs API odrzuca rejestrację źródła atrybucji.
  
  Aplikacje powinny weryfikować miejsca docelowe w internecie przed wywołaniem interfejsu API kontekstu internetowego. W przypadku kliknięć aplikacje powinny sprawdzić, czy określone miejsce docelowe jest zgodne z miejscem docelowym, do którego przechodzi użytkownik.
• Interfejs API ignoruje wszystkie identyfikatory URI przekierowania podane w elementachAttribution-Reporting-Redirects. Aplikacje powinny samodzielnie śledzić przekierowania i wywoływać funkcję registerWebSource() dla każdego przekierowania, aby w razie potrzeby stosować własne zasady dotyczące uprawnień.

Aplikacje muszą dołączyć do listy dozwolonych, aby mogły wykonywać połączenia na numer registerWebSource(). Aby dołączyć do listy dozwolonych, wypełnij ten formularz. Lista dozwolonych ma na celu ograniczenie zagrożeń dla prywatności związanych z budowaniem zaufania w kontekście stron internetowych.

Wywołanie rejestracji (konwersji)

Podczas rejestracji reguły aplikacje mogą wywoływać funkcję registerWebTrigger(), która oczekuje tych parametrów:

• Identyfikatory URI wyzwalaczy: platforma wysyła żądanie do każdego identyfikatora URI z tej listy, aby pobrać metadane powiązane z wyzwalaczem.
• Pochodzenie miejsca docelowego: miejsce, w którym wystąpiło zdarzenie (witryna reklamodawcy).

Źródło atrybucji i rejestracja wyzwalacza z komponentu WebView

Domyślnie komponent WebView będzie używać registerSource() i registerWebTrigger(). W przypadku wystąpienia reguły źródła są powiązane z aplikacją, a reguły z najwyższym źródłem WebView.

Jeśli aplikacja wymaga innego zachowania (np. aplikacje, które hostują treści internetowe w komponencie WebView), muszą używać metody setAttributionRegistrationBehavior w klasie androidx.webkit.WebViewSettingsCompat. Ta metoda określa, czy WebView ma wywołać metodę registerWebSource() czy registerSource() oraz registerWebTrigger() czy registerTrigger().

Dostępne opcje setAttributionRegistrationBehavior:

Kwestie związane z ochroną prywatności i bezpieczeństwem

W tej sekcji omawiamy kwestie związane z prywatnością i bezpieczeństwem w przypadku aplikacji korzystających z interfejsu Attribution Reporting API.

Wpływ mechanizmów ochrony prywatności stosowanych w przypadku raportów

Jak opisano w głównej propozycji interfejsu API, stosuje on w raportach ograniczenia szybkości, które chronią prywatność. Niektóre limity są podzielone na aplikacje źródłowe i docelowe. Gdy zarejestrowane jest źródło lub reguła atrybucji internetowej, limit częstotliwości jest dzielony według witryny źródłowej lub docelowej, a nie aplikacji.

Jeśli aplikacja ma osobne limity częstotliwości, atakujący może wykorzystać limity dotyczące aplikacji oprócz limitów interfejsu API. Aby temu zapobiec, aplikacje powinny zapewnić, aby dane źródło atrybucji nie było zarejestrowane ani w rozwiązaniu do pomiarów aplikacji, ani w interfejsie Attribution Reporting API na Androida.

Zdobywanie zaufania w kontekście internetowym

W przypadku wywołań interfejsu API w kontekście sieci interfejs API ufa aplikacji, która ma wykrywać i określać źródła i miejsca docelowe. Może to wiązać się z potencjalnymi kwestiami dotyczącymi prywatności i bezpieczeństwa:

• W celu obejścia ograniczeń szybkości dotyczących ilości informacji, które może przesyłać dowolne źródło, przeciwnik może twierdzić, że hostuje należące do siebie witryny.
• Kilku przeciwników może współpracować ze sobą, aby zarejestrować oddzielne źródła atrybucji, twierdząc, że pochodzą z tej samej witryny źródłowej. Może to spowodować osiągnięcie przez witrynę źródłową limitów szybkości platformy reklamowej i uniemożliwić zarejestrowanie przez nią źródeł atrybucji.

Aby temu zapobiec, ograniczymy możliwość wywoływania registerWebSource() do przeglądarek lub aplikacji, które potwierdzają, że witryna źródłowa użyta w rejestracji jest rzeczywistą witryną wyświetlaną użytkownikowi. Aby dołączyć do listy dozwolonych do wywołania funkcji registerWebSource(), wypełnij formularz rejestracyjny do raportowania atrybucji „z sieci do aplikacji”.

Każda aplikacja może wywołać funkcję registerWebTrigger(), ponieważ względy związane z ochroną prywatności i bezpieczeństwem po stronie wyzwalacza nie mają zastosowania bez współpracy po stronie źródła.

Kontrola użytkowników

Aplikacje mogą nadal obsługiwać kontrolę użytkownika lub zasady dotyczące uprawnień, o ile można je zdefiniować w momencie rejestracji. Jeśli na przykład aplikacje zezwalają na jakiekolwiek uprawnienia na poziomie witryny lub użytkownika, powinny je ocenić i określić, czy wywołać interfejsy API kontekstu internetowego.

Dodatkowo udostępnimy nowe wywołanie interfejsu API z aplikacji, które umożliwia usuwanie wszystkich źródeł atrybucji, wyzwalaczy i oczekujących raportów przechowywanych na urządzeniu w przypadku tej aplikacji. Jeśli na przykład aplikacje umożliwiają użytkownikom czyszczenie historii przeglądania, mogą wywołać interfejs API, aby usunąć źródła atrybucji, wyzwalacze i oczekujące raporty zapisane na urządzeniu użytkownika.

Uwagi na przyszłość i pytania otwarte

Interoperacyjność między aplikacją a internetem w przypadku interfejsu Attribution Reporting API jest obecnie opracowywana. Chcielibyśmy poznać opinię społeczności na temat kilku pomysłów:

1. Jak będziesz korzystać z rozwiązań do pomiaru w przeglądarce z interfejsem Attribution Reporting API na urządzeniu z Androidem, które obsługuje Piaskownicę prywatności? Czy wolisz przekazać wszystko do Androida?
2. Czy istnieje ryzyko, że w przypadku każdego źródła i wyzwalacza atrybucji mogą być wysyłane 2 pingi – jeden z przeglądarki lub aplikacji, a drugi z interfejsu Attribution Reporting API?
3. Jak możemy ułatwić Ci debugowanie różnych interfejsów API?
4. Propozycja nie obejmuje weryfikacji, czy miejsca docelowe w aplikacji i w witrynie są powiązane. W przyszłości możemy weryfikować te miejsca docelowe, sprawdzając powiązania za pomocą linków do zasobów cyfrowych. Czy to uniemożliwiłoby korzystanie z jakiegoś przypadku użycia? Czy warto używać Digital Asset Links do przeprowadzania tej weryfikacji?
5. Podczas rejestrowania źródła atrybucji musisz określić miejsce docelowe. W przypadku kampanii typu web-to-app możesz podać link do aplikacji. Jakich formatów używasz do określenia tego linku do aplikacji?
6. Podczas rejestrowania źródła atrybucji „aplikacja–strona internetowa” należy zarejestrować to źródło w aplikacji za pomocą interfejsu Attribution Reporting API na Androida. Jeśli np. użytkownik kliknie reklamę, która otwiera się w przeglądarce lub na karcie niestandardowej przeglądarki, to kliknięcie (zdarzenie źródłowe) powinno zostać zarejestrowane przez aplikację, a nie w kontekście przeglądarki. Skontaktuj się z nami, jeśli masz wątpliwości lub jeśli masz inne przypadki użycia, które nie pasują do kategorii opisanych w tym artykule przedstawiającym obsługiwane przepływy danych.

Polecane dla Ciebie

• Uwaga: tekst linku jest wyświetlany, gdy obsługa JavaScript jest wyłączona
• Raportowanie atrybucji
• Przewodnik dla programistów dotyczący Attribution Reporting API
• Informacje o wersji