Raportowanie atrybucji: pomiary obejmujące wiele aplikacji i witryn

Uwaga: ten dokument odzwierciedla obecne propozycje projektowe Piaskownicy prywatności na Androidzie i może jeszcze ulec zmianie. Zachęcamy do przesyłania opinii i komentarzy, które pomogą nam w tych działaniach.

Przesłać opinię

Ostatnie aktualizacje

• Dodaliśmy sekcję poświęconą raportom na temat przejściowego debugowania.
• Dodaliśmy instrukcje dotyczące dołączania do listy dozwolonych w celu zarejestrowania źródeł internetowych.

Zgodnie z opisem w ofercie pakietowej interfejsu Attribution Reporting API interfejs API umożliwia atrybucję następujących ścieżek reguł na pojedynczym urządzeniu z Androidem:

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

Internet to tutaj zawartość internetowa wyświetlana w aplikacji. Treści internetowe mogą być wyświetlane w kontekście aplikacji w przeglądarce mobilnej lub jako osadzone witryny widoczne w aplikacjach innych niż przeglądarki.

Poprzednie ścieżki aktywatorów spełniają te wymagania:

• Dla technologii reklamowych: aktualizacje wywołań interfejsu API i raportowania w celu przejścia z aplikacji do witryny
• Aplikacje i przeglądarki: możliwość przekazywania rejestracji źródeł atrybucji i reguł internetowych

W tym dokumencie wyjaśniamy, w jaki sposób poszerzyliśmy interfejs Attribution Reporting API o obsługę ścieżek aktywatorów „z aplikacji do witryny”, z witryny do aplikacji oraz z witryny do witryny. Opisano w nim również zmiany, jakie muszą wprowadzić technologie reklamowe i aplikacje, aby spełnić wymagania dotyczące obsługi tych ścieżek reguł.

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 Rejestrowanie konta Piaskownicy prywatności.

Po zakończeniu procesu rejestracji interfejs API odrzuci rejestrację w przypadku otrzymania niezarejestrowanego wywołania rejestracji.

Podczas rejestracji platformy technologii reklamowych powinny się upewnić, że rejestrują się ze wszystkimi adresami URL serwerów, których mogą używać w aplikacjach i internecie do rejestrowania źródeł i reguł atrybucji. Obsługiwanych jest wiele adresów URL do rejestracji serwera, ale tylko jedno źródło raportowania jest obsługiwane. To źródło raportowania 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 technologie reklamowe obecnie określają pole docelowe, czyli nazwę pakietu aplikacji, w którym występuje zdarzenie aktywujące. Aby umożliwić pomiary pomiędzy aplikacją a stroną, planujemy obsługiwać 1 pole miejsca docelowego aplikacji (nazwa pakietu aplikacji) i 1 pole miejsca docelowego w internecie (eTLD + 1).

W przypadku rejestrowania źródeł atrybucji lub reguł atrybucji internetowej interfejs API nie obsługuje przekierowań, ponieważ każda aplikacja hostująca treści internetowe może mieć własny model uprawnień. Każda aplikacja odpowiada za śledzenie przekierowań (jeśli są obsługiwane) i wywoływanie interfejsów API kontekstu internetowego w przypadku każdego przeskoku.

Dodatkowo ta integracja umożliwia technikom reklamowym korzystanie w przypadku internetowych źródeł atrybucji z konkretnej aplikacji. Możesz np. określić okna atrybucji po instalacji w internetowym źródle atrybucji.

Otrzymuj raporty z aplikacji i witryny

Interfejs Android Attribution Reporting API może wysyłać raporty dotyczące konwersji w aplikacjach i w witrynie. Jeśli technologie reklamowe nie chcą dopasowywać danych dotyczących reguł do par klucz-wartość agregacji na platformach internetowych i w aplikacjach, mogą wprowadzić rozróżnienie między konwersją w witrynie a konwersją z aplikacji:

• W przypadku raportów na poziomie zdarzenia obsługujemy pole docelowe, które określa, czy reguła miała miejsce w witrynie (miejsce docelowe to eTLD + 1) czy aplikacja (miejsce docelowe to nazwa pakietu aplikacji)
• W raportach zbiorczych miejsce docelowe jest wysyłane w postaci tekstu nieszyfrowanego.

