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 aplikacjach i w internecie. 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ę internetową lub obie te opcje, 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 ź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 technologia reklamowa przekazała 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:

  1. Pakiet SDK technologii reklamowej w aplikacji Daily News na Androida rejestruje kliknięcie za pomocą:registerSource()

  2. Interfejs Attribution Reporting API na Androida wysyła żądanie do serwera adtech pod adresem URL podanym w registerSource()

  3. Serwer reklamowy odpowiada nagłówkiem Attribution-Reporting-Register-Source, aby dokończyć rejestrację źródła

Rejestracja reguły wywołania w witrynie:

  1. Technologia reklamowa rejestruje wyzwalacz i sprawdza dostępność systemu operacyjnego w interfejsie Attribution Reporting API.

  2. ARA internetowa zwraca informacje o tym, która platforma jest obsługiwana

  3. Nagłówek OS-Trigger informuje interfejs API ARA w witrynie, aby wywołał funkcję registerWebTrigger() interfejsu API ARA w systemie operacyjnym

  4. Wywołanie funkcji registerWebTrigger() odbywa się w tle, a programista nie musi wywoływać funkcji registerWebTrigger() bezpośrednio z systemu operacyjnego.

  5. System ARA operacyjny przejmuje kontrolę i wysyła żądanie do adresu URL serwera technologii reklamowej podanego w nagłówku Attribution-Reporting-Register-OS-Trigger

  6. Technologia reklamowa sfinalizuje rejestrację wyzwalacza za pomocą interfejsu API systemu operacyjnego.

  7. 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:

  1. 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",
    ...
}
    .
    • 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ścią nagłówka powinna być wartość redirect-302-to-well-known
      Attribution-Reporting-Redirect-Config: redirect-302-to-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.

  2. 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. Do rejestrowania żądań można użyć żądania pikselowego lub fetch().

      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ą.

    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 za pomocą 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"]}
    ],
    ...
}

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 następnie 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:

  1. Technologia reklamowa rejestruje źródło i sprawdza dostępność systemu operacyjnego w interfejsie Attribution Reporting API.

  2. ARA internetowa zwraca informacje o tym, która platforma jest obsługiwana

  3. Nagłówek OS-Source informuje interfejs ARA API o tym, że ma wywołać funkcję registerWebSource() interfejsu ARA API.

  4. Wywołanie funkcji registerWebSource() odbywa się w tle, a deweloper nie musi wywoływać funkcji registerWebSource() bezpośrednio z systemu operacyjnego.

  5. System ARA operacyjny przejmuje kontrolę i wysyła żądanie do adresu URL serwera technologii reklamowej podanego w nagłówku Attribution-Reporting-Register-OS-Source

  6. Technologia reklamowa sfinalizuje rejestrację źródła za pomocą interfejsu OS API

Rejestracja reguły aplikacji:

  1. Pakiet SDK firmy zajmującej się technologiami reklamowymi w aplikacji na Androida sklepu z ubraniem rejestruje wyzwalacz w ARA systemu operacyjnego.

  2. Interfejs Attribution Reporting API na Androida wysyła żądanie do serwera adtech pod adresem URL podanym w registerTrigger()

  3. Serwer adtech odpowiada nagłówkiem Attribution-Reporting-Register-Trigger, aby dokończyć rejestrację reguły

  4. 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:

  1. Technologia reklamowa na stronie wydawcy rejestruje źródło, polecają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">

  2. 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

  3. 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ą;
    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 nagłówkiem 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.

  4. 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

  1. 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.

  2. Aby ograniczyć zakłócenia w raportach na poziomie zdarzenia w przypadku źródeł o podwójnym przeznaczeniu, 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.

  1. Zarejestruj źródło aplikacji i regułę w karcie niestandardowej:

  2. Zarejestruj źródło karty niestandardowej i jej aktywator:

  3. Rejestrowanie źródła i wyzwalacza CCT

Aplikacje korzystające z WebView

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

  1. Aby umożliwić WebViews korzystanie z interfejsu Attribution Reporting API, aplikacja do umieszczania musi być skonfigurowana z odpowiednimi uprawnieniami.

  2. 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.

  3. Podczas delegowania do systemu operacyjnego WebView może używać funkcji registerSource lub registerWebSource oraz registerTrigger lub registerWebTrigger. Metody używane przez WebView są ustawiane 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 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 w komponencie WebView.
    1. Źródła i wyzwalacze rejestracji z WebView

    2. 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 Androidzie 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",
  ...
}

    3. Pozostała część rejestracji źródła pozostaje bez zmian.

    4. 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.

    5. Aby zakoń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"]}
    ],
    ...
}

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 książce kucharskiej na temat debugowania.