Combining native and web content in an app
In many cases an mobile app consists of a native part (e.g. written in Java or Kotlin or C++ and so on) and a web-part (usually achieved by inserting a webview into the app). In order to optimize the user experience, there are some recommendations and implementation strategies that you can use.
Core setup
In general we recommend using our SDK for iOS or Android in order to integrate the CMP into your app (native part). The CMP will usually be triggered on app start, display the consent layer and let the user make its choices. Once the user made the choices, the SDK will remove the consent layer and the app will continue.
In cases when the app includes a webview, the content in this webview (e.g. a webpage that contains advertising) will also need to know if consent was given and support for APIs such as the IAB TCF or IAB GPP might be needed. Therefore the webpage that is loaded within the webview should also include the CMP code (HTML-implementation of the code).
Exchanging consent information
With the above core setup, the problem is that a user will be asked twice: Once on app start and once every time a (new) webview opens. In order to avoid this, the consent information can be exchanged between SDK and webview. This is done by exporting the consent data from the SDK and attaching it to the URL that is loaded within the webview.
Example:
consentData = CMPStorageConsentManager.exportCMPData(this);
myWebView.loadURL("https://mywebsite.com/....#cmpimport=" + consentData);(An export function exists for both SDKs, the above example is taken from the iOS examples)
Once the webview loads, the CMP code in the webview will execute and find the hash (#cmpimport=.....) in the URL. The CMP will automatically import this consent data and no longer use data from cookies or local storage. Since the consent data has been imported into the CMP, the consent layer should normally not appear (again) because the user consent already exsits.
Please note, that consent information can only be shared from the SDK to the webview and not in the opposit direction.
Fine tuning
As a last step there might be some fine tuning that you will like to do.
On the one hand, the CMP code that is integrated into the webview should not show the preference center icon (usually on the left lower side of the browser window, allowing visitors to update their choices). In order to disable the icon, please go to Menu > Legal settings > GDPR/CCPA/... > Show Preferences Icon.
On the other hand, even with the #cmpimport=... on the URL, there can still be cases, when the CMP decides to show the consent layer in the webview. In order to avoid that, we recommend to add a client side configuration variable to all pages that are shown within the webview:
<script>
window.cmp_noscreen = true;
</script>
... your CMP-Code ...This will prevent the consent layer from being shown.
FAQ
Can I use the same CMP in the SDK and the webview?
Yes. For the system it does not matter whether the same CMP or a different CMP is used in th SDK, your webview and/or your normal website. You can use the same CMP or different CMPs in all environments and all CMPs can import the consent data from each other.
However, since in most cases the app has different needs in regards to behavior and design, it is usually better to separate app-CMPs and web-CMPs. The same is true for designs: In general the same design can be used in all environements, but in many cases it makes sense to have a separate design for the app environment.
Recommendation: If you are using different CMPs in your app and in your website, we recommend to use the same CMP, that is used in the native part of your app, to also use it in the webviews within your app too.
What are the Pro's and Con's of using the same/a different CMP?
Here are some advantages of using the same CMP in all your environments:
- easier management of vendorlists, purposes and cookies since all environments use the same configuration
- no friction when consent data is transfered from one environment to another
These are the downsides of using the same CMP in all of your environments:
- vendorlist is potentially longer compared to when the CMPs are separated (since a combined vendor list needs to include all vendors from all environments)
- no possibility to distinguish certain general settings (e.g. general settings such as privacy URL, T&C URL, or legal settings such as support for GDPR, CCPA and others)
- more complicated when different designs should be used (using targetings might be necessary)
What happens when two different CMPs are used?
In case the CMP used in the native part of the app is a different CMP than the one in the webview, the consent information from the native SDK is imported into the webview CMP. In cases when there is a difference between the purposelist and/or vendorlist of the two CMPs, the importing CMP (the one in the webview) will treat all missing purposes and vendors as "no consent" / "opted out". In order to illustrate this, lets assume the following setup:
CMP in the native part of the app:
Purposes: A, B, C
Vendors: 1, 2, 3
CMP in the webview:
Purposes: C, D, E
Vendors: 3, 4, 5
In case when the user accepts in the native part, the result will be:
CMP in the native part of the app:
Purposes: A=accepted, B=accepted, C=accepted
Vendors: 1=accepted, 2=accepted, 3=accepted
CMP in the webview:
Purposes: C=accepted, D=rejected, E=rejected
Vendors: 3=accepted, 4=rejected, 5=rejected
In case when the user rejects in the native part, the result will be:
CMP in the native part of the app:
Purposes: A=rejected, B=rejected, C=rejected
Vendors: 1=rejected, 2=rejected, 3=rejected
CMP in the webview:
Purposes: C=rejected, D=rejected, E=rejected
Vendors: 3=rejected, 4=rejected, 5=rejected
Please note that his behavior is independent of the assignment of the vendors to purposes. This means the result will be the same as outlined above, even if all vendors are assigned to purpose C.
Please note that his behavior is also independent of the used legal bases of each vendor/purpose and independent of the jurisdiction in which the user is.