Konsekwencje pomiaru konwersji z witryny do sieci

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

• Czy interfejs Attribution Reporting API jest dostępny na tym urządzeniu? Udostępnimy aplikacjom nowy sygnał, który wskazuje, czy interfejs Attribution Reporting API jest dostępny na danym urządzeniu. Więcej informacji o tym, jak aplikacje mogą przekazywać rejestrację do interfejsu Attribution Reporting API, znajdziesz w sekcji zmian w aplikacji.
• Jaką część źródeł atrybucji i reguł atrybucji należy przekazywać do interfejsu API? Decyzję podejmuje każda aplikacja lub technologia reklamowa, jeśli zezwala na to aplikacja. Jeśli aplikacja ma własne rozwiązanie analityczne, może je rozważyć. Ostatecznie przekazywanie wszystkich rejestracji źródeł i reguł do interfejsu Android Attribution Reporting API (o ile jest dostępne) umożliwia najdokładniejsze przypisywanie w aplikacjach i internecie.

Ten przykład pokazuje, jak aplikacje przeglądarki mogą współpracować z interfejsem Attribution Reporting API, aby zapewniać precyzyjne pomiary, gdy użytkownik klika reklamę zarówno w przeglądarce, jak i w aplikacji innej niż przeglądarka:

Przykład rejestracji źródła i aktywatora w przeglądarce i aplikacji

• Pierwszego dnia użytkownik klika reklamę w aplikacji przeglądarki.
  • Aplikacja przeglądarki może użyć własnego rozwiązania analitycznego lub zarejestrować kliknięcie reklamy internetowej w interfejsie Attribution Reporting API.
• Drugiego dnia użytkownik klika reklamę w aplikacji, która nie jest przeglądarką.
  • Kliknięcie jest rejestrowane jako źródło atrybucji przez interfejs API. Aplikacja przeglądarki nie ma wglądu w to kliknięcie, ponieważ zdarzenie wystąpiło w innej aplikacji.
• trzeciego dnia użytkownik dokonuje konwersji w aplikacji przeglądarki,
  • Jeśli aplikacja przeglądarki rejestruje kliknięcia i konwersje za pomocą własnego rozwiązania pomiarowego i przekazuje te informacje do interfejsu Attribution Reporting API, mało prawdopodobne jest, że technologia reklamowa usunie duplikaty raportów o konwersjach z różnych rozwiązań pomiarowych. Dodatkowo technologia reklamowa może wykorzystywać zarówno limity szybkości aplikacji przeglądarki, jak i limity szybkości interfejsu Attribution Reporting API. Dlatego zalecamy, aby aplikacje przekazywały wszystkie zdarzenia reklamowe i konwersje, rejestrując je w interfejsie API, gdy jest on dostępny.

Zarejestruj źródło atrybucji i aktywację z komponentu WebView

Jeśli do wyświetlania treści internetowych zamiast natywnej reklamy na Androida aplikacja korzysta z komponentu WebView, może ona przesłać prośbę o dołączenie do listy dozwolonych witryny registerWebSource() i podać jej źródło najwyższego poziomu, które będzie powiązane ze źródłem atrybucji, a nie z nazwą pakietu aplikacji.

Podobnie jak przeglądarki, WebView obsługuje funkcję registerWebTrigger() na potrzeby rejestracji aktywatorów, która wiąże regułę ze źródłem najwyższego poziomu. Komponent WebView nie obsługuje rejestrowania aktywatora aplikacji. Skontaktuj się z nimi, jeśli masz odpowiedni przypadek użycia. Pełną listę kombinacji obsługiwanych przez WebView znajdziesz w artykule Rejestrowanie źródła atrybucji i reguły w komponencie WebView.

W przeciwieństwie do przeglądarek komponent WebView obsługuje rejestrację z systemem operacyjnym w nagłówku Attribution-Reporting-Eligible tylko wtedy, gdy dostępny jest interfejs Attribution Reporting API na Androida. Jeśli interfejs Attribution Reporting API na Androida jest niedostępny, komponent WebView nie ustawia nagłówka Attribution-Reporting-Eligible i nie przeprowadza się rejestracji.

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

