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 aplikacjach i internecie w przypadku źródeł i zdarzeń, które występują na tym samym urządzeniu. Przeglądarki, np. Chrome, mogą przekazywać rejestracje źródeł i zdarzeń do interfejsu Attribution Reporting API na Androidzie zamiast obsługiwać je w przeglądarce. Umożliwia to Androidowi dopasowywanie źródeł i wywołań zarówno w witrynach, jak i w aplikacjach.

Z tego przewodnika dowiesz się, jak skonfigurować atrybucję w aplikacjach i witrynach.

Podczas konfigurowania atrybucji w aplikacjach i w internecie zalecamy zapoznanie się z dostępnymi rozwiązaniami do debugowania, które pozwolą Ci sprawdzić, czy konfiguracja działa zgodnie z oczekiwaniami.

Rejestrowanie źródeł i wyzwalaczy w systemie Android

Atrybucja w aplikacjach i w internecie będzie dostępna tylko wtedy, gdy interfejs Attribution Reporting API będzie włączony zarówno w przeglądarce, jak i w systemie Android na tym samym urządzeniu. Informacja o dostępności interfejsu Android Attribution Reporting API jest przesyłana w nagłówku Attribution-Reporting-Support. Ten nagłówek zwróci wartość os, web lub obie te wartości w zależności od tego, co jest dostępne na danym urządzeniu. Jeśli oba są dostępne, dostawcy technologii reklamowych będą mogli rejestrować źródła internetowe i wyzwalacze internetowe w przeglądarce lub systemie operacyjnym.

Technologia reklamowa musi zdecydować, czy zarejestrować źródło internetowe lub wyzwalacz internetowy w przeglądarce czy w systemie operacyjnym.

  • W przypadku kampanii internetowych dostawcy technologii reklamowych mogą nadal rejestrować źródła i wyzwalacze za pomocą interfejsu Attribution Reporting API w Chrome lub przekazywać je do systemu operacyjnego. W przypadku kampanii wyświetlanych tylko w internecie, w których źródło lub wyzwalacz może wystąpić w widoku WebView, dostawcy technologii reklamowych muszą przekazywać rejestracje źródła i wyzwalacza do systemu operacyjnego. Więcej informacji znajdziesz w sekcji poświęconej widokom WebView.

  • Dostawcy technologii reklamowych powinni unikać jednoczesnego rejestrowania źródeł i aktywatorów w interfejsach API Chrome i Androida, aby nie tworzyć zduplikowanych raportów o atrybucji.

  • Atrybucja jest przeprowadzana 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, tych 2 elementów nie można dopasować. Działa to też w drugą stronę.

  • W przypadku źródeł, które mogą powodować wywołanie w aplikacji lub w internecie, dostawca technologii reklamowych powinien przekazywać rejestracje źródeł i wywołań w internecie do interfejsu Android Attribution Reporting API.

  • W przypadku wywołań, które mogły być spowodowane przez źródła w aplikacji, dostawca technologii reklamowych może przekazać rejestrację wywołań w internecie do interfejsu Android Attribution Reporting API.

  • W przypadku kampanii, w których zarówno źródło, jak i wyzwalacz występują w aplikacji, oba te elementy muszą być zarejestrowane w interfejsie Attribution Reporting API systemu operacyjnego.

Rejestrowanie źródła aplikacji i aktywatora internetowego

W przypadku niektórych kampanii źródło może wystąpić 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 radością klika, aby dokonać rezerwacji. Technologia reklamowa wyświetlająca reklamę w aplikacji z wiadomościami rejestruje źródło kliknięcia za pomocą interfejsu Android Attribution Reporting API. Użytkownik zostaje przekierowany do strony internetowej reklamodawcy w Chrome, gdzie może dokonać konwersji. Technologia reklamowa w witrynie reklamodawcy sprawdza, czy interfejs API na poziomie systemu operacyjnego jest dostępny. Jest on dostępny. Technologia reklamowa rejestruje wyzwalacz konwersji, instruując Chrome, aby przekazać rejestrację do systemu operacyjnego zamiast rejestrować ją bezpośrednio w interfejsie Attribution Reporting API Chrome. Interfejs Attribution Reporting API na poziomie systemu operacyjnego może następnie dopasować źródło aplikacji i wyzwalacz internetowy oraz wysłać odpowiednie raporty.

