W wielu przypadkach aplikacja mobilna składa się z części natywnej (np. napisanej w Javie, Kotlinie, C++ itp.) oraz części internetowej (zwykle uzyskiwanej poprzez wstawienie widoku internetowego do aplikacji). Aby zoptymalizować doświadczenia użytkownika, można skorzystać z pewnych zaleceń i strategii wdrożeniowych.

Podstawowa konfiguracja

Ogólnie zalecamy korzystanie z naszego SDK dla systemów iOS lub Android w celu zintegrowania CMP z aplikacją (część natywna). CMP jest zazwyczaj uruchamiane przy starcie aplikacji, wyświetla warstwę zgody i pozwala użytkownikowi dokonać wyboru. Gdy użytkownik dokona wyboru, SDK usunie warstwę zgody, a aplikacja będzie kontynuować działanie.

W przypadkach, gdy aplikacja zawiera widok internetowy, treść w tym widoku (np. strona internetowa zawierająca reklamy) również będzie musiała wiedzieć, czy wyrażono zgodę, i może być potrzebna obsługa interfejsów API, takich jak IAB TCF lub IAB GPP. Dlatego strona internetowa ładowana w widoku internetowym powinna również zawierać kod CMP (implementację kodu w HTML).

Wymiana informacji dotyczących zgody

Przy powyższej podstawowej konfiguracji problem polega na tym, że użytkownik zostanie zapytany dwukrotnie: raz przy uruchomieniu aplikacji i raz przy każdym otwarciu (nowego) widoku internetowego. Aby tego uniknąć, informacje dotyczące zgody mogą być wymieniane między SDK a widokiem internetowym. Odbywa się to poprzez eksportowanie danych dotyczących zgody z SDK i dołączenie ich do adresu URL, który jest ładowany w widoku internetowym.

Przykład:

// Swift version
let consentData = cmpManager.exportCMPString()
if let url = URL(string: "https://mywebsite.com/....#cmpimport=" + consentData) {
    myWebView.load(URLRequest(url: url))
}

// Kotlin version
val consentData = cmpManager.exportCMPString()
myWebView.loadUrl("https://mywebsite.com/....#cmpimport=" + consentData)

 

Funkcja exportCMPInfo funkcja jest dostępna w obu SDK, zarówno na iOS, jak i na Androida

Po załadowaniu widoku internetowego kod CMP w widoku zostanie wykonany i znajdzie skrót (#cmpimport=.....) w adresie URL. CMP automatycznie zaimportuje te dane dotyczące zgody i nie będzie już korzystać z danych z plików cookie ani pamięci lokalnej. Ponieważ dane dotyczące zgody zostały zaimportowane do CMP, warstwa zgody nie powinna się (ponownie) pojawiać, ponieważ zgoda użytkownika już istnieje.

Dopracowanie

Na koniec możesz wprowadzić drobne poprawki, które uznasz za stosowne.

Z jednej strony kod CMP zintegrowany z widokiem internetowym nie powinien wyświetlać ikony centrum preferencji (zwykle w lewym dolnym rogu okna przeglądarki, umożliwiającej odwiedzającym aktualizację swoich wyborów). Aby wyłączyć ikonę, przejdź do Menu > Ustawienia prawne > RODO/CCPA/… > Pokaż ikonę preferencji.

Z drugiej strony, nawet jeśli #cmpimport=... w adresie URL, nadal mogą wystąpić sytuacje, w których CMP zdecyduje się wyświetlić warstwę zgody w widoku internetowym. Aby tego uniknąć, zalecamy dodanie zmiennej konfiguracyjnej po stronie klienta do wszystkich stron wyświetlanych w widoku internetowym:

<script>
 window.cmp_noscreen = true;
</script>
... your CMP-Code ...

Dzięki temu warstwa zgody nie będzie wyświetlana.

FAQ

Czy mogę używać tego samego CMP w SDK i widoku internetowym?

Tak. Dla systemu nie ma znaczenia, czy w SDK, widoku internetowym i/lub zwykłej witrynie internetowej używana jest ta sama platforma CMP, czy inna. We wszystkich środowiskach można używać tej samej platformy CMP lub różnych platform CMP, a wszystkie platformy CMP mogą importować dane dotyczące zgody od siebie nawzajem.

Jednakże, ponieważ w większości przypadków aplikacja ma inne wymagania dotyczące zachowania i wyglądu, zazwyczaj lepiej jest rozdzielić CMP dla aplikacji i CMP dla stron internetowych. To samo dotyczy projektów: ogólnie rzecz biorąc, ten sam projekt może być używany we wszystkich środowiskach, ale w wielu przypadkach sensowne jest stworzenie oddzielnego projektu dla środowiska aplikacji.

Jakie są zalety i wady korzystania z tego samego/innego CMP?

Oto kilka zalet korzystania z tego samego CMP we wszystkich środowiskach:

• łatwiejsze zarządzanie listami dostawców, celami i plikami cookie, ponieważ wszystkie środowiska korzystają z tej samej konfiguracji
• brak oporu podczas przenoszenia danych dotyczących zgody z jednego środowiska do drugiego

Oto wady korzystania z tego samego CMP we wszystkich środowiskach:

• Lista dostawców jest potencjalnie dłuższa w porównaniu z sytuacją, gdy platformy CMP są rozdzielone (ponieważ połączona lista dostawców musi zawierać wszystkich dostawców ze wszystkich środowisk)
• brak możliwości rozróżnienia niektórych ustawień ogólnych (np. ustawień ogólnych, takich jak adres URL polityki prywatności, adres URL warunków użytkowania, lub ustawień prawnych, takich jak zgodność z RODO, CCPA i innymi)
• Sytuacja jest bardziej skomplikowana, gdy należy zastosować różne projekty (konieczne może być użycie targetowania).

Co się dzieje, gdy używa się dwóch różnych platform CMP?

W przypadku, gdy CMP używane w natywnej części aplikacji jest innym CMP niż to w widoku internetowym, informacje o zgodzie z natywnego SDK są importowane do CMP widoku internetowego. W przypadkach, gdy występuje różnica między listą celów i/lub listą dostawców obu CMP, importujący CMP (ten w widoku internetowym) potraktuje wszystkie brakujące cele i dostawców jako „brak zgody” / „rezygnację”. Aby to zilustrować, załóżmy następującą konfigurację:

CMP w natywnej części aplikacji:
Cele: A, B, C
Dostawcy: 1, 2, 3

CMP w widoku internetowym:
Cele: C, D, E
Dostawcy: 3, 4, 5

W przypadku, gdy użytkownik wyrazi zgodę w części w języku ojczystym, wynik będzie następujący:

CMP w natywnej części aplikacji:
Cele: A = zaakceptowane, B = zaakceptowane, C = zaakceptowane
Dostawcy: 1 = zaakceptowany, 2 = zaakceptowany, 3 = zaakceptowany

CMP w widoku internetowym:
Cele: C = zaakceptowane, D = odrzucone, E = odrzucone
Dostawcy: 3 = zaakceptowane, 4 = odrzucone, 5 = odrzucone

W przypadku, gdy użytkownik odrzuci część w języku ojczystym, wynik będzie następujący:

CMP w natywnej części aplikacji:
Cele: A = odrzucone, B = odrzucone, C = odrzucone
Dostawcy: 1 = odrzucone, 2 = odrzucone, 3 = odrzucone

CMP w widoku internetowym:
Cele: C = odrzucone, D = odrzucone, E = odrzucone
Dostawcy: 3 = odrzucone, 4 = odrzucone, 5 = odrzucone