Problem podwójnego banera

Wiele aplikacji jest częściowo natywnych, a częściowo webowych. Gra pokazuje sklep, wiadomości lub strony pomocy w WebView; aplikacja narzędziowa renderuje artykuły ze swojej witryny; aplikacja hybrydowa opakowuje większość interfejsu w treści webowe. Każda strona ma własny mechanizm zgody: aplikacja natywna używa CMP lub SDK w aplikacji, a strony webowe ładują webowy CMP. Jeśli nie są połączone, użytkownik jest pytany dwa razy, wybory dokonane w jednym miejscu są ignorowane w drugim, a żądania reklam z wnętrza WebView wychodzą z niewłaściwymi sygnałami.

Ten przewodnik pokazuje, jak sprawić, by zgoda natywna i webowa się zgadzały, tak aby użytkownicy odpowiadali raz, a każde żądanie reklamy niosło tę samą decyzję.

Gdzie każda strona przechowuje zgodę

Natywna

IAB TCF określa, jak CMP w aplikacji przechowuje zgodę: w NSUserDefaults na iOS i SharedPreferences na Androidzie, używając standardowych kluczy, takich jak IABTCF_TCString, IABTCF_gdprApplies i IABTCF_PurposeConsents. SDK reklamowe odczytują te klucze bezpośrednio. IAB GPP definiuje podobne klucze z prefiksem IABGPP_, na przykład IABGPP_HDR_GppString.

Webowa

Webowy CMP zwykle przechowuje decyzję w plikach cookie pierwszej strony lub pamięci lokalnej dla domeny witryny i udostępnia ją przez funkcje JavaScript __tcfapi i __gpp. Tagi reklamowe na stronie wywołują te funkcje, a nie pamięć natywną.

Luka

WebView mają własną przestrzeń na pliki cookie i dane, oddzieloną od przeglądarki urządzenia i od natywnych preferencji aplikacji. Na iOS WKWebView używający nietrwałego magazynu danych zapomina wszystko po zamknięciu. Nic nie przepływa między obiema stronami, dopóki tego nie zbudujesz.

Wybierz jedno źródło prawdy

Pierwszą decyzją jest, która strona jest właścicielem zgody. Dla większości aplikacji odpowiedzią jest natywny CMP, ponieważ:

• Uruchamia się jako pierwszy, zanim otworzy się jakiekolwiek WebView.
• Natywne SDK reklamowe, które zwykle zarabiają większość przychodów, odczytują pamięć natywną.
• Na iOS można go skoordynować z monitem App Tracking Transparency.

Podejście web-first może mieć sens w aplikacjach hybrydowych, których cały interfejs to treść webowa, ale wtedy musisz zapisywać decyzję z powrotem do pamięci natywnej dla natywnych SDK.

Przekazywanie zgody natywnej do WebView

Gdy źródłem prawdy jest strona natywna, WebView musi widzieć tę samą decyzję. Typowe wzorce:

1. Wstrzyknij implementację __tcfapi. Zanim uruchomią się skrypty strony, wstrzyknij mały skrypt, który definiuje __tcfapi (i w razie potrzeby __gpp) i odpowiada na wywołania ciągiem TC oraz wartościami odczytanymi z pamięci natywnej. Tagi reklamowe na stronie otrzymują wtedy decyzję natywną przez standardowe API.
2. Wyłącz baner webowy. Skonfiguruj webowy CMP tak, aby pozostawał ukryty, gdy strona jest ładowana wewnątrz Twojej aplikacji, na przykład na podstawie parametru zapytania lub własnego tokenu user agenta, który kontrolujesz. W przeciwnym razie użytkownik zobaczy drugi baner.
3. Przekaż ciąg przy ładowaniu. Niektóre webowe CMP potrafią przyjąć istniejący ciąg zgody przy inicjalizacji i go przejąć. Obsługiwane metody sprawdź w dokumentacji swojego webowego CMP.

Niezależnie od wzorca upewnij się, że wstrzyknięte wartości aktualizują się, gdy użytkownik zmieni wybór na natywnym ekranie ustawień, a nie dopiero przy następnym uruchomieniu aplikacji.

Przekazywanie zgody webowej z powrotem do natywnej

Jeśli użytkownicy mogą zmieniać zgodę wewnątrz WebView, na przykład na stronie ustawień prywatności, aplikacja musi się o tym dowiedzieć. Użyj mostu JavaScript: obsługi komunikatów na iOS lub interfejsu JavaScript na Androidzie. Strona webowa nasłuchuje przez __tcfapi('addEventListener', ...) i wysyła nowy ciąg do kodu natywnego, który zapisuje standardowe klucze. Zweryfikuj dane wejściowe z WebView przed zapisem; akceptuj tylko komunikaty z własnych treści.

Reklamy wewnątrz WebView

Reklamy renderowane w WebView to reklamy webowe. Odczytują zgodę ze strony, a nie z pamięci natywnej, chyba że SDK reklamowe zapewnia sposób połączenia obu. Na przykład Google Mobile Ads SDK oferuje API do rejestrowania WebView, aby reklamy w nich mogły korzystać z sygnałów z aplikacji; aktualną dokumentację swojego SDK sprawdź samodzielnie. W każdym razie potwierdź testem, że żądania reklam z WebView niosą ten sam ciąg TC lub GPP co natywne żądania reklam.

Lista kontrolna testów

• Świeża instalacja: jeden monit o zgodę, nie dwa.
• Odrzuć wszystko w natywnym CMP, otwórz WebView, sprawdź żądania reklam: ciąg powinien odzwierciedlać odrzucenie.
• Zmień zgodę w ustawieniach natywnych, wróć do otwartego WebView: strona powinna zobaczyć nową decyzję.
• Jeśli istnieją ustawienia webowe, zmień zgodę tam i potwierdź, że klucze natywne się aktualizują.
• Zamknij i uruchom ponownie aplikację: decyzje utrzymują się po obu stronach.
• Testuj na iOS i na Androidzie, ponieważ pamięć WebView zachowuje się na każdym inaczej.

Najważniejsze wnioski

• Zgoda natywna i w WebView mieszkają w oddzielnych magazynach i domyślnie się nie synchronizują.
• Wybierz jedno źródło prawdy; dla większości aplikacji to natywny CMP.
• Udostępnij zgodę natywną treści webowej przez wstrzyknięty __tcfapi lub __gpp i ukryj baner webowy.
• Użyj mostu JavaScript, aby odsyłać zmiany z webu do pamięci natywnej.
• Sprawdź, czy żądania reklam z WebView niosą ten sam ciąg zgody co natywne.