Raportowanie atrybucji: pomiary obejmujące wiele aplikacji i witryn

Ostatnie aktualizacje

Ścieżki wyzwalania

Zgodnie z propozycją projektu interfejsu Attribution Reporting API interfejs API umożliwia przypisywanie tych ścieżek wyzwalania na jednym urządzeniu z Androidem: Sieć to: (1) samodzielna przeglądarka działająca 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 w 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 następnie dokonuje konwersji w aplikacji.
  • Web-to-web: użytkownik widzi reklamę w internecie, a następnie dokonuje konwersji w internecie.

Powyższe ścieżki wyzwalacza przekładają się na te wymagania:

  • Dla dostawców technologii reklamowych: aktualizacje wywołań interfejsu API i raportowania, które umożliwiają ścieżki od aplikacji do witryny.
  • W przypadku aplikacji i przeglądarek: możliwość przekazywania do Androida rejestracji internetowych źródeł atrybucji i wyzwalaczy internetowych.

Z tego dokumentu dowiesz się, jak rozszerzyć interfejs Attribution Reporting API, aby obsługiwał ścieżki wyzwalania z aplikacji do witryny, z witryny do aplikacji i z witryny do witryny. Opisuje też zmiany, które muszą wprowadzić technologie reklamowe i aplikacje, aby spełnić wymagania dotyczące obsługi tych ścieżek wyzwalania.

Uzyskiwanie dostępu do interfejsów Attribution Reporting API

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

Po zakończeniu procesu rejestracji interfejs API odrzuci rejestrację, jeśli otrzyma wywołanie niezarejestrowanej rejestracji.

Podczas rejestracji platformy technologii reklamowych powinny podać wszystkie adresy URL serwerów, których mogą używać w aplikacjach i internecie do rejestrowania źródeł i wyzwalaczy atrybucji. Obsługiwanych jest wiele adresów URL rejestracji serwera, ale tylko jedno źródło raportowania. To źródło raportowania pochodzi z domeny jednego z adresów URL rejestracji serwera.

Zmiany dla dostawców technologii reklamowych

W tej sekcji omawiamy zmiany dla technologii reklamowych korzystających z interfejsu Attribution Reporting API.

Zmiany w rejestracji i atrybucji

Podczas rejestrowania źródła atrybucji dostawcy technologii reklamowych określają pole docelowe, które jest nazwą pakietu aplikacji, w której występuje zdarzenie wyzwalające. Aby włączyć pomiary 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ł lub wyzwalaczy 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 jest odpowiedzialna za śledzenie przekierowań (jeśli są obsługiwane) i wywoływanie interfejsów API kontekstu internetowego w przypadku każdego przekierowania.

Ta integracja umożliwia też technologiom reklamowym korzystanie z logiki atrybucji w aplikacji w przypadku źródeł atrybucji w internecie. Możesz na przykład określić okresy atrybucji po instalacji w przypadku internetowego źródła atrybucji.

Otrzymywanie raportów o aplikacjach i witrynach

Interfejs Attribution Reporting API na Androidzie może wysyłać raporty o konwersjach w aplikacjach i w internecie. Jeśli dostawcy technologii reklamowych nie chcą dopasowywać danych wywołujących i wartości kluczy agregacji w przypadku witryn i aplikacji, mogą rozróżniać konwersje w witrynach i aplikacjach:

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

Konsekwencje pomiarów w przypadku przejść z reklamy do witryny

Aplikacje decydują, kiedy przekazać rejestrację do interfejsu Attribution Reporting API. W tym przypadku 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 będzie informować, 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 dotyczącej zmian w aplikacjach.
  • Jaką część źródeł i wyzwalaczy atrybucji należy przekazać do interfejsu API? Decyzję podejmuje każda aplikacja lub technologia reklamowa, jeśli aplikacja zezwala na wybór. Jeśli aplikacja ma własne rozwiązanie analityczne, warto rozważyć jego użycie. Przekazywanie wszystkich rejestracji źródeł i wyzwalaczy do interfejsu Android Attribution Reporting API, gdy jest on dostępny, umożliwia najdokładniejszą atrybucję w aplikacjach i internecie.

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

