Configuration by URL
This section describes how to override the configuration of the Didomi Web SDK through query-string parameters in the URL.
Configuration options should be done through the Didomi Console or through local configuration variables/files. Configuration by URL should only be used in specific cases like testing/previewing AB tests or disabling a notice in a WebView.
Didomi allows some configuration properties to be passed via query-string parameters in the URL if you want to test or preview changes on the fly. The configuration passed in the query string is merged into the remote configuration (from the Console) and the local configuration (from window.didomiConfig
).
Allowed properties to be passed by URL
For security reasons, we currently only allow the properties below:
notice.enable
notice.showDataProcessing
experiment.group
app.vendors.iab.version
Query-string parameters
You can either pass a full Didomi configuration object via a didomiConfig
parameter or a specific attribute via didomiConfig.*
.
Full configuration
To override more than one attribute, we suggest to use the didomiConfig
parameter. It allows you to provide a full Didomi configuration object encoded as JSON. The format and content of the object is the same as the window.didomiConfig
object added to a webpage so any option that can be passed there can be passed in the query string.
First, encode your configuration object as url-encoded JSON so that it can be read properly by the browser. You can use this online encoder to convert your JSON object into a readable query-string parameter.
For example, { "notice": { "enable": false } }
will become %7B%20%22notice%22%3A%20%7B%20%22enable%22%3A%20false%20%7D%20%7D
and the URL will be:
Specific configuration
If you want to override only one attribute, it may be faster and easier to use the didomiConfig.*
parameter. It allows you to edit a specific attribute via a dot notation.
Use a dot notation to go deeper into the configuration tree. For example, { "notice": { "enable": false } }
will be written as didomiConfig.notice.enable=false
and the URL will be:
Use cases
Configuration should never be passed via URL except for specific cases for temporary preview or testing. Here are a few cases where configuration via URL can be useful:
Force group test for AB tests
If you run AB test, it can be difficult to see how it looks on production, especially if the size of your test is small. To avoid you from clearing your cache and refreshing the page until you see the test configuration, you can force the test group to test
or control
.
Force your website to display the test group configuration :
Disable notice in a WebView (Mobile Apps)
If you are opening WebViews in your mobile apps, you can share the consent status of the user from the app to the WebViews. This allows you to not re-collect consent on the web pages.
In some cases, the notice might be displayed for a short time before being hidden in the WebView as the consent gets passed. To avoid that visual glitch, you can disable the notice in your WebView to make sure that it never shows:
Force the Transparency and Consent Framework (TCF) version
If you want to transitioned to the TCF v2 and would like to have a preview on how it will impact your website, you can force the version via URL. The authorized values are 1
et 2
.
Force your website to display the notice with a specific version of the TCF :
Display the data processing list in your notice
If you want to have a preview on how the data processing list will impact the UI of your notice, you can display it by switching showDataProcessing
to true
.
Force the data processing list to be displayed in the notice :
Last updated