Raportowanie atrybucji: pomiary obejmujące wiele aplikacji i witryn

Uwaga: ten dokument odzwierciedla obecne propozycje dotyczące Piaskownicy prywatności na Androida i może ulec zmianie. Zachęcamy do dzielenia się opiniami i komentarzami, które pomogą nam w realizacji tych działań.

Ostatnie aktualizacje

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

Jak opisano w propozycji interfejsu Attribution Reporting API, interfejs ten umożliwia przypisywanie tych ścieżek aktywacji na jednym urządzeniu z Androidem:

• 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 przeglądarce mobilnej lub w aplikacji.
• Web-to-app: użytkownik widzi reklamę w przeglądarce mobilnej lub w aplikacji, a potem dokonuje konwersji w aplikacji.
• Web-to-web: użytkownik widzi reklamę w przeglądarce mobilnej lub w aplikacji, a potem dokonuje konwersji w tej samej przeglądarce lub w innej przeglądarce na tym samym urządzeniu.

Internet to tutaj definiowany jako treści internetowe wyświetlane w aplikacji. Treści internetowe mogą być wyświetlane w kontekście aplikacji mobilnej przeglądarki lub jako wbudowane witryny wyświetlane w aplikacjach innych niż przeglądarka.

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

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

Z tego dokumentu dowiesz się, jak interfejs Attribution Reporting API został rozszerzony o ścieżki wywołania 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.

Po zakończeniu procesu rejestracji 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 raportowania. To źródło danych pochodzi z domeny jednego z adresów URL rejestracji serwera.

Zmiany dotyczące technologii reklamowych

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 dotyczące konwersji zarówno w aplikacji, jak i w witrynie. Jeśli dostawcy technologii reklamowych nie chcą dopasowywać danych o wyzwalaczach i kluczy-wartości w przypadku stron internetowych i aplikacji, mogą rozróżniać konwersje w internecie i w 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 „Zmiany 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 aplikacji niebędącej przeglądarką:

Przykład rejestracji źródła i aktywatorów w przeglądarce i 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.
• W 2. dniu 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 Attribution Reporting 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 aktywatora z komponentu 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() dla rejestracji zdarzeń, co powoduje powiązanie zdarzenia z pochodzeniem najwyższego poziomu. Komponent 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ę z systemem operacyjnym tylko w ramach nagłówka Attribution-Reporting-Eligible, jeśli interfejs Attribution Reporting API na Androida jest dostępny. 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 wywołań 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.

Uwaga: aby umożliwić WebViews korzystanie z interfejsu Attribution Reporting API, musisz skonfigurować aplikację do umieszczania z odpowiednimi uprawnieniami.

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 reklamy. 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 przeglądarce), 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. Poniżej znajdziesz przykład przejścia z aplikacji do witryny, w którym źródło znajduje się w aplikacji wydawcy, ale wyzwalacz występuje w witrynie reklamodawcy w aplikacji przeglądarki.

Aby włączyć raportowanie debugowania skuteczności powiązań w przypadku ścieżek „aplikacja–strona internetowa”, muszą być spełnione wszystkie 3 warunki wymienione poniżej:

• 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ć kolumnę source_debug_key, kolumna source_debug_key jest uwzględniana, jeśli identyfikator reklamy jest dostępny dla aplikacji wydawcy.

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

Uwaga: jeśli obsługujesz atrybucję w wielu aplikacjach i w internecie za pomocą danych innych niż identyfikator reklamy, skontaktuj się z nami, aby przedstawić swój przypadek użycia i ubiegać się o uczestnictwo w programie zaufanych testerów. Program zaufanych testerów umożliwia alternatywne otrzymywanie tych samych raportów przejściowych dotyczących debugowania, co opisane w poprzedniej sekcji. Program zaufanych testerów jest dostępny tylko dla dostawców technologii reklamowych, którzy wykazują potrzebę korzystania z tej funkcji, gdy jest ona obsługiwana, ale dostawca nie może udostępnić identyfikatora reklamy w przypadku rejestracji źródła i wyzwalacza.

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 aplikacji i sieci 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 przypadku aplikacji i sieci.