• Technicy reklamowi powinni odpowiadać na rejestracje źródeł za pomocą nagłówka Attribution-Reporting-Register-OS-Source, który inicjuje dodatkowe wywołanie interfejsu API z komponentu WebView do registerSource() lub registerWebSource().
• Technologie reklamowe mogą też odpowiadać na rejestracje przy użyciu nagłówka Attribution-Reporting-Register-OS-Trigger, który inicjuje dodatkowe wywołanie interfejsu API z komponentu WebView do registerWebTrigger() lub registerTrigger().

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

Aby dowiedzieć się, czy komponent WebView będzie wykorzystywał registerSource() / registerWebSource() i registerTrigger() / registerWebTrigger() (a także jak zmienić to działanie), przeczytaj artykuł Źródło atrybucji i uruchamianie rejestracji z WebView.

Raporty debugowania na temat przejścia

Interfejs Attribution Reporting API obsługuje opcjonalną funkcję o nazwie przejściowe raporty debugowania, która umożliwia technikom reklamowym uzyskiwanie dodatkowych informacji o raportach atrybucji, gdy dostępny jest identyfikator wyświetlania reklam. Istnieją 2 rodzaje raportów debugowania: Atrybucja-sukces i wyczerpujący. Raporty te są obsługiwane w przypadku atrybucji obejmującej różne aplikacje i witryny. Oba typy raportów zawierają te same informacje, a jedyna różnica dotyczy uprawnień, które są brane pod uwagę podczas wysyłania raportów z debugowania.

W przypadku atrybucji z witryny do witryny, która ma miejsce w ramach pojedynczej aplikacji (np. w tej samej aplikacji przeglądarki), raporty o udanej atrybucji i szczegółowe raporty są dostępne tylko wtedy, gdy dostępne są pliki cookie innych firm i nie zależą od dostępności identyfikatora wyświetlania reklam.

W przypadku atrybucji „z aplikacji do witryny”, „z internetu do aplikacji” i z internetu w różnych aplikacjach dostępne są raporty o sukcesie atrybucji i szczegółowe raporty, jeśli identyfikator AdID jest dostępny po stronie aplikacji, a technologia reklamowa może przekazywać ten sam (prawidłowy) identyfikator AdID na stronie internetowej. Poniżej znajduje się przykład połączenia z aplikacji do witryny, w którym źródło występuje w aplikacji wydawcy, a reguła – na stronie reklamodawcy w aplikacji przeglądarki.

Aby wygenerować raport z debugowania atrybucji zakończonego sukcesem w przypadku konwersji z aplikacji do witryny, trzeba spełnić wszystkie te 3 warunki:

• użytkownik nie może zrezygnować z personalizacji przy użyciu identyfikatora wyświetlania reklam;
• Aplikacja wydawcy musi mieć zadeklarowane uprawnienia AdID
• Technologia reklamowa musi przekazać wartość AdID w rejestracji reguły (z kontekstu internetowego).

Aby włączyć szczegółowe raporty z debugowania „z aplikacji do internetu”:

• Szczegółowe raporty źródłowe zależą wyłącznie od uprawnień po stronie wydawcy. Aby można było wysyłać szczegółowe raporty źródłowe, użytkownik nie może zrezygnować z personalizacji AdID, a aplikacja wydawcy musi mieć zadeklarowane uprawnienia dotyczące identyfikatora AdID.
• Raporty szczegółowe zależą wyłącznie od uprawnień aktywatora (w tym przypadku witryny). Aby umożliwić wysyłanie szczegółowych raportów, w przeglądarce muszą być dostępne pliki cookie innych firm.
• W raportach szczegółowych, które mogą opcjonalnie zawierać element source_debug_key, używany jest element source_debug_key, o ile aplikacja wydawcy ma dostęp do identyfikatora wyświetlania reklam.

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

Uwaga: jeśli obsługujesz atrybucję w różnych aplikacjach i internecie za pomocą danych innych niż identyfikator wyświetlania reklam, skontaktuj się z Tobą, aby przesłać zgłoszenie do programu Zaufany tester. Program Zaufany tester obsługuje alternatywny sposób otrzymywania takich samych przejściowych raportów debugowania, jak opisano powyżej. Program dla zaufanych testerów jest ograniczony do technologii reklamowych o udowodnionej potrzebie, w przypadku których dany przypadek użycia jest obsługiwany, ale technologia reklamowa nie jest w stanie podać identyfikatora wyświetlania reklam z różnych źródeł i z reguły rejestracji.

