Łączenie treści natywnych i internetowych w aplikacji
W wielu przypadkach aplikacja mobilna składa się z części natywnej (np. napisanej w Javie, Kotlinie lub C++ itd.) oraz części internetowej (zwykle uzyskuje się ją poprzez wstawienie do aplikacji widoku internetowego). Aby zoptymalizować doświadczenie użytkownika, możesz skorzystać z kilku zaleceń i strategii wdrożeniowych.
Konfiguracja rdzenia
Ogólnie zalecamy korzystanie z naszego SDK dla iOS or Android w celu zintegrowania CMP z Twoją aplikacją (część natywna). CMP będzie zwykle uruchamiany podczas uruchamiania aplikacji, wyświetla warstwę zgody i umożliwia użytkownikowi dokonanie wyboru. Gdy użytkownik dokona wyboru, pakiet SDK usunie warstwę zgody, a aplikacja będzie działać dalej.
W przypadkach, gdy aplikacja zawiera widok internetowy, zawartość tego widoku internetowego (np. strona internetowa zawierająca reklamy) również musi 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, która jest ładowana w ramach Webview, powinna również zawierać kod CMP (Implementacja HTML kodu).
Wymiana informacji o zgodzie
W przypadku powyższej podstawowej konfiguracji problem polega na tym, że użytkownik zostanie zapytany dwukrotnie: raz przy uruchomieniu aplikacji i raz za każdym razem, gdy otwiera się (nowy) widok internetowy. Aby tego uniknąć, informacje o zgodzie mogą być wymieniane między SDK a webview. Odbywa się to poprzez wyeksportowanie danych zgody z SDK i dołączenie ich do adresu URL, który jest ładowany w widoku internetowym.
Przykład:
consentData = CMPStorageConsentManager.exportCMPData(this);
myWebView.loadURL("https://mywebsite.com/....#cmpimport=" + consentData);(Funkcja eksportu istnieje dla obu zestawów SDK, powyższy przykład pochodzi z przykładów dla systemu iOS)
Po załadowaniu przeglądarki internetowej kod CMP w przeglądarce internetowej zostanie wykonany i znajdzie skrót (#cmpimport=.....) w adresie URL. CMP automatycznie zaimportuje te dane zgody i nie będzie już wykorzystywać danych z plików cookie ani pamięci lokalnej. Ponieważ dane zgody zostały zaimportowane do CMP, warstwa zgody zwykle nie powinna się (ponownie) pojawiać, ponieważ zgoda użytkownika już istnieje.
Prosimy pamiętać,, że informacje o zgodzie można udostępniać tylko z pakietu SDK do widoku internetowego, a nie w przeciwnym kierunku.
Strojenie
Ostatnim krokiem może być drobne dostrojenie, które będziesz chciał zrobić.
Z jednej strony kod CMP zintegrowany z przeglądarką internetową nie powinien pokazywać ikony centrum preferencji (zwykle w lewym dolnym rogu okna przeglądarki, umożliwiając odwiedzającym aktualizację swoich wyborów). Aby wyłączyć ikonę, przejdź do Menu > Ustawienia prawne > RODO/CCPA/... > Pokaż ikonę preferencji.
Z drugiej strony nawet z #cmpimport=... na adresie URL, nadal mogą zdarzyć się przypadki, gdy CMP zdecyduje się pokazać warstwę zgody w webview. Aby tego uniknąć, zalecamy dodanie a konfiguracja po stronie klienta zmienna do wszystkich stron, które są wyświetlane w widoku internetowym:
<script>
window.cmp_noscreen = true;
</script>
... your CMP-Code ...Zapobiegnie to wyświetlaniu warstwy zgody.
FAQ
Czy mogę używać tego samego CMP w pakiecie SDK i w widoku internetowym?
Tak. Dla systemu nie ma znaczenia, czy ten sam CMP, czy inny CMP jest używany w SDK, Twojej przeglądarce internetowej i/lub zwykłej stronie internetowej. Możesz używać tego samego CMP lub różnych CMP we wszystkich środowiskach, a wszystkie CMP mogą importować dane zgody od siebie.
Ponieważ jednak w większości przypadków aplikacja ma różne potrzeby w zakresie zachowania i wyglądu, zwykle lepiej jest oddzielić CMP aplikacji i web-CMP. To samo dotyczy projektów: zasadniczo ten sam projekt może być używany we wszystkich środowiskach, ale w wielu przypadkach sensowne jest posiadanie osobnego projektu dla środowiska aplikacji.
Zalecenie: Jeśli używasz różnych CMP w swojej aplikacji i na swojej stronie, zalecamy użycie tego samego CMP, który jest używany w natywnej części Twojej aplikacji, aby używać go również w odsłonach w Twojej aplikacji.
Jakie są wady i zalety korzystania z tego samego/innego CMP?
Oto kilka zalet używania tego samego CMP we wszystkich środowiskach:
- łatwiejsze zarządzanie listami dostawców, celami i plikami cookie, ponieważ wszystkie środowiska używają tej samej konfiguracji
- brak tarć, gdy dane dotyczące zgody są przesyłane z jednego środowiska do drugiego
Oto wady używania tego samego CMP we wszystkich środowiskach:
- lista dostawców jest potencjalnie dłuższa niż w przypadku rozdzielenia CMP (ponieważ połączona lista dostawców musi obejmować wszystkich dostawców ze wszystkich środowisk)
- brak możliwości rozróżnienia niektórych ustawień ogólnych (np. ustawienia ogólne, takie jak adres URL prywatności, adres URL regulaminu, czy ustawienia prawne, takie jak obsługa RODO, CCPA i inne)
- bardziej skomplikowane, gdy należy użyć różnych projektów (konieczne może być użycie targetowania)
Co się stanie, gdy zostaną użyte dwa różne CMP?
Jeśli CMP używany w natywnej części aplikacji jest innym CMP niż ten w widoku internetowym, informacje o zgodzie z natywnego pakietu SDK są importowane do CMP widoku internetowego. W przypadkach, gdy istnieje różnica między listą celów i/lub listą dostawców dwóch CMP, importujący CMP (ten w widoku internetowym) potraktuje wszystkie brakujące cele i dostawców jako „brak zgody”/„zrezygnowano”. Aby to zilustrować, załóżmy następującą konfigurację:
CMP w natywnej części aplikacji:
Przeznaczenie: A, B, C
Sprzedawcy: 1, 2, 3
CMP w widoku internetowym:
Przeznaczenie: C, D, E
Sprzedawcy: 3, 4, 5
W przypadku, gdy użytkownik akceptuje w części rodzimej wynikiem będzie:
CMP w natywnej części aplikacji:
Cele: A=zaakceptowany, B=zaakceptowany, C=zaakceptowany
Sprzedawcy: 1=zaakceptowany, 2 =zaakceptowany, 3 =zaakceptowany
CMP w widoku internetowym:
Cele: C=zaakceptowany, D=odrzucone, E=odrzucone
Sprzedawcy: 3=zaakceptowany, 4 =odrzucone, 5 =odrzucone
W przypadku, gdy użytkownik odrzuca w części rodzimej wynikiem będzie:
CMP w natywnej części aplikacji:
Cele: A=odrzucone, B=odrzucone, C=odrzucone
Sprzedawcy: 1=odrzucone, 2 =odrzucone, 3 =odrzucone
CMP w widoku internetowym:
Cele: C=odrzucone, D=odrzucone, E=odrzucone
Sprzedawcy: 3=odrzucone, 4 =odrzucone, 5 =odrzucone
Prosimy pamiętać, że jego zachowanie jest niezależne od przypisania dostawców do celów. Oznacza to, że wynik będzie taki sam, jak opisano powyżej, nawet jeśli wszyscy dostawcy zostaną przypisani do celu C.
Prosimy pamiętać, że jego zachowanie jest również niezależne od stosowanych podstaw prawnych każdego sprzedawcy/celu oraz niezależne od jurysdykcji, w której znajduje się użytkownik.