W propozycji Piaskownicy prywatności dla internetu znajdziesz przykład integracji przeglądarek z interfejsem Attribution Reporting API na Androida, która umożliwia pomiar w wielu 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.
• Jeśli jest dostępny, zespół pomocy technicznej może 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, technologia reklamowa powinna 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 zmianami:

• 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 z usługą 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.

Rejestracja wywołania (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. aplikacji, 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 metodę registerWebTrigger() czy registerTrigger().

Dostępne opcje setAttributionRegistrationBehavior:

Wartość	Opis	Przykładowy przypadek użycia
APP_SOURCE_AND_WEB_TRIGGER (domyślnie)	Pozwala aplikacjom rejestrować źródła aplikacji (źródła powiązane z nazwą pakietu aplikacji) i wyzwalacze internetowe (wyzwalacze powiązane z eTLD+1) z WebView.	aplikacje, które używają WebView do wyświetlania reklam, a nie do przeglądania internetu;
WEB_SOURCE_AND_WEB_TRIGGER	Umożliwia aplikacjom rejestrowanie źródeł internetowych i wyzwalaczy internetowych z WebView. Uwaga: aplikacje korzystające z tej opcji muszą zostać dodane do listy dozwolonych.registerWebSource()	Aplikacje przeglądarkowe oparte na WebView, w których przypadku wyświetlenia reklam i konwersje mogą występować w witrynach w komponencie WebView.
APP_SOURCE_AND_APP_TRIGGER	Umożliwia aplikacjom rejestrowanie źródeł i wyzwalaczy aplikacji z WebView.	aplikacje oparte na WebView, w których przypadku wyświetlenia reklam i konwersje powinny być zawsze powiązane z aplikacją, a nie z eTLD+1 WebView;
WYŁĄCZONE	Wyłącza rejestrowanie źródła i wyzwalacza z WebView. Pamiętaj, że początkowe wywołanie sieci do źródła atrybucji lub wywołującego adresu URI może się nadal odbywać, ale każda odpowiedź zostanie odrzucona i nic nie zostanie zapisane na urządzeniu.

Uwaga: setAttributionRegistrationBehavior dotyczy każdej implementacji WebView w każdej aplikacji. Jeśli Twoja aplikacja obsługuje wiele WebView, możesz dla każdego z nich ustawić inne zachowanie. setAttributionRegistrationBehavior nie zapobiega rejestracji ani nie zmienia źródła lub wyzwalacza rejestracji z aplikacji ani z innej aplikacji.

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

Wpływ na mechanizmy ochrony prywatności stosowane w raportach

Jak opisano w głównej propozycji interfejsu API, w raportach stosuje on limity 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 szybkości, atakujący może wykorzystać limity szybkości dotyczące aplikacji oprócz limitów szybkości interfejsu API. Aby temu zapobiec, aplikacje powinny się upewnić, że dane źródło atrybucji nie jest zarejestrowane zarówno w rozwiązaniu do pomiarów aplikacji, jak i w interfejsie Android Attribution Reporting API.

Zdobywanie zaufania w kontekście internetowym

W przypadku wywołań interfejsu API w kontekście sieci interfejs API ufa aplikacji, która wykryje i określi źródło i miejsce 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. Wypełnij formularz rejestracyjny do raportowania atrybucji „z sieci do aplikacji”, aby dodać adres registerWebSource() do listy dozwolonych.

Każda aplikacja może wywołać funkcję registerWebTrigger(), ponieważ kwestie prywatności i bezpieczeństwa 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, aplikacja powinna je ocenić i określić, czy wywołać interfejsy API kontekstu sieci.

Dodatkowo udostępnimy nowe wywołanie interfejsu API z aplikacji, które umożliwia usuwanie źródeł atrybucji, wyzwalaczy i oczekujących raportów przechowywanych na urządzeniu w przypadku danej 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 aplikacjami 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 ich 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ła) 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.