Zmiany w aplikacjach

Będziemy obsługiwać atrybucję w aplikacjach i na stronach internetowych, umożliwiając aplikacjom przekazywanie rejestracji źródeł atrybucji i reguł internetowych do interfejsu Attribution Reporting API na Androida za pomocą nowego zestawu wywołań interfejsu API kontekstu.

Po wykonaniu czynności rejestracji opisanych w poniższych sekcjach na urządzeniu będą przechowywane źródła i reguły atrybucji z aplikacji i internetu, a interfejs Attribution Reporting API może przeprowadzać atrybucję ostatniego punktu kontaktu z perspektywy źródła w aplikacjach i internecie.

W ofercie Piaskownicy prywatności w internecie znajdziesz przykład tego, jak przeglądarki mogą integrować się z interfejsem Attribution Reporting API na Androida, aby umożliwić pomiary w różnych aplikacjach i witrynach. W ofercie pakietowej przeglądarka doda te nagłówki żądania:

• Attribution-Reporting-Eligible informuje, czy dostępna jest obsługa atrybucji na poziomie systemu operacyjnego. W tym przypadku nagłówek wskazuje, czy dostępny jest interfejs Attribution Reporting API na Androida.
• Jeśli to możliwe, technologie reklamowe mogą opcjonalnie odpowiedzieć za pomocą polecenia Attribution-Reporting-Register-OS-Source, który inicjuje dodatkowe wywołanie interfejsu API w aplikacji przeglądarki do interfejsu registerWebSource().
• Technologie reklamowe mogą też reagować na uruchamianie rejestracji przy użyciu nagłówka Attribution-Reporting-Register-OS-Trigger, który inicjuje dodatkowe wywołanie interfejsu API z aplikacji przeglądarki do interfejsu registerWebTrigger().

Rejestracja źródła atrybucji

Po zarejestrowaniu źródła atrybucji aplikacje mogą wywoływać metodę registerWebSource(), która wymaga 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 towarzyszyć flagie logicznej Debug wskazująca, czy w raporcie powinny zostać uwzględnione klucze debugowania dostarczone przez specjalistów.
• Zdarzenie wejściowe: obiekt InputEvent (w przypadku zdarzenia kliknięcia) lub null (w przypadku zdarzenia wyświetlenia).
• Źródło źródła: źródło, w którym wystąpiło źródło (witryna wydawcy).
• OS destination (Miejsce docelowe systemu operacyjnego): nazwa pakietu aplikacji, w którym zachodzi zdarzenie aktywujące.
• Miejsce docelowe w witrynie: adres eTLD + 1, w którym zachodzi zdarzenie aktywujące.
• Zweryfikowane miejsce docelowe: intencja URI miejsca docelowego w systemie operacyjnym lub sieci służącym do nawigacji po kliknięciu przez użytkownika.

Gdy interfejs API wysyła żądanie do identyfikatora URI źródła atrybucji, technika reklamowa powinna odpowiedzieć, podając metadane źródła atrybucji w nagłówku HTTP Attribution-Reporting-Register-Source. Ten nagłówek zawiera te same pola co rejestracja źródła atrybucji między aplikacją, ale z kilkoma zmianami:

• Interfejs API weryfikuje miejsca docelowe określone przez technologię reklamową 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 sieci przed wywołaniem interfejsu webcontext API. W przypadku kliknięć aplikacje powinny sprawdzać, czy określone miejsce docelowe odpowiada temu, do którego prowadzi użytkownik.
• Interfejs API ignoruje wszystkie identyfikatory URI przekierowania podane w Attribution-Reporting-Redirects. Aplikacje powinny samodzielnie śledzić przekierowania i w przypadku każdego przekierowania wywoływać metodę registerWebSource(), aby w razie potrzeby można było zastosować własne zasady uprawnień.

Aby móc wywoływać aplikację registerWebSource(), aplikacje muszą zostać umieszczone na liście dozwolonych. Aby dołączyć do listy dozwolonych, wypełnij ten formularz. Tworzenie listy dozwolonych ma na celu ograniczenie kwestii związanych z prywatnością w zakresie budowania zaufania do kontekstu internetowego.

Rejestracja aktywatora (konwersji)