Przykłady kliknięć i konwersji użytkowników w okresie 3 dni.
Przykład rejestracji źródła i aktywatora w przeglądarce i aplikacji
  • Dnia 1 użytkownik klika reklamę w aplikacji przeglądarki.
    • Aplikacja przeglądarki może używać własnego rozwiązania pomiarowego lub przekazywać rejestrację kliknięcia reklamy w internecie do interfejsu Attribution Reporting API.
  • Dnia 2 użytkownik klika reklamę w aplikacji innej niż przeglądarka.
    • Kliknięcie jest rejestrowane jako źródło atrybucji w interfejsie API. Przeglądarka nie ma wglądu w to kliknięcie, ponieważ zdarzenie wystąpiło w innej aplikacji.
  • Dzień 3: użytkownik dokonuje konwersji w aplikacji w przeglądarce.
    • Jeśli aplikacja przeglądarki rejestruje kliknięcie i konwersję za pomocą własnego rozwiązania pomiarowego i przekazuje te informacje do interfejsu Attribution Reporting API, jest mało prawdopodobne, że dostawca technologii reklamowych będzie w stanie usunąć duplikaty raportów o konwersjach w różnych rozwiązaniach pomiarowych. Technologia reklamowa może też wykorzystywać limity liczby żądań zarówno w aplikacji przeglądarki, jak i w interfejsie Attribution Reporting API. Dlatego zalecamy, aby aplikacje przekazywały wszystkie zdarzenia reklamowe i konwersje do zarejestrowania w interfejsie API, gdy jest on dostępny.

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

Jeśli aplikacja używa komponentu WebView do wyświetlania treści internetowych zamiast reklam na Androida, może zgłosić się do dodania do listy dozwolonychregisterWebSource() i podać źródło 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 wyzwalaczy, co powoduje powiązanie wyzwalacza z źródłem najwyższego poziomu. Nie ma obsługi komponentu WebView do rejestrowania wyzwalacza aplikacji. Jeśli masz przypadek użycia, w którym jest to potrzebne, skontaktuj się z nami. Pełną listę kombinacji obsługiwanych przez WebView znajdziesz w artykule Rejestrowanie źródła atrybucji i wyzwalacza w WebView.

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

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

  • Technologie reklamowe powinny odpowiadać na rejestracje źródła za pomocą nagłówka Attribution-Reporting-Register-OS-Source, który inicjuje dodatkowe wywołanie interfejsu API z widoku WebView do registerSource() lub 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 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 internet nie jest obsługiwany, cała rejestracja zakończy się niepowodzeniem.

Szczegółowe informacje o tym, czy komponent WebView będzie używać registerSource() / registerWebSource() i registerTrigger() / registerWebTrigger() (oraz jak zmienić to zachowanie), znajdziesz w artykule Rejestrowanie źródła atrybucji i wyzwalacza w komponencie WebView.

Raporty debugowania przejściowego

Interfejs Attribution Reporting API obsługuje opcjonalną funkcję raportów debugowania przejściowego, która umożliwia dostawcom technologii reklamowych uzyskiwanie więcej informacji o raportach atrybucji, gdy dostępny jest identyfikator wyświetlania reklam. Dostępne są 2 typy raportów debugowania: attribution-success i verbose. Te raporty są obsługiwane w przypadku atrybucji w aplikacjach i w internecie. Oba typy raportów zawierają te same informacje. Jedyna różnica dotyczy uprawnień, które określają, kiedy wysyłane są raporty debugowania.

W przypadku atrybucji typu „witryna – witryna” 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. Nie są one oparte na dostępności identyfikatora reklamowego.

W przypadku atrybucji w aplikacjach (aplikacja – witryna, witryna – aplikacja i witryna – witryna) dostępne są raporty o skuteczności atrybucji i raporty szczegółowe, jeśli po stronie aplikacji dostępny jest identyfikator reklamowy, a technologia reklamowa może przekazać ten sam (prawidłowy) identyfikator reklamowy po stronie internetowej.

W późniejszym przykładzie dotyczącym przejścia z aplikacji do sieci źródło występuje w aplikacji wydawcy, ale wyzwalacz pojawia się w witrynie reklamodawcy w aplikacji przeglądarki.

Aby włączyć raport debugowania dotyczący przypisywania w przypadku przejścia z aplikacji do witryny, należy 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 przekazywać wartość identyfikatora reklamy podczas rejestracji wyzwalacza (z kontekstu internetowego).