Proces atrybucji z aplikacji do witryny
Przepływ atrybucji z aplikacji do sieci

Rejestracja źródła aplikacji:

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

  2. Interfejs Attribution Reporting API na Androidzie wysyła żądanie do serwera technologii reklamowej adresu URL podanego w registerSource()

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

Rejestracja aktywatora internetowego:

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

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

  3. Nagłówek OS-Trigger informuje internetowy interfejs ARA API, aby wywołać funkcję registerWebTrigger() interfejsu OS ARA API.

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

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

  6. Technologia reklamowa dokończy rejestrację wywołania za pomocą interfejsu API systemu operacyjnego.

  7. OS ARA będzie przeprowadzać atrybucję zgodnie z tą samą logiką, która jest stosowana w przypadku atrybucji aplikacji do aplikacji, i wysyłać te same raporty.

Przepływ pracy

Poniżej znajdziesz szczegółowe instrukcje wykonania tego zadania:

  1. Technologia reklamowa z aplikacji rejestruje źródło w interfejsie Attribution Reporting API na Androidzie z tymi zmianami:

    • Aby zarejestrować źródło aplikacji, które ma generować konwersje w witrynie, nagłówek odpowiedzi Attribution-Reporting-Register-Source powinien zawierać miejsce docelowe w witrynie (eTLD+1) zamiast miejsca docelowego w aplikacji.
    Attribution-Reporting-Register-Source: {
    "web_destination": "https://advertiser.example",
    ...
}
    • Niektórzy reklamodawcy mogą korzystać z usług kilku dostawców pomiarów (np. zewnętrznego narzędzia pomiarowego lub narzędzia analitycznego) za pomocą ciągów przekierowań 302. W niektórych przypadkach interfejs Attribution Reporting API będzie w tle śledzić ś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 istniejących żądań nawigacji. Te żądania będą wysyłane na ten sam adres URL, co może spowodować podwójne zliczanie rejestracji przez dostawcę zewnętrznych usług pomiarowych. Aby zapobiec podwójnemu zliczaniu rejestracji, dostawcy technologii reklamowych mogą zmodyfikować zachowanie przekierowania, aby wysyłać rejestrację interfejsu Attribution Reporting API do alternatywnego, ale deterministycznego adresu URL.

    • Aby włączyć to zachowanie, dostawcy technologii reklamowych muszą dołączać nowy nagłówek HTTP, gdy odpowiadają 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

    • Pozostała część procesu rejestracji źródła jest taka sama jak w przypadku standardowej rejestracji źródła w aplikacji.

  2. Technologia reklamowa w witrynie reklamodawcy rejestruje zdarzenie wywołujące, prosząc Chrome o przekazanie rejestracji do interfejsu Android Attribution Reporting API:

    • Gdy użytkownik dokona konwersji w witrynie, technologia reklamowa wyśle do Chrome prośbę o zarejestrowanie wywołania.

      1. Do wysłania żądania zarejestrowania wyzwalacza można użyć piksela lub żądania fetch().

      2. Nagłówek żądania Attribution-Reporting-Support jest zwracany przez Chrome do dostawcy technologii reklamowych. 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 poinformować Chrome, aby przekazać uprawnienia do systemu operacyjnego za pomocą nagłówka Attribution-Reporting-Register-OS-Trigger, który:

      1. Informuje Chrome, że rejestracja ma zostać przekazana do systemu operacyjnego.

      2. Chrome przekazuje rejestrację do systemu operacyjnego, wywołując funkcję interfejsu API systemu operacyjnego.registerWebTrigger()

        • Wywołanie registerWebTrigger() odbywa się w tle, a technologia reklamowa nie musi wywoływać registerWebTrigger() bezpośrednio.

      3. Interfejs API systemu operacyjnego inicjuje dodatkowe wywołanie interfejsu API do adresu 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 takiej sytuacji platforma technologii reklamowej może nadal ustawić preferowaną platformę do obsługi rejestracji wyzwalacza, dodają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, gdy będzie ona dostępna, a w przypadku niedostępności systemu operacyjnego przełączy się na platformę internetową.

    Attribution-Reporting-Info: preferred-platform=os
    • Aby dokończyć rejestrację wywołania, punkt końcowy technologii reklamowej powinien odpowiedzieć na żądanie interfejsu Android 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ć w witrynie w przeglądarce mobilnej, a zdarzenie wywołujące – 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 z ulubionych sklepów. Klikają reklamę i przechodzą do aplikacji, którą już pobrali. Technologia reklamowa na stronie, na której wyświetlono reklamę, rejestruje źródło kliknięcia, instruując Chrome, aby przekazać rejestrację do interfejsu Attribution Reporting API na Androidzie zamiast korzystać z interfejsu Attribution Reporting API w Chrome. Użytkownik kupuje sweter w aplikacji zakupowej. Technologia reklamowa w aplikacji reklamodawcy rejestruje następnie wyzwalacz konwersji w interfejsie Android Attribution Reporting API. Interfejs Attribution Reporting API na poziomie systemu operacyjnego może dopasować źródło internetowe i wyzwalacz aplikacji oraz wysyłać odpowiednie raporty.