Podczas rejestracji aktywatora aplikacje mogą wywoływać metodę registerWebTrigger(), która wymaga tych parametrów:

• Identyfikatory URI aktywatorów: platforma wysyła żądanie do każdego identyfikatora URI z tej listy, aby pobrać metadane powiązane z regułą.
• Miejsce docelowe: miejsce, w którym wystąpiła reguła (witryna reklamodawcy).

Źródło atrybucji i rejestracja aktywatora z WebView

Domyślnie WebView będzie korzystać z registerSource() i registerWebTrigger(). Powoduje to powiązanie źródeł z aplikacją i aktywuje je ze źródłem najwyższego poziomu komponentu WebView w chwili wystąpienia aktywatora.

Jeśli aplikacja wymaga innego działania (np. udostępnia treści internetowe w komponencie WebView), musi użyć metody setAttributionRegistrationBehavior w klasie androidx.webkit.WebViewSettingsCompat. Ta metoda określa, czy komponent WebView powinien wywoływać metodę registerWebSource() czy registerSource() oraz registerWebTrigger() lub registerTrigger().

Oto dostępne opcje setAttributionRegistrationBehavior:

Wartość	Opis	Przykładowy przypadek użycia
APP_SOURCE_AND_WEB_TRIGGER (domyślnie)	Umożliwia aplikacjom rejestrowanie źródeł aplikacji (źródeł powiązanych z nazwą pakietu aplikacji) i reguł internetowych (reguł powiązanych z eTLD + 1) z komponentu WebView.	aplikacje, które używają komponentu WebView do wyświetlania reklam, zamiast umożliwiać przeglądanie internetu.
WEB_SOURCE_AND_WEB_TRIGGER	Zezwala aplikacjom na rejestrowanie źródeł internetowych i aktywatorów internetowych z WebView. Uwaga: aplikacje korzystające z tej opcji będą musiały zostać umieszczone na liście dozwolonych, aby móc używać usługi registerWebSource().	aplikacji przeglądarek opartych na WebView, w przypadku których wyświetlenia reklam i konwersje mogą mieć miejsce w witrynach w komponencie WebView.
APP_SOURCE_AND_APP_TRIGGER	Zezwala aplikacjom na rejestrowanie źródeł aplikacji i aktywatorów aplikacji z WebView.	aplikacje oparte na WebView, w których wyświetlenia reklam i konwersje powinny być zawsze powiązane z aplikacją, a nie z domeną eTLD + 1 komponentu WebView.
WYŁĄCZONA	Wyłącza źródło i aktywuje rejestrację z komponentu WebView. Pamiętaj, że początkowe wywołanie sieciowe dotyczące identyfikatorów URI źródła atrybucji lub aktywatorów może być nadal wykonywane, ale każda odpowiedź jest odrzucana i nie zostanie zapisane na urządzeniu.

Uwaga: setAttributionRegistrationBehavior ma zastosowanie do każdej implementacji komponentu WebView w każdej aplikacji. Jeśli Twoja aplikacja obsługuje wiele komponentów WebView, możesz ustawić różne zachowania dla każdego z nich. setAttributionRegistrationBehavior nie blokuje ani nie zmienia źródła ani nie aktywuje rejestracji w samej aplikacji ani w żadnej innej aplikacji.

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

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

Zgodnie z opisem w głównej ofercie projektu interfejs API stosuje do raportów ograniczenia stawek chroniące prywatność. Niektóre limity są podzielone między aplikacje źródłowe i docelowe. Po zarejestrowaniu źródła lub aktywatora atrybucji internetowej limit częstotliwości jest partycjonowany według witryny źródłowej lub docelowej, a nie według aplikacji.

Jeśli w aplikacji obowiązują oddzielne limity liczby żądań, przeciwnik mógłby zastosować limity stawek specyficzne dla aplikacji oprócz limitów szybkości stosowanych w interfejsie API. Aby temu zaradzić, aplikacje powinny się upewnić, że dane źródło atrybucji nie jest zarejestrowane zarówno w rozwiązaniu pomiarowym aplikacji, jak i w interfejsie Android Attribution Reporting API.

Wzbudzaj zaufanie w kontekście internetowym

