Ta strona została przetłumaczona przez Cloud Translation API.

Przewodnik po implementacji interfejsu Attribution Reporting API w różnych witrynach i aplikacjach

Interfejs Attribution Reporting API umożliwia przypisywanie udziału w konwersji w przypadku źródeł i wyzwalaczy występujących na tym samym urządzeniu w internecie i aplikacji. Przeglądarki, takie jak Chrome, mogą delegować rejestracje źródeł i wyzwalania do interfejsu Attribution Reporting API na Androida zamiast obsługiwać te rejestracje w przeglądarce. Dzięki temu Android może dopasowywać źródła i wyzwalacze w przypadku witryn i aplikacji.

Z tego przewodnika dowiesz się, jak skonfigurować atrybucję w przypadku aplikacji i witryn internetowych.

Podczas konfigurowania atrybucji w wielu aplikacjach i w internecie warto też zapoznać się z dostępnymi rozwiązaniami do debugowania, aby mieć pewność, że konfiguracja działa zgodnie z oczekiwaniami.

Rejestrowanie źródeł i wyzwalaczy w systemie Android

Atrybucja między aplikacjami i internetem będzie dostępna tylko wtedy, gdy interfejs AttributionReportingAPI jest włączony zarówno w przeglądarce, jak i w systemie Android na tym samym urządzeniu. Dostępność interfejsu Attribution Reporting API na Androida jest wysyłana w nagłówku Attribution-Reporting-Support. Ten nagłówek zwróci system operacyjny, przeglądarkę lub oba te elementy, w zależności od tego, co jest dostępne na danym urządzeniu. Jeśli obie opcje są dostępne, firmy technologiczne zajmujące się reklamami mogą rejestrować źródła internetowe i wyzwalacze internetowe w przeglądarce lub systemie operacyjnym.

Firma zajmująca się technologiami reklamowymi musi zdecydować, czy rejestrować źródło internetowe czy wyzwalacz internetowy w przeglądarce lub systemie operacyjnym.

W przypadku kampanii internetowych dostawcy technologii reklamowych nadal mogą rejestrować źródła i wyzwalacze za pomocą interfejsu Attribution Reporting API w Chrome lub zlecać rejestrowanie obu tych elementów systemowi operacyjnemu. W przypadku kampanii internetowych, w których przypadku źródło lub wyzwalacz może występować w WebView, firmy technologiczne zajmujące się reklamami muszą delegować rejestracje źródła i wyzwalacza do systemu operacyjnego. Więcej informacji znajdziesz w sekcji o komponentach WebView.
Technologie reklamowe nie powinny rejestrować źródeł i wyzwalaczy jednocześnie w interfejsach API Chrome i Androida, aby uniknąć tworzenia zduplikowanych raportów atrybucji.
Przypisywanie odbywa się osobno w przypadku przeglądarek i systemów operacyjnych. Jeśli źródło jest zarejestrowane w przeglądarce, ale wyzwalacz jest zarejestrowany w systemie operacyjnym, te dwa elementy nie mogą być dopasowywane w drugą stronę.
W przypadku źródeł, które mogą prowadzić do aplikacji lub do uruchomienia licznika w witrynie, zdecydowanie zalecamy, aby dostawca technologii reklamowej delegował rejestrowanie źródeł internetowych i liczników do interfejsu Attribution Reporting API na Androida.
W przypadku wyzwalaczy, które mogły być wywołane przez źródła oparte na aplikacji, technologia reklamowa może zdecydować się na delegowanie rejestracji wyzwalaczy internetowych do interfejsu Attribution Reporting API na Androida.
W przypadku kampanii, w których zarówno źródło, jak i wyzwalacz występują w aplikacji, oba te elementy muszą zostać zarejestrowane w interfejsie Attribution Reporting API systemu operacyjnego.

Rejestrowanie źródła aplikacji i aktywatorów internetowych

W przypadku niektórych kampanii źródło może występować w aplikacji, a wyzwalacz w witrynie w przeglądarce mobilnej na tym samym urządzeniu.

Przykład