Proces atrybucji w przypadku przejścia z internetu do aplikacji
Proces atrybucji Web to App

Rejestracja źródła internetowego:

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

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

  3. Nagłówek OS-Source informuje internetowy interfejs ARA API, aby wywołać funkcję registerWebSource() interfejsu OS ARA API.

  4. Wywołanie registerWebSource() odbywa się w tle i deweloper nie musi wywoływać registerWebSource() bezpośrednio w systemie operacyjnym.

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

  6. Technologia reklamowa dokończy rejestrację źródła za pomocą interfejsu API systemu operacyjnego.

Rejestracja aktywatora aplikacji:

  1. Pakiet SDK technologii reklamowej w aplikacji na Androida w sklepie odzieżowym rejestruje wyzwalacz w interfejsie ARA systemu operacyjnego.

  2. Interfejs Attribution Reporting API na Androidzie wysyła żądanie do serwera technologii reklamowej adresu URL podanego w registerTrigger()

  3. Serwer technologii reklamowej odpowiada za pomocą nagłówka Attribution-Reporting-Register-Trigger w celu dokończenia rejestracji wyzwalacza.

  4. OS ARA będzie przeprowadzać atrybucję zgodnie z tą samą logiką, która jest stosowana w przypadku atrybucji aplikacji do aplikacji, i wysyłać te same raporty.

Przepływ pracy

Poniżej znajdziesz szczegółowe instrukcje wykonania tego zadania:

  1. Technologia reklamowa w witrynie wydawcy rejestruje źródło, instruując Chrome, aby przekazać rejestrację do interfejsu Android Attribution Reporting API:

    • W przypadku scenariusza użycia „sieć – aplikacja” podczas rejestrowania źródła parametr źródła atrybucji musi być określony bezpośrednio za pomocą tagu attributionsrc lub rejestracji w JavaScript.
    • W tym przykładzie używamy tagu attributionsrc, aby określić parametr źródła:
    <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 poinformować Chrome, aby przekazać wywołanie interfejsu API na poziomie systemu operacyjnego, używając nagłówka Attribution-Reporting-Register-OS-Source, który:

    1. Informuje Chrome, że rejestracja ma zostać przekazana do systemu operacyjnego.
    2. Chrome przekazuje rejestrację do systemu operacyjnego, wywołując funkcję interfejsu API systemu operacyjnego.registerWebSource()
    3. Wywołanie registerWebSource() odbywa się w tle, a technologia reklamowa nie musi wywoływać registerWebSource() bezpośrednio.
    4. Interfejs API systemu operacyjnego inicjuje dodatkowe wywołanie interfejsu API do adresu URI technologii reklamowej przekazanego z przeglądarki.
    Attribution-Reporting-Register-OS-Source: "https://adtech.example/register-source"
    • W niektórych przypadkach nagłówek Attribution-Reporting-Support jest niedostępny. W takiej sytuacji platforma reklamowa może nadal ustawić preferowaną platformę do obsługi rejestracji źródła, dodają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, gdy jest ona dostępna, a w przypadku niedostępności systemu operacyjnego 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 Androidzie za pomocą nagłówka odpowiedzi Attribution-Reporting-Register-Source. W polu docelowym odpowiedź powinna też zawierać miejsce docelowe aplikacji.
    Attribution-Reporting-Register-Source: {
    "source_event_id":"123001",
    "destination":"android-app://com.example.advertiser",
    ...
}

  4. Technologia reklamowa w aplikacji reklamodawcy rejestruje wyzwalacz w interfejsie Attribution Reporting API na Androidzie:

    • W przypadku wyzwalaczy, które występują w aplikacjach, aplikacje rejestrują wyzwalacze w interfejsie Android Attribution Reporting API w normalny sposób.