Aby włączyć szczegółowe raporty debugowania dotyczące przejść z aplikacji do witryny:

  • Szczegółowe raporty o źródłach zależą tylko od uprawnień po stronie wydawcy. Aby wysyłać szczegółowe raporty o źródłach, użytkownik nie może zrezygnować z personalizacji za pomocą identyfikatora reklamowego, a aplikacja wydawcy musi deklarować uprawnienia do identyfikatora reklamowego.
  • Wyzwalanie szczegółowych raportów zależy tylko od uprawnień po stronie wyzwalacza (w tym przykładzie – witryny). Aby wysyłać szczegółowe raporty o wyzwalaniu, pliki cookie innych firm muszą być dostępne w przeglądarce.
  • W przypadku szczegółowych raportów o wyzwalaniu, które mogą opcjonalnie zawierać source_debug_key, symbol source_debug_key jest uwzględniany, jeśli identyfikator reklamowy 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 rejestracji źródła i wyzwalacza.

Zmiany dotyczące aplikacji

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

Po wykonaniu kroków rejestracji opisanych w kolejnych sekcjach źródła i wyzwalacze atrybucji w aplikacjach i internecie są przechowywane na urządzeniu, a interfejs Attribution Reporting API może przeprowadzać atrybucję według priorytetu źródła i ostatniego kliknięcia na różnych platformach w aplikacjach i internecie.

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

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

Rejestracja źródła atrybucji

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

  • Identyfikatory URI źródła atrybucji: platforma wysyła żądanie do każdego identyfikatora URI na tej liście, aby pobrać metadane powiązane ze źródłem atrybucji.

    Każdemu identyfikatorowi URI powinna towarzyszyć wartość logiczna Debug, która wskazuje, czy w raporcie mają być uwzględnione klucze debugowania dostarczone przez zespoły techniczne.
  • Zdarzenie wejściowe: obiekt InputEvent (w przypadku zdarzenia kliknięcia) lub null (w przypadku zdarzenia wyświetlenia).
  • Pochodzenie źródła: pochodzenie, w którym wystąpiło źródło (witryna wydawcy).
  • Miejsce docelowe systemu operacyjnego: nazwa pakietu aplikacji, w której występuje zdarzenie wywołujące.
  • Miejsce docelowe w internecie: eTLD+1, w którym występuje zdarzenie wywołujące.
  • Zweryfikowane miejsce docelowe: intencja identyfikatora URI miejsca docelowego w systemie operacyjnym lub internecie używana do nawigacji po kliknięciu przez użytkownika.

Gdy interfejs API wyśle żądanie do identyfikatora URI źródła atrybucji, dostawca technologii reklamowych 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 w przypadku atrybucji w aplikacji, 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 internecie przed wywołaniem interfejsu API kontekstu internetowego. W przypadku kliknięć aplikacje powinny sprawdzać, 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 Attribution-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ń.

Aby aplikacje mogły dzwonić na numer registerWebSource(), muszą zostać dodane do listy dozwolonych. Aby dołączyć do listy dozwolonych, wypełnij ten formularz. Celem listy dozwolonych jest ograniczenie kwestii związanych z prywatnością w zakresie budowania zaufania w kontekście internetowym.

Wywoływanie rejestracji (konwersji)

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

  • Identyfikatory URI wywołania: platforma wysyła żądanie do każdego identyfikatora URI na tej liście, aby pobrać metadane powiązane z wywołaniem.
  • Miejsce docelowe: miejsce, w którym wystąpiło wywołanie (witryna reklamodawcy).

Rejestracja źródła atrybucji i wyzwalacza w komponencie WebView

Domyślnie komponent WebView będzie używać wartości registerSource() i registerWebTrigger(). Powiązuje to źródła z aplikacją, a reguły z pochodzeniem najwyższego poziomu elementu WebView, gdy nastąpi wywołanie reguły.

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

Dostępne opcje dla setAttributionRegistrationBehavior:

Wartość Opis 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 wywołań internetowych (wywołań powiązanych z eTLD+1) z WebView. aplikacje, które używają komponentu WebView do wyświetlania reklam zamiast 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 będą musiały złożyć wniosek o dodanie do listy dozwolonych, aby używać registerWebSource().		 Aplikacje przeglądarki oparte na WebView, w których wyświetlenia reklam i konwersje mogą występować w witrynach w WebView.
APP_SOURCE_AND_APP_TRIGGER Umożliwia aplikacjom rejestrowanie źródeł i wyzwalaczy aplikacji z poziomu WebView. Aplikacje oparte na WebView, w których wyświetlenia reklam i konwersje powinny być zawsze powiązane z aplikacją, a nie z eTLD+1 komponentu WebView.
WYŁĄCZONE Wyłącza rejestrację źródła i wyzwalacza w widoku WebView.
Pamiętaj, że początkowe wywołanie sieciowe do adresów URI źródła lub wyzwalacza atrybucji może nadal występować, ale każda odpowiedź jest odrzucana i nic nie jest przechowywane na urządzeniu.