Użytkownik czyta artykuły w ulubionej aplikacji z wiadomościami. Widzi reklamę tanich lotów do Paryża i z podniecenia klika, aby zarezerwować bilet. Technologia reklamowa wyświetlająca reklamę w aplikacji z wiadomościami rejestruje źródło kliknięcia za pomocą interfejsu Attribution Reporting API na Androida. Użytkownik zostaje przekierowany do strony internetowej reklamodawcy w Chrome, na której może dokonać konwersji. Technologia reklamowa na stronie reklamodawcy sprawdza, czy interfejs API na poziomie systemu operacyjnego jest dostępny. Jeśli tak, rejestruje wyzwalacz konwersji, polecając Chrome delegowanie rejestracji do systemu operacyjnego zamiast rejestrować go bezpośrednio za pomocą interfejsu Attribution Reporting API w Chrome. Interfejs Attribution Reporting API na poziomie systemu operacyjnego może wtedy dopasować źródło aplikacji i wyzwalacz internetowy oraz wysłać odpowiednie raporty.

Proces atrybucji z aplikacji na stronę internetową — Proces atrybucji z aplikacji do witryny internetowej

Rejestrowanie źródła aplikacji:

Pakiet SDK technologii reklamowej w aplikacji Daily News na Androida rejestruje kliknięcie za pomocą:registerSource()
Interfejs Attribution Reporting API na Androida wysyła żądanie do serwera adtech pod adresem URL podanym w registerSource()
Serwer reklamowy odpowiada nagłówkiem Attribution-Reporting-Register-Source, aby dokończyć rejestrację źródła

Rejestracja reguły wywołania w witrynie:

Technologia reklamowa rejestruje wyzwalacz i sprawdza dostępność systemu operacyjnego w interfejsie Attribution Reporting API.
ARA internetowa zwraca informacje o tym, która platforma jest obsługiwana
Nagłówek OS-Trigger informuje interfejs ARA API o tym, że ma wywołać funkcję registerWebTrigger() interfejsu ARA API.
Wywołanie registerWebTrigger() odbywa się w tle, a programista nie musi wywoływać registerWebTrigger() bezpośrednio z systemu operacyjnego.
System ARA operacyjny przejmuje kontrolę i wysyła żądanie do adresu URL serwera technologii reklamowej podanego w nagłówku Attribution-Reporting-Register-OS-Trigger
Technologia reklamowa sfinalizuje rejestrację wyzwalacza za pomocą interfejsu API systemu operacyjnego.
ARA na poziomie systemu operacyjnego będzie przeprowadzać atrybucję zgodnie z tą samą logiką stosowaną w przypadku atrybucji typu app<>app i wysyłać te same raporty.

Przepływ pracy

Poniżej znajdziesz więcej informacji o tym, jak wykonać to zadanie:

Technologia reklamowa z aplikacji rejestruje źródło w interfejsie Attribution Reporting API na Androida z tymi zmianami:
- Aby zarejestrować źródło aplikacji, które ma prowadzić do konwersji w witrynie, nagłówek odpowiedzi Attribution-Reporting-Register-Source powinien zawierać miejsce docelowe w internecie (eTLD+1) zamiast miejsca docelowego w aplikacji.
```
Attribution-Reporting-Register-Source: {
    "web_destination": "https://advertiser.example",
    ...
}
```
Uwaga: w przypadku kampanii, które mogą generować konwersje w witrynie lub w aplikacji, zapoznaj się z sekcją o podwójnych miejscach docelowych
- Niektórzy reklamodawcy mogą korzystać z usług wielu dostawców pomiarów (np. z zewnętrznego narzędzia analitycznego lub narzędzia analitycznego) za pomocą łańcuchów przekierowań 302. W niektórych przypadkach interfejs Attribution Reporting API będzie na drugim planie podążać ścieżką przekierowania określoną w nagłówku Attribution-Reporting-Redirect, a jednocześnie ścieżka przekierowania 302 będzie wykonywana na pierwszym planie w przypadku dotychczasowych żądań nawigacji. Te żądania będą wysyłane pod ten sam adres URL i mogą spowodować podwójne zliczanie rejestracji przez zewnętrznego dostawcę usług pomiarowych. Aby zapobiec podwójnemu zliczaniu rejestracji, firmy technologiczne zajmujące się reklamami mogą zmodyfikować zachowanie przekierowania, aby wysyłać rejestrację interfejsu Attribution Reporting API do alternatywnego, ale deterministycznego adresu URL.
- Aby umożliwić to działanie, firmy technologiczne zajmujące się reklamami muszą uwzględnić nowy nagłówek HTTP w odpowiedzi na żądanie rejestracji:
  - Nagłówek to Attribution-Reporting-Redirect-Config
  - Wartość nagłówka powinna być redirect-302-to-well-known