W wywołaniach interfejsu API w kontekście internetowym interfejs API nadaje aplikacji zaufanie w celu wykrywania i określania źródła źródłowego i docelowego. Może się to wiązać z potencjalnymi kwestiami ochrony prywatności i bezpieczeństwa:

• przeciwnik może twierdzić, że hostuje własne witryny, aby ominąć limity szybkości dotyczące ilości informacji, które może przesyłać każde źródło.
• Wielu przeciwników może z powodzeniem zarejestrować osobne źródła atrybucji i zgłosić prawa do tej samej witryny źródłowej. W rezultacie witryna źródłowa może osiągnąć limity stawek na platformie technologii reklamowych, przez co witryna źródłowa nie będzie rejestrować prawidłowych źródeł atrybucji.

Aby temu zaradzić, ograniczymy liczbę przeglądarek i aplikacji, które mogą wywoływać registerWebSource() do przeglądarek lub aplikacji, które potwierdzają, że witryna źródłowa użyta podczas rejestracji reprezentuje witrynę wyświetlaną użytkownikowi. Wypełnij ten formularz, aby dołączyć do listy dozwolonych i zadzwonić pod numer registerWebSource().

Każda aplikacja może wywołać metodę registerWebTrigger(), ponieważ kwestie dotyczące prywatności i bezpieczeństwa po stronie reguły nie są stosowane bez współpracy po stronie źródła.

Kontrola użytkowników

Aplikacje mogą nadal obsługiwać opcje kontroli i zasady uprawnień użytkowników, o ile można je zdefiniować w trakcie rejestracji. Jeśli na przykład aplikacja zezwala na dowolne uprawnienia na poziomie witryny lub użytkownika, powinna je ocenić i określić, czy wywołać interfejsy API kontekstu internetowego.

Wprowadzimy też nowe wywołanie interfejsu API w aplikacjach, aby usunąć wszelkie źródła atrybucji, reguły i oczekujące raporty dotyczące danej aplikacji zapisane na urządzeniu. Jeśli na przykład aplikacje umożliwiają użytkownikowi wyczyszczenie historii przeglądania, mogą wywołać interfejs API, aby usunąć zapisane na urządzeniu źródła atrybucji, reguły i oczekujące raporty dotyczące danej aplikacji.

Uwagi na przyszłość i pytania otwarte

Pracujemy nad interoperacyjnością między aplikacją a internetem przez Attribution Reporting API. Prosimy o opinie społeczności dotyczące kilku pomysłów:

1. W jaki sposób na urządzeniu obsługującym Piaskownicę prywatności na Androida będziesz używać rozwiązań pomiarowych w przeglądarce z interfejsem Android Attribution Reporting API? Czy wolisz przekazać wszystko do Androida?
2. Czy masz jakieś obawy związane z potencjalnym otrzymywaniem 2 pingów dla każdego źródła i reguły atrybucji – po jednym z przeglądarki lub aplikacji, a drugim z interfejsu Attribution Reporting API?
3. Jak możemy ułatwić debugowanie różnych interfejsów API?
4. Oferta nie obejmuje potwierdzenia, że miejsca docelowe w aplikacji i w sieci są powiązane. W przyszłości być może uda nam się zweryfikować te miejsca docelowe, sprawdzając powiązania za pomocą Digital Asset Links. Czy to zablokuje którekolwiek z Państwa przypadków użycia? Czy w tym celu warto użyć linków do zasobów cyfrowych?
5. Przy rejestrowaniu źródła atrybucji musisz podać miejsce docelowe. W przypadku konwersji z witryny do aplikacji możesz podać link do aplikacji. Jakich formatów używasz, aby określić link do aplikacji?
6. Przy rejestrowaniu źródła atrybucji opartej na aplikacji do witryny należy zarejestrować to zdarzenie źródłowe z poziomu aplikacji za pomocą interfejsu Android Attribution Reporting API. Jeśli np. użytkownik kliknie reklamę i kliknięcie zostanie otwarte w przeglądarce lub na karcie niestandardowej, kliknięcie to (zdarzenie źródłowe) powinno zostać zarejestrowane w aplikacji, a nie w kontekście przeglądarki. Skontaktuj się z nami, jeśli masz wątpliwości dotyczące tej kwestii lub jeśli istnieją inne przypadki użycia, które nie należą do kategorii opisanych w tym problemie z opisem obsługiwanych procesów.