I många fall består en mobilapp av en native del (t.ex. skriven i Java, Kotlin eller C++ osv.) och en webbdel (vanligtvis genom att infoga en webbvy i appen). För att optimera användarupplevelsen finns det några rekommendationer och implementeringsstrategier som du kan använda.

Grundinställningar

Generellt rekommenderar vi att du använder vårt SDK för iOS eller Android för att integrera CMP i din app (native-delen). CMP aktiveras vanligtvis när appen startas, visar samtyckeslagret och låter användaren göra sina val. När användaren har gjort sina val tar SDK bort samtyckeslagret och appen fortsätter.

I de fall appen innehåller en webview måste innehållet i denna webview (t.ex. en webbsida som innehåller reklam) också veta om samtycke har givits, och stöd för API:er som IAB TCF eller IAB GPP kan behövas. Därför bör webbsidan som laddas i webbvyn också innehålla CMP-koden (HTML-implementering av koden).

Utbyte av information om samtycke

Med ovanstående grundinställning är problemet att användaren kommer att tillfrågas två gånger: en gång när appen startas och en gång varje gång en (ny) webbvy öppnas. För att undvika detta kan samtyckesinformationen utbytas mellan SDK och webbvyn. Detta görs genom att exportera samtyckesdata från SDK och bifoga den till den URL som laddas i webbvyn.

Exempel:

// 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)

 

Funktionen exportCMPInfo finns för båda SDK:erna, iOS och Android.

När webvyn har laddats kommer CMP-koden i webvyn att köras och hitta hash-värdet (#cmpimport=.....) i URL:en. CMP:n importerar automatiskt dessa samtyckesdata och använder inte längre data från cookies eller lokal lagring. Eftersom samtyckesdata har importerats till CMP:n bör samtyckeslagret normalt inte visas (igen) eftersom användarens samtycke redan finns.

Finjustering

Som ett sista steg kan det finnas några finjusteringar som du kanske vill göra.

Å ena sidan bör CMP-koden som är integrerad i webbvyn inte visa ikonen för inställningscentret (vanligtvis längst ned till vänster i webbläsarfönstret, där besökare kan uppdatera sina val). För att inaktivera ikonen, gå till Meny > Juridiska inställningar > GDPR/CCPA/… > Visa inställningsikon.

Å andra sidan, även med #cmpimport=... i URL:en, kan det fortfarande finnas fall där CMP:n beslutar att visa samtyckeslagret i webview. För att undvika detta rekommenderar vi att lägga till en konfigurationsvariabel på klientsidan till alla sidor som visas inom webview:

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

Detta förhindrar att samtyckeslagret visas.

Vanliga frågor

Kan jag använda samma CMP i SDK och webview?

Ja. För systemet spelar det ingen roll om samma CMP eller en annan CMP används i SDK, din webbvy och/eller din vanliga webbplats. Du kan använda samma CMP eller olika CMP:er i alla miljöer och alla CMP:er kan importera samtyckesdata från varandra.

Eftersom appen i de flesta fall har andra krav på beteende och design är det dock oftast bättre att skilja på app-CMP:er och webb-CMP:er. Detsamma gäller för design: Generellt kan samma design användas i alla miljöer, men i många fall är det vettigt att ha en separat design för appmiljön.

Vilka är för- och nackdelarna med att använda samma/en annan CMP?

Här är några fördelar med att använda samma CMP i alla dina miljöer:

• Enklare hantering av leverantörslistor, syften och cookies eftersom alla miljöer använder samma konfiguration
• Ingen friktion när samtyckesdata överförs från en miljö till en annan

Detta är nackdelarna med att använda samma CMP i alla dina miljöer:

• Leverantörslistan är potentiellt längre jämfört med när CMP:erna är separerade (eftersom en kombinerad leverantörslista måste inkludera alla leverantörer från alla miljöer)
• Det går inte att skilja på vissa allmänna inställningar (t.ex. allmänna inställningar som URL för integritetspolicy, URL för användarvillkor eller juridiska inställningar som stöd för GDPR, CCPA och andra).
• Det blir mer komplicerat när olika design ska användas (det kan bli nödvändigt att använda målgruppsanpassning).

Vad händer när två olika CMP:er används?

Om den CMP som används i den inbyggda delen av appen är en annan CMP än den i webbvyn, importeras samtyckesinformationen från det inbyggda SDK:t till CMP:n i webbvyn. Om det finns en skillnad mellan ändamåls- och/eller leverantörslistan för de två CMP:erna kommer den importerande CMP:en (den i webbvyn) att behandla alla saknade ändamål och leverantörer som ”inget samtycke”/”avregistrerad”. För att illustrera detta, låt oss anta följande uppställning:

CMP i den inhemska delen av appen:
Syften: A, B, C
Leverantörer: 1, 2, 3

CMP i webbvyn:
Syften: C, D, E
Leverantörer: 3, 4, 5

Om användaren accepterar i den inhemska delen blir resultatet:

CMP i den inhemska delen av appen:
Syften: A=godkänt, B=godkänt, C=godkänt
Leverantörer: 1=godkänt, 2=godkänt, 3=godkänt

CMP i webbvyn:
Syften: C=godkänt, D=avvisat, E=avvisat
Leverantörer: 3=godkänt, 4=avvisat, 5=avvisat

Om användaren avvisar den inhemska delen blir resultatet:

CMP i den inhemska delen av appen:
Syften: A=avvisad, B=avvisad, C=avvisad
Leverantörer: 1=avvisad, 2=avvisad, 3=avvisad

CMP i webbvyn:
Syften: C=avvisad, D=avvisad, E=avvisad
Leverantörer: 3=avvisad, 4=avvisad, 5=avvisad