Kwestie związane z 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 na mechanizmy ochrony prywatności stosowane w raportach

Zgodnie z główną propozycją projektu interfejs API stosuje do raportów limity częstotliwości, które chronią prywatność. Niektóre limity są dzielone między aplikacje źródłowe i docelowe. Gdy zarejestrowane jest źródło lub wyzwalacz atrybucji w internecie, limit szybkości jest dzielony według witryny źródłowej lub docelowej, a nie według aplikacji.

Jeśli aplikacja utrzymuje oddzielne limity częstotliwości, przeciwnik może wykorzystać limity częstotliwości specyficzne dla aplikacji oprócz limitów częstotliwości interfejsu API. Aby temu zapobiec, aplikacje powinny sprawdzać, czy dane źródło atrybucji nie jest zarejestrowane zarówno w rozwiązaniu pomiarowym aplikacji, jak i w interfejsie Android Attribution Reporting API.

Ustalanie zaufania w kontekście internetowym

W przypadku wywołań interfejsu API w kontekście internetowym interfejs API ufa aplikacji, że wykryje i określi źródło oraz miejsce docelowe. Może to rodzić potencjalne problemy związane z prywatnością i bezpieczeństwem:

  • Przeciwnik może twierdzić, że hostuje należące do niego witryny, aby obejść limity szybkości dotyczące ilości informacji, które może przesyłać dowolne źródło.
  • Wielu przeciwników może działać w zmowie, aby zarejestrować oddzielne źródła atrybucji, podając tę samą witrynę źródłową. Może to spowodować przekroczenie przez witrynę źródłową limitów częstotliwości platformy technologii reklamowej i uniemożliwić jej rejestrowanie prawidłowych źródeł atrybucji.

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

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

Kontrola użytkowników

Aplikacje mogą nadal obsługiwać ustawienia użytkownika lub zasady 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 będziemy obsługiwać nowe wywołanie interfejsu API z aplikacji, które umożliwi usuwanie źródeł atrybucji, wyzwalaczy i oczekujących raportów przechowywanych na urządzeniu na potrzeby tej aplikacji. Jeśli na przykład aplikacje umożliwiają użytkownikowi wyczyszczenie historii przeglądania, mogą wywołać interfejs API, aby usunąć źródła atrybucji, wyzwalacze i oczekujące raporty przechowywane w tej aplikacji na urządzeniu użytkownika.

Przyszłe kwestie i otwarte pytania

Interoperacyjność interfejsu Attribution Reporting API między aplikacjami a internetem jest w trakcie opracowywania. Chcielibyśmy poznać opinię społeczności na temat kilku pomysłów:

  1. W jaki sposób będziesz używać rozwiązań do pomiarów w przeglądarce na urządzeniu obsługującym Piaskownicę prywatności na Androidzie w połączeniu z interfejsem Attribution Reporting API na Androidzie? Czy wolisz przekazywać wszystko do Androida?
  2. Czy istnieje ryzyko otrzymania 2 pingów dla każdego źródła atrybucji i wyzwalacza – jednego z przeglądarki lub aplikacji, a drugiego 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 internecie są powiązane. W przyszłości będziemy mogli weryfikować te miejsca docelowe, sprawdzając powiązania za pomocą Digital Asset Links. Czy to zablokuje któryś z Twoich przypadków użycia? Czy do przeprowadzenia tej weryfikacji warto użyć Digital Asset Links?
  5. Podczas rejestrowania źródła atrybucji musisz określić miejsce docelowe. W przypadku przejścia z internetu do aplikacji możesz określić link do aplikacji. W jakim formacie określasz ten link do aplikacji?
  6. Podczas rejestrowania źródła atrybucji z aplikacji do witryny zdarzenie źródłowe musi zostać zarejestrowane w aplikacji za pomocą interfejsu Android Attribution Reporting API. Jeśli na przykład użytkownik kliknie reklamę, a kliknięcie zostanie otwarte w przeglądarce lub w karcie niestandardowej przeglądarki, to kliknięcie (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 lub jeśli istnieją inne przypadki użycia, które nie pasują do kategorii opisanych w tym artykule o obsługiwanych przepływach.