```
Attribution-Reporting-Redirect-Config: redirect-302-to-well-known
```
  Uwaga: wszystkie kolejne przekierowania po tym nagłówku będą miały dołączony do początku ścieżki identyfikatora URI przekierowania parametr .well-known.
- Pozostała część procesu rejestracji źródła jest taka sama jak standardowa rejestracja źródła w przypadku komunikacji między aplikacjami.
Uwaga: jeśli Ty lub aplikacja do publikowania używacie przeglądarki WebView do wyświetlania reklamy w aplikacji na Androida, zapoznaj się z sekcją dotyczącą przeglądarki WebView
.
Technologia reklamowa w witrynie reklamodawcy rejestruje wyzwalacz, prosząc Chrome o zlecenie rejestracji interfejsowi Attribution Reporting API na Androida:
- Gdy użytkownik dokona konwersji w witrynie, usługa reklamowa prześle do Chrome prośbę o zarejestrowanie wyzwalacza.
  1. Żądanie typu pixel lub fetch() może służyć do rejestrowania zdarzeń
  2. Przeglądarka Chrome zwraca nagłówek Attribution-Reporting-Support do technologii reklamowej. Jeśli interfejs API jest włączony zarówno w przeglądarce Chrome, jak i na urządzeniu z Androidem, nagłówek zwróci wartość os, web.
```
Attribution-Reporting-Support: os, web
```
- Technologia reklamowa powinna następnie poprosić Chrome o przekazanie uprawnień systemowi operacyjnemu za pomocą nagłówka Attribution-Reporting-Register-OS-Trigger, który:
  1. Informuje Chrome, aby delegował rejestrację do systemu operacyjnego.
  2. Chrome deleguje rejestrację do systemu operacyjnego, wywołując funkcję interfejsu API systemu.registerWebTrigger()
    - Wywołanie funkcji registerWebTrigger() odbywa się w tle, a technologia reklamowa nie musi wywoływać funkcji registerWebTrigger() bezpośrednio.
  3. Interfejs API systemu operacyjnego inicjuje dodatkowe wywołanie interfejsu API do URI technologii reklamowej przekazanego z przeglądarki.
```
Attribution-Reporting-Register-OS-Trigger: "https://adtech.example/register-trigger",
"https://other-adtech.example/register-trigger"
```
- W niektórych przypadkach nagłówek Attribution-Reporting-Support jest niedostępny i nie można go wysłać. W takim przypadku technologia reklamowa może nadal ustawić preferowaną platformę do obsługi rejestracji wyzwalacza, podając nagłówek Attribution-Reporting-Info. Kluczem jest preferred-platform, a dozwolone wartości to os i web. Przeglądarka będzie używać preferowanej platformy, jeśli jest dostępna, a gdy system operacyjny jest niedostępny, przełączy się na platformę internetową.
Uwaga: podczas podawania preferowanej platformy należy zwrócić zarówno nagłówek Attribution-Reporting-Register-Trigger z informacjami o rejestracji w internecie, jak i nagłówek Attribution-Reporting-Register-OS-Trigger z informacjami o rejestracji w systemie operacyjnym, aby umożliwić rejestrację na odpowiedniej platformie. Należy podać zarówno rejestracje w systemie operacyjnym, jak i w internecie, aby w przypadku niedostępności preferowanej platformy były dostępne informacje wymagane do użycia metody zapasowej.
```
Attribution-Reporting-Info: preferred-platform=os
```
- Aby dokończyć rejestrację reguły, punkt końcowy technologii reklamowej powinien odpowiedzieć na żądanie interfejsu Attribution Reporting API dla Androida, używając nagłówka odpowiedzi.
```
Attribution-Reporting-Register-Trigger: {
    "event_trigger_data": [{"trigger_data":"1"}],
    "aggregatable_trigger_data": [
        {"key_piece":"0x400","source_keys":["campaignCounts"]},
        {"key_piece":"0xA80","source_keys":["geoValue"]}
    ],
    ...
}
```
- Pozostała część rejestracji reguły pozostaje bez zmian.

