Native en webcontent combineren in een app
In veel gevallen bestaat een mobiele app uit een native gedeelte (bijvoorbeeld geschreven in Java of Kotlin of C++ enzovoort) en een webgedeelte (meestal bereikt door een webweergave in de app in te voegen). Om de gebruikerservaring te optimaliseren, zijn er enkele aanbevelingen en implementatiestrategieën die u kunt gebruiken.
Kernopstelling
Over het algemeen raden we aan om onze SDK te gebruiken voor iOS or Android om de CMP te integreren in uw app (native gedeelte). De CMP wordt meestal geactiveerd bij het starten van de app, geeft de toestemmingslaag weer en laat de gebruiker zijn keuzes maken. Zodra de gebruiker de keuzes heeft gemaakt, verwijdert de SDK de toestemmingslaag en gaat de app verder.
In gevallen waarin de app een webweergave bevat, moet de inhoud in deze webweergave (bijvoorbeeld een webpagina met advertenties) ook weten of toestemming is gegeven en kan ondersteuning voor API's zoals de IAB TCF of IAB GPP nodig zijn. Daarom moet de webpagina die in de webweergave wordt geladen ook de CMP-code bevatten (HTML-implementatie van de code).
Toestemmingsgegevens uitwisselen
Met de bovenstaande kernopstelling is het probleem dat een gebruiker twee keer wordt gevraagd: één keer bij het starten van de app en één keer telkens wanneer een (nieuwe) webview wordt geopend. Om dit te voorkomen, kan de toestemmingsinformatie worden uitgewisseld tussen SDK en webview. Dit wordt gedaan door de toestemmingsgegevens van de SDK te exporteren en deze te koppelen aan de URL die in de webview is geladen.
Voorbeeld:
consentData = CMPStorageConsentManager.exportCMPData(this);
myWebView.loadURL("https://mywebsite.com/....#cmpimport=" + consentData);(Er bestaat een exportfunctie voor beide SDK's, het bovenstaande voorbeeld is overgenomen uit de iOS-voorbeelden)
Zodra de webview is geladen, wordt de CMP-code in de webview uitgevoerd en wordt de hash (#cmpimport=.....) in de URL. Het CMP importeert deze toestemmingsgegevens automatisch en gebruikt geen gegevens meer uit cookies of lokale opslag. Aangezien de toestemmingsgegevens in het CMP zijn geïmporteerd, zou de toestemmingslaag normaal gesproken niet (opnieuw) moeten verschijnen omdat de toestemming van de gebruiker al bestaat.
Let op:, dat toestemmingsinformatie alleen kan worden gedeeld van de SDK naar de webweergave en niet in de tegenovergestelde richting.
Scherpstellen
Als laatste stap is er misschien wat fijnafstemming die u graag wilt doen.
Aan de ene kant mag de CMP-code die in de webweergave is geïntegreerd, niet het pictogram van het voorkeurscentrum weergeven (meestal linksonder in het browservenster, zodat bezoekers hun keuzes kunnen bijwerken). Ga naar om het pictogram uit te schakelen Menu > Juridische instellingen > GDPR/CCPA/... > Pictogram Voorkeuren tonen.
Aan de andere kant, zelfs met de #cmpimport=... op de URL kunnen er nog steeds gevallen zijn waarin de CMP besluit om de toestemmingslaag weer te geven in de webview. Om dat te voorkomen, raden we aan om een configuratie aan de clientzijde variabele naar alle pagina's die binnen de webview getoond worden:
<script>
window.cmp_noscreen = true;
</script>
... your CMP-Code ...Dit voorkomt dat de toestemmingslaag wordt weergegeven.
FAQ
Kan ik dezelfde CMP gebruiken in de SDK en de webview?
Ja. Voor het systeem maakt het niet uit of dezelfde CMP of een andere CMP wordt gebruikt in de SDK, uw webview en/of uw normale website. U kunt dezelfde CMP of verschillende CMP's in alle omgevingen gebruiken en alle CMP's kunnen de toestemmingsgegevens van elkaar importeren.
Aangezien de app in de meeste gevallen andere behoeften heeft met betrekking tot gedrag en ontwerp, is het meestal beter om app-CMP's en web-CMP's te scheiden. Hetzelfde geldt voor ontwerpen: over het algemeen kan hetzelfde ontwerp in alle omgevingen worden gebruikt, maar in veel gevallen is het zinvol om een apart ontwerp voor de app-omgeving te hebben.
Aanbeveling: Als u verschillende CMP's gebruikt in uw app en op uw website, raden we u aan om dezelfde CMP, die wordt gebruikt in het native gedeelte van uw app, ook te gebruiken in de webviews binnen uw app.
Wat zijn de voor- en nadelen van het gebruik van dezelfde/een andere CMP?
Hier volgen enkele voordelen van het gebruik van dezelfde CMP in al uw omgevingen:
- eenvoudiger beheer van leverancierslijsten, doeleinden en cookies aangezien alle omgevingen dezelfde configuratie gebruiken
- geen wrijving wanneer toestemmingsgegevens van de ene omgeving naar de andere worden overgedragen
Dit zijn de nadelen van het gebruik van dezelfde CMP in al uw omgevingen:
- leverancierslijst is mogelijk langer in vergelijking met wanneer de CMP's gescheiden zijn (aangezien een gecombineerde leverancierslijst alle leveranciers uit alle omgevingen moet bevatten)
- geen mogelijkheid om bepaalde algemene instellingen te onderscheiden (bijv. algemene instellingen zoals privacy-URL, T&C-URL of juridische instellingen zoals ondersteuning voor GDPR, CCPA en andere)
- ingewikkelder wanneer verschillende ontwerpen moeten worden gebruikt (het gebruik van targeting kan nodig zijn)
Wat gebeurt er als twee verschillende CMP's worden gebruikt?
Als de CMP die wordt gebruikt in het native deel van de app een andere CMP is dan die in de webview, wordt de toestemmingsinformatie van de native SDK geïmporteerd in de webview CMP. In gevallen waarin er een verschil is tussen de doellijst en/of leverancierslijst van de twee CMP's, zal de importerende CMP (die in de webview) alle ontbrekende doelen en leveranciers behandelen als "geen toestemming" / "afgemeld". Om dit te illustreren gaan we uit van de volgende opstelling:
CMP in het oorspronkelijke deel van de app:
Doeleinden: A, B, C
Verkopers: 1, 2, 3
CMP in de webweergave:
Doeleinden: C, D, E
Verkopers: 3, 4, 5
In het geval dat de gebruiker accepteert in het oorspronkelijke deel is het resultaat:
CMP in het oorspronkelijke deel van de app:
Doeleinden: A=aanvaard, B=aanvaard, C=aanvaard
Verkopers: 1=aanvaard, 2 =aanvaard, 3 =aanvaard
CMP in de webweergave:
Doeleinden: C=aanvaard, D=verworpen, E=verworpen
Verkopers: 3=aanvaard, 4 =verworpen, 5 =verworpen
In het geval dat de gebruiker verwerpt in het oorspronkelijke deel is het resultaat:
CMP in het oorspronkelijke deel van de app:
Doeleinden: A=verworpen, B=verworpen, C=verworpen
Verkopers: 1=verworpen, 2 =verworpen, 3 =verworpen
CMP in de webweergave:
Doeleinden: C=verworpen, D=verworpen, E=verworpen
Verkopers: 3=verworpen, 4 =verworpen, 5 =verworpen
Let op: dat zijn gedrag onafhankelijk is van de toewijzing van de verkopers aan doeleinden. Dit betekent dat het resultaat hetzelfde zal zijn als hierboven beschreven, zelfs als alle leveranciers zijn toegewezen aan doel C.
Let op: dat zijn gedrag ook onafhankelijk is van de gebruikte rechtsgrondslagen van elke verkoper/doel en onafhankelijk van het rechtsgebied waarin de gebruiker zich bevindt.