Kampanie, które mają potencjalne miejsca docelowe w aplikacji i w internecie

  1. Konfigurowanie dwóch miejsc docelowych

    • Niektóre kampanie mogą być skonfigurowane tak, aby konwersje były rejestrowane w aplikacji reklamodawcy lub na jego stronie internetowej w zależności od różnych czynników, np. od tego, czy użytkownik ma zainstalowaną aplikację.
    • W takich przypadkach zalecamy przekazanie rejestracji źródła do systemu operacyjnego, aby można było prawidłowo przypisać źródło niezależnie od tego, gdzie wystąpi wyzwalacz. 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.
    • Programiści Chrome powinni pamiętać, że pole destination w przypadku interfejsu OS Attribution Reporting API 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 przybliżonego wyjaśnimy, jak korzystanie z 2 miejsc docelowych może wpłynąć na szum w raportach.

  2. Używaj raportowania przybliżonego, aby ograniczyć szum w raportach na poziomie zdarzenia w przypadku źródeł z 2 miejscami docelowymi:

    • Jeśli w rejestracji źródła określono zarówno miejsce docelowe w systemie operacyjnym (aplikacji), jak i w internecie, raporty na poziomie zdarzenia będą domyślnie określać, czy wyzwalacz wystąpił w miejscu docelowym w internecie czy w aplikacji. Aby jednak zachować limity prywatności, do tych raportów zostanie dodany dodatkowy szum.
    • Technologie reklamowe mogą używać pola coarse_event_report_destinations w sekcji Attribution-Reporting-Register-Source, aby włączyć raportowanie przybliżone i zmniejszyć szum. Jeśli źródło z określonym polem coarse_event_report_destinations zostanie uznane za źródło atrybucji, raport będzie zawierać zarówno miejsca docelowe w aplikacji, jak i w internecie, bez rozróżnienia, gdzie nastąpiło rzeczywiste wywołanie, ale z mniejszą ilością szumu niż raporty, w których określono miejsce docelowe w aplikacji lub w internecie.
    • Raporty zbiorcze pozostają bez zmian.

W przypadku aplikacji korzystających z kart niestandardowych Chrome

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

  1. Zarejestruj źródło aplikacji i aktywator karty niestandardowej:

  2. Zarejestruj źródło kart niestandardowych i aktywator aplikacji:

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

W przypadku aplikacji korzystających z WebView