Rejestrowanie źródła internetowego i aktywatora aplikacji

W przypadku niektórych kampanii źródło może występować na stronie w przeglądarce mobilnej, a wyzwalacz w aplikacji na tym samym urządzeniu.

Przykład

Użytkownik przegląda witrynę w przeglądarce Chrome na telefonie z Androidem. Widzi reklamę swetra z jednego ze swoich ulubionych sklepów. Klikają przycisk i przenoszą się do aplikacji, którą mają już zainstalowaną. Technologia reklamowa na stronie, na której wyświetlono reklamę, rejestruje źródło kliknięcia, zlecając Chrome delegowanie rejestracji do interfejsu Attribution Reporting API na Androida zamiast używać interfejsu Attribution Reporting API w Chrome. Użytkownik kupuje sweter w aplikacji do zakupów. Technologia reklamowa w aplikacji reklamodawcy rejestruje wyzwalacz konwersji za pomocą interfejsu Attribution Reporting API na Androida. Interfejs Attribution Reporting API na poziomie systemu operacyjnego może dopasowywać źródło internetowe i wyzwalacz aplikacji oraz wysyłać odpowiednie raporty.

Proces atrybucji z sieci do aplikacji — Proces atrybucji w przypadku witryn internetowych i aplikacji

Rejestracja źródła internetowego:

Technologia reklamowa rejestruje źródło i sprawdza dostępność systemu operacyjnego w interfejsie Attribution Reporting API.
ARA internetowa zwraca informacje o tym, która platforma jest obsługiwana
Nagłówek OS-Source informuje interfejs ARA API o tym, że ma wywołać funkcję registerWebSource() interfejsu ARA API.
Wywołanie funkcji registerWebSource() odbywa się w tle, a deweloper nie musi wywoływać funkcji registerWebSource() bezpośrednio z systemu operacyjnego.
System ARA operacyjnego przejmuje kontrolę i wysyła żądanie do adresu URL serwera technologii reklamowej podanego w nagłówku Attribution-Reporting-Register-OS-Source
Technologia reklamowa sfinalizuje rejestrację źródła za pomocą interfejsu OS API

Rejestracja reguły aplikacji:

Pakiet SDK firmy zajmującej się technologiami reklamowymi w aplikacji na Androida sklepu z ubraniem rejestruje wyzwalacz w ARA systemu operacyjnego.
Interfejs Attribution Reporting API na Androida wysyła żądanie do serwera adtech pod adresem URL podanym w registerTrigger()
Serwer adtech odpowiada nagłówkiem Attribution-Reporting-Register-Trigger, aby dokończyć rejestrację reguły
ARA na poziomie systemu operacyjnego będzie przeprowadzać atrybucję zgodnie z tą samą logiką stosowaną w przypadku atrybucji typu app<>app i wysyłać te same raporty.

Przepływ pracy

Poniżej znajdziesz więcej informacji o tym, jak wykonać to zadanie:

Technologia reklamowa na stronie wydawcy rejestruje źródło, zlecając Chrome delegowanie rejestracji do interfejsu Attribution Reporting API na Androida:
- W przypadku ścieżki z witryny do aplikacji podczas rejestrowania źródła należy bezpośrednio podać parametr attribution_source, korzystając z tagu attributionsrc lub rejestracji JavaScriptu.
- W tym przykładzie do określenia parametru source użyto tagu attributionsrc:
```
<img src="https://adtech.example/conversionpixel"
attributionsrc="https://adtech.example/register-source?purchase=12">
```
Nagłówek żądania Attribution-Reporting-Support jest zwracany przez Chrome do technologii reklamowej. Jeśli interfejs API jest włączony zarówno w przeglądarce Chrome, jak i na urządzeniu z Androidem, nagłówek zwróci wartość os, web.
```
Attribution-Reporting-Support: os, web
```
Uwaga: aby móc dokonywać pomiarów w aplikacji i w internecie, musisz włączyć interfejs Attribution Reporting API w systemie operacyjnym Android.
Technologia reklamowa powinna poprosić Chrome o przekazanie uprawnień interfejsowi API na poziomie systemu operacyjnego za pomocą nagłówka Attribution-Reporting-Register-OS-Source, który:
1. Informuje Chrome, aby delegował rejestrację do systemu operacyjnego.
2. Chrome deleguje rejestrację do systemu operacyjnego, wywołując funkcję interfejsu API systemu.registerWebSource()
3. Wywołanie funkcji registerWebSource() odbywa się w tle, a technologia reklamowa nie musi wywoływać funkcji registerWebSource() bezpośrednio.
4. Interfejs API systemu operacyjnego inicjuje dodatkowe wywołanie interfejsu API do adresu URI technologii reklamowej przekazanego przez przeglądarkę.
```
Attribution-Reporting-Register-OS-Source: "https://adtech.example/register-source"
```
- W niektórych przypadkach nagłówek Attribution-Reporting-Support może być niedostępny. W takim przypadku technologia reklamowa może nadal ustawić preferowaną platformę do obsługi rejestracji źródła, podając nagłówek Attribution-Reporting-Info. Klucz to preferred-platform, a dozwolone wartości to os i web. przeglądarka będzie używać preferowanej platformy, jeśli jest dostępna, a gdy system operacyjny jest niedostępny, przełączy się na platformę internetową;
Uwaga: podczas podawania preferowanej platformy należy zwrócić zarówno nagłówek Attribution-Reporting-Register-Source z informacjami o rejestracji w internecie, jak i nagłówek Attribution-Reporting-Register-OS-Source z informacjami o rejestracji w systemie operacyjnym, aby umożliwić rejestrację na odpowiedniej platformie. Należy podać zarówno rejestracje w systemie operacyjnym, jak i w internecie, aby w przypadku niedostępności preferowanej platformy były dostępne informacje wymagane do użycia metody zapasowej.
```
Attribution-Reporting-Info: preferred-platform=os
```
- Aby dokończyć rejestrację źródła, punkt końcowy technologii reklamowej powinien odpowiedzieć na żądanie interfejsu Attribution Reporting API na Androida za pomocą nagłówka odpowiedzi.Attribution-Reporting-Register-Source W odpowiedzi należy też podać miejsce docelowe w aplikacji w polu „destination” (miejsce docelowe).
```
Attribution-Reporting-Register-Source: {
    "source_event_id":"123001",
    "destination":"android-app://com.example.advertiser",
    ...
}
```
- Aby obsługiwać przekierowania w przypadku rejestracji źródeł, Chrome będzie podążać za przekierowaniami i wywoływać interfejsy API kontekstu sieci w przypadku każdego przeskoku przekierowania.
- Pozostała część rejestracji źródła pozostaje bez zmian.
Technologia reklamowa w aplikacji reklamodawcy rejestruje w interfejsie Attribution Reporting API na Androida odpowiednią regułę:
- W przypadku wyzwalaczy występujących w aplikacjach aplikacje rejestrują je w interfejsie Attribution Reporting API na Androida w zwykły sposób.

Kampanie, które mają zarówno miejsca docelowe w aplikacji, jak i w internecie

Konfigurowanie podwójnych miejsc docelowych
- Niektóre kampanie mogą być skonfigurowane tak, aby konwersje następowały w aplikacji lub na stronie internetowej reklamodawcy w zależności od różnych czynników, np. od tego, czy użytkownik ma zainstalowaną aplikację.
- W takich przypadkach zalecamy delegowanie rejestracji źródła do systemu operacyjnego, jeśli jest to możliwe, aby źródło było prawidłowo przypisywane niezależnie od tego, gdzie występuje. Podczas rejestrowania źródła w systemie operacyjnym w odpowiednich parametrach można określić zarówno aplikację, jak i miejsce docelowe w internecie.
- Miejsce docelowe aplikacji powinno znajdować się w polu destination
- Miejsce docelowe w internecie powinno znajdować się w polu web_destination
- Deweloperzy Chrome powinni pamiętać, że pole destination w przypadku interfejsu Attribution Reporting API na system operacyjny powinno zawierać pakiet aplikacji, a nie adres URL.
```
Attribution-Reporting-Register-Source: {
    "source_event_id":"123001",
    "destination":"android-app://com.example.advertiser",
    "web_destination": "https://example.advertiser"
    ...
}
```
- W następnej sekcji dotyczącej raportowania zgrubsza wyjaśnimy, jak korzystanie z podwójnych miejsc docelowych może wpływać na szum w raportach.
Aby ograniczyć zakłócenia w raportach na poziomie zdarzenia w przypadku źródeł danych z podwójnym celem, użyj raportowania zgrubsza:
- Jeśli w rejestracji źródła podano zarówno system operacyjny (aplikację), jak i miejsce docelowe w internecie, raporty na poziomie zdarzenia będą domyślnie określać, czy wywołanie nastąpiło w miejscu docelowym w internecie czy w aplikacji. Jednak aby zachować te ograniczenia, do tych raportów zostanie dodany dodatkowy szum.
- Specjaliści ds. technologii reklamowych mogą użyć pola coarse_event_report_destinations pod nagłówkiem Attribution-Reporting-Register-Source, aby włączyć raportowanie zgrubsza i zmniejszyć poziom szumu. Jeśli atrybucja zostanie przypisana do źródła z wyspecyfikowanym polem coarse_event_report_destinations, raport będzie zawierał zarówno miejsca docelowe w aplikacji, jak i w witrynie, bez rozróżniania, w którym miejscu wystąpił rzeczywisty bodziec, ale z mniejszą ilością zakłóceń niż w raportach, w których jest określone miejsce docelowe w aplikacji lub witrynie.
- Raporty zbiorcze pozostają bez zmian.

Aplikacje korzystające z kart niestandardowych Chrome

Niektóre aplikacje mogą używać kart niestandardowych do renderowania treści internetowych. W przypadku pomiarów w aplikacjach i witrynach mobilnych karty niestandardowe działają podobnie jak zwykłe strony internetowe.

Zarejestruj źródło aplikacji i regułę w karcie niestandardowej:
- Postępuj zgodnie z instrukcjami, aby zarejestrować źródło aplikacji i wyzwalacz internetowy.
Zarejestruj źródło karty niestandardowej i jej aktywator:
- Postępuj zgodnie z instrukcjami, aby zarejestrować źródło internetowe i wyzwalacz aplikacji.
Rejestrowanie źródła i wyzwalacza CCT
- Jest on traktowany tak samo jak przypisanie konwersji do witryny w Chrome.

Aplikacje korzystające z WebView

Niektóre aplikacje mogą używać WebView do wyświetlania treści. WebView może być używany na wiele sposobów, np. do renderowania reklam, hostowania treści internetowych lub obsługi niestandardowych funkcji aplikacji, które lepiej pasują do formatu internetowego.

Aby umożliwić WebViews korzystanie z interfejsu Attribution Reporting API, aplikacja do umieszczania musi być skonfigurowana z odpowiednimi uprawnieniami.
W WebView dostępna jest tylko atrybucja na poziomie systemu operacyjnego. Nagłówek Attribution-Reporting-Support zwraca tylko os, i tylko wtedy, gdy interfejs Attribution Reporting API na Androida jest dostępny.

Uwaga: aby stosować atrybucję w Chrome i WebView, musisz delegować rejestracje źródeł i wyzwań w Chrome do systemu operacyjnego, ponieważ w przypadku WebView obsługiwana jest tylko atrybucja oparta na systemie operacyjnym.

Podczas delegowania do systemu operacyjnego WebView może używać funkcji registerSource lub registerWebSource oraz registerTrigger lub registerWebTrigger. Metody używane przez WebView są określane przez aplikację renderującą WebView i określane na podstawie WebView.

Różnica między registerSource a registerWebSource polega na tym, która ze źródeł zostanie zarejestrowana jako wydawca. W przypadku wartości registerSource aplikacja jest rejestrowana jako wydawca. Przykładem użycia wartości registerSource jest aplikacja wydawcy, która wyświetla reklamę renderowaną za pomocą WebView. W przypadku registerWebSource witryna hostowana w komponencie WebView jest rejestrowana jako wydawca. Przykładem użycia registerWebSource jest aplikacja, która hostuje komponent WebView, a witryna renderowana przez ten komponent wyświetla reklamy. registerTrigger i registerWebTrigger działają podobnie. Schemat podany w punkcie 3 przedstawia różne scenariusze, w których deweloper aplikacji lub pakietu SDK może skonfigurować interfejs API do użycia funkcji registerSource lub registerWebSource oraz registerTrigger lub registerWebTrigger.

Domyślnie WebView używa atrybutów registerSource i registerWebTrigger podczas wywoływania interfejsu Attribution Reporting API na Androida. W ten sposób źródła są powiązane z aplikacją, a czynniki uruchamiające – z źródłem najwyższego poziomu adresu URL w WebView, gdy wystąpi czynnik uruchamiający.

Jeśli aplikacja wymaga innego zachowania, musi użyć nowej metody setAttributionRegistrationBehavior w klasie androidx.webkit.WebViewSettingsCompat. Ta metoda określa, czy WebView ma wywołać metodę registerWebSource() czy registerWebTrigger(), a nie registerSource() czy registerTrigger().
To zachowanie trzeba ustawić dla każdego wywołanego WebView.
Jeśli pakiet SDK technologii reklamowej inicjuje WebView, musi on ustawić to domyślne zachowanie.
Aplikacje, które chcą używać registerWebSource() do kojarzenia rejestracji źródeł z witryną w komponencie WebView zamiast w aplikacji, muszą dołączyć do listy dozwolonych aplikacji internetowych. Aby dołączyć do listy dozwolonych, wypełnij ten formularz. Celem listy dozwolonych jest ograniczenie zagrożeń dla prywatności związanych z budowaniem zaufania w kontekście sieci.

Wartość	Opis	Przykład zastosowania
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.	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 rejestrację źródła i wyzwalacza w komponencie WebView.

Źródła i wyzwalacze rejestracji z WebView
Technologie reklamowe powinny odpowiadać na rejestracje źródeł za pomocą nagłówka Attribution-Reporting-Register-OS-Source. W zależności od ustawień WebView wywoła on registerSource() lub registerWebSource() z systemem operacyjnym i rozpocznie dodatkowe wywołanie interfejsu API z interfejsu Attribution Reporting API na Androida do adresu URI technologii reklamowej.
- Aby dokończyć rejestrację źródła, punkt końcowy technologii reklamowej powinien odpowiedzieć na żądanie interfejsu Attribution Reporting API dla Androida za pomocą nagłówka odpowiedzi.
```
 Attribution-Reporting-Register-OS-Source: {
  "source_event_id":"123001",
  "destination":"android-app://com.example.advertiser",
  ...
}
```
Pozostała część rejestracji źródła pozostaje bez zmian.
Technologie reklamowe powinny odpowiadać na rejestracje wywołane za pomocą nagłówka Attribution-Reporting-Register-OS-Trigger. W zależności od ustawień komponentu WebView wywoła on registerTrigger() lub registerWebTrigger() w systemie operacyjnym i rozpocznie dodatkowe wywołanie interfejsu API z Rb do adresu URI technologii reklamowej.
Aby dokończyć rejestrację reguły, punkt końcowy technologii reklamowej powinien odpowiedzieć na żądanie interfejsu Attribution Reporting API na Androida za pomocą nagłówka odpowiedzi.

Attribution-Reporting-Register-OS-Trigger: {
    "event_trigger_data": [{"trigger_data":"1"}],
    "aggregatable_trigger_data": [
        {"key_piece":"0x400","source_keys":["campaignCounts"]},
        {"key_piece":"0xA80","source_keys":["geoValue"]}
    ],
    ...
}

Pozostała część procesu rejestracji wyzwalacza pozostaje bez zmian.

Debugowanie

Podczas konfigurowania aplikacji do implementacji internetowej zalecamy skonfigurowanie raportów debugowania, aby sprawdzić, czy źródła i wyzwalacze są prawidłowo zarejestrowane, a jeśli nie, to dlaczego.

Ogólne instrukcje debugowania raportowania atrybucji znajdziesz w poradniku debugowania.