Niektóre aplikacje mogą używać WebView do wyświetlania treści. Widok WebView ma wiele zastosowań, np. renderowanie reklam, hostowanie treści internetowych lub niestandardowych funkcji aplikacji, które lepiej sprawdzają się w formacie internetowym.

  1. Aby umożliwić widokom WebView korzystanie z interfejsu Attribution Reporting API, aplikacja osadzająca musi być skonfigurowana z odpowiednimi uprawnieniami.

  2. W przypadku WebView dostępna jest tylko atrybucja na poziomie systemu operacyjnego. Nagłówek Attribution-Reporting-Support zwróci tylko wartość os i tylko wtedy, gdy dostępny jest interfejs Attribution Reporting API na Androida.

  3. Podczas przekazywania uprawnień do systemu operacyjnego komponent WebView może używać registerSource lub registerWebSource oraz registerTrigger lub registerWebTrigger. Metody używane przez WebView są ustawiane przez aplikację renderującą WebView i określane dla każdego komponentu WebView z osobna.

    • Różnica między registerSource a registerWebSource polega na tym, które źródło jest rejestrowane jako wydawca. W przypadku registerSource aplikacja jest rejestrowana jako wydawca. Przykładem użycia registerSource może być aplikacja wydawcy, która wyświetla reklamę renderowaną za pomocą WebView. W przypadku parametru registerWebSource witryna hostowana w komponencie WebView jest rejestrowana jako wydawca. Przykładem użycia parametru registerWebSource może być aplikacja, która hostuje komponent WebView, a witryna renderowana przez ten komponent wyświetla reklamy. registerTrigger i registerWebTrigger działają podobnie. Wykres w punkcie 3 zawiera szczegółowe informacje o różnych scenariuszach, w których deweloper aplikacji lub pakietu SDK może skonfigurować interfejs API do używania wartości registerSource lub registerWebSource oraz registerTrigger lub registerWebTrigger.
    • Domyślnie WebView będzie używać wartości registerSource i registerWebTrigger podczas wywoływania interfejsu Android Attribution Reporting API. Powiązuje to źródła z aplikacją, a czynniki uruchamiające ze źródłem najwyższego poziomu adresu URL w widoku WebView, gdy nastąpi uruchomienie.

      • Jeśli aplikacja wymaga innego działania, musi użyć nowej metody setAttributionRegistrationBehavior w klasie androidx.webkit.WebViewSettingsCompat. Ta metoda określa, czy komponent WebView ma wywoływać registerWebSource() lub registerWebTrigger() zamiast registerSource() lub registerTrigger().

      • To zachowanie należy ustawić w przypadku każdego inicjowanego widoku WebView.

      • Jeśli pakiet SDK technologii reklamowej inicjuje komponent WebView, musi ustawić to domyślne zachowanie.

      • Aplikacje, które chcą używać registerWebSource() do powiązania rejestracji źródła z witryną w WebView zamiast z aplikacją, muszą dołączyć do listy dozwolonych WebApp. Aby dołączyć do listy dozwolonych, wypełnij ten formularz. Celem listy dozwolonych jest ograniczenie kwestii związanych z prywatnością w kontekście budowania zaufania w kontekście internetowym.

      Wartość Opis Przykład zastosowania
      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 Zezwala aplikacjom na rejestrowanie źródeł internetowych i wyzwalaczy internetowych z WebView. 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 komponencie WebView.
    1. Rejestrowanie źródeł i wywołań 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 ustawionego działania komponentu WebView wywoła on funkcję registerSource() lub registerWebSource() z systemem operacyjnym i zainicjuje dodatkowe wywołanie interfejsu API z interfejsu Android Attribution Reporting API do adresu URI technologii reklamowej.

      • Aby dokończyć rejestrację źródła, punkt końcowy technologii reklamowej powinien odpowiedzieć na żądanie interfejsu Android Attribution Reporting API 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 wyzwalaczy za pomocą nagłówka Attribution-Reporting-Register-OS-Trigger. W zależności od ustawionego działania komponentu WebView wywoła on funkcję registerTrigger() lub registerWebTrigger() w systemie operacyjnym i zainicjuje drugie wywołanie interfejsu API z Rb do adresu URI technologii reklamowej.

    5. Aby dokończyć rejestrację wyzwalacza, punkt końcowy technologii reklamowej powinien odpowiedzieć na żądanie interfejsu Android Attribution Reporting API 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 implementacji aplikacji w internecie zalecamy skonfigurowanie raportów debugowania, aby sprawdzić, czy źródła i wyzwalacze są prawidłowo rejestrowane, a jeśli nie, otrzymywać informacje o przyczynach.

Ogólne instrukcje debugowania interfejsu Attribution Reporting znajdziesz w tym przewodniku.