Essential Mode - Data Stream Options
In the basics guide (JENTIS Essential Mode) we covered how to install and use the Esssential Mode in JENTIS Tag Manager. With that in mind in this guide we will make a deep dive into Essential Mode tracking and options on further customizing your JENTIS setup.
Please be aware that this only covers technical functionalities of integration and is not a legal assessment or consulting.
Essential Mode Basics
JENTIS Essential Mode is a feature that allows a data stream to operate in a fallback configuration. This feature can apply different schemas on individual property values, such as anonymization or pseudonymization of respective values transmitted to a connected tool. In simpler terms, if you can't justify the need for certain data (e.g. if consent is denied), you can fall back on JENTIS Essential Mode to receive only data that doesn't require the same level of justification (e.g. anonymized data, which is not subject to GDPR regulations). You can find more details about this feature in the general guide at JENTIS Essential Mode.
Vendor Consent Settings
Every vendor in JENTIS Tag Manager terms has a consent settings option. This enables you to decide, based on your configuration of which data will be processed with this vendor, if consent is applicable or not.
The options you have are:
Consent Mode: tools related to this vendor will activate only when consent from the user was received.
Essential Mode: you have the option to apply a split configuration in each tag of this vendors tools. A version for consent given and a different version when consent is denied.
No Consent Mode: this tool will activate straight away without considering the consent.
JENTIS Consent Engine Processing
The consent setting is vital to your data landscape and has many implications. While "Consent" is selected a tools tags will not be executed until an explicit interaction of the user with the Consent Management was registered. Either consenting to the usage of that tool or denying consent. Users ignoring the CMP banner will bring this tools data to a halt.
This sequence of processing is important to better understand how and when tags are executed in the JENTIS Tag Manager. All vendors with the justification "consent" will not be executed any sooner than the explicit consent decision of the user, which in consequence means a bouncing user is never registered in a tool with that justification setting.
The following states a vendor can have in the JENTIS Consent Engine:
true (consent explicitly given)
false (consent explicitly denied)
ncm (no consent - essential mode must be used)
undefined (no status known yet)
NCM and FALSE are dichotomous
Please be aware that the status "ncm" can only be present when a vendor has the Essential Mode enabled, thus meaning that "false" can not be a valid status for this vendor any more. It is then either "true" or "ncm" but it can not be "false" as long as the Essential Mode is activated for this vendor.
Non-Consent Justifications Default
If a tools justification is defined as "No Consent Mode" (from the three options on a vendor) the internal system value for the consent setting will default to "true" (same as explicit consent) and not change or update on any interaction of the user.
The processing of data in JENTIS follows primarily the internal data schema and generic sequences. Where commands such as "track:submit" will initiate a JENTIS Tag Manager State which in turn means triggers are evaluated and tags are activated. However a second layer atop on this foundation is the JENTIS Consent Engine. Without consent nothing moves, as long as the Consent Engine is turned on (which is the default).
Reprocessing
A special function of the JENTIS Consent Engine is the reprocessing of commands as consent information is updated. The following processing is only applied when a scope is not changed (ie. when a page is reloaded and therefor the JavaScript scope is reset). All tracking commands will be available and reprocessed every time a consent setting is changed on a tool (meaning a JENTIS vendor).
So all JENTIS States (ie. "track:event", "track:submit" or any other custom state implemented) will be processed in context of a consent. If that consent for a tool is changed the data will be reprocessed, if a tool is granted consent for example. To better understand this concept please see the following step by step section.
Note that on single page applications (reactJS and other frameworks that simulate navigation via the browser history API and load content asynchronously) a navigation within this app also resets this reprocessing. So even though a pageview or event might be pushed and still available in the scope technically, JENTIS will reset its internal cache and treat single page apps and regular page reloads the same. No reprocessing is possible in this circumstance.
To better take control if the reprocessing reset (per navigation on the same page scope) should be active or not there are two functions.
JavaScript
window.jentisApp.reprocessingCache_deactivate_reset();
window.jentisApp.reprocessingCache_activate_reset();You can decide if in your application the reset of reprocessing must be active or deactivated. Per default the reset is active (meaning that a reset of the reprocessing happens on navigation within the page). To have a processing regardless of navigation you must call the "..._deactivate_reset()" function.
Reset Call Timing
Make sure to call the according function (deactivate or activate reset) BEFORE JENTIS is initialized fully. In JTM you must use the trigger “Before JENTIS Bundle Load” to achieve this, or, if it is to be called by your web application, you must make sure to make the call together with the JTM Container code snippet.
Step by Step Use Case
With that in mind we must also consider some loops and sequences that are very common scenarios. Let's examine those step by step.
Vendor settings for this example:
myAnalyticsService:
consent setting: no consent mode
myMarketingService:
consent setting: essential mode
Step - Description | Commands | Consent Status | Result |
|---|---|---|---|
Page load initiated | _jts.push({ | myAnalyticsService: true myMarketingService: undefined (default consent status) | Analytics Pageview-Tags are executed with no restrictions (as the justification setting does not require consent). Marketing Tags not executed (as neither consent or deny signal was explicitly provided by the user). |
Alternative A: | - | myAnalyticsService: true myMarketingService: true | Analytics Pageview-Tags are not executed, as the consent setting did not change. Marketing Pageview-Tags are executed with no restrictions (reprocessed command, as the consent setting changed from "undefined" to "true"). |
Alternative B: | - | myAnalyticsService:true myMarketingService: ncm | Analytics Pageview-Tags are not executed, as the consent setting did not change. Marketing Pageview-Tags are executed with restrictions (Privacy Mode Configuration; reprocessed command, as the consent setting changed from "undefined" to "ncm"). |
A Fourth Option - Essential Mode Delivered Immediately
Next to the three discussed options "Consent", "Essential Mode" and "No Consent Mode" we often receive the question on whether the "Essential Mode" should be treated the same way as "No Consent Mode" on the level of essential data.
Meaning that the "fallback" configuration (of only essential data provided to the tool) will execute right away. Technically speaking "why awaiting the decision, if that has no effect on the outcome". As the essential mode is meant to be a fallback with highly limited and/or fully restricted access to PII. So activating a tag immediately will benefit from having all data (even of bouncing users) to complete your picture on analytical purposes.
However this has more implications than it looks like on the first glance. As by design a tools tags with essential mode activated have the same trigger (regardless of the mode). Changing the moment of activation would have an effect on this trigger and reprocessing of the data. Which can not be solved conveniently and natively in JENTIS for all accounts without assumptions that can not be centralized. Basically if a tag already was executed for a given tracking command (ie. "track a pageview" and that is executed immediately when page loads before any explicit consent decision by the user) a second pageview will not be tracked if consent was granted. Resolving all this possibilities is a very complex task and highly individual to all projects.
So if this fourth option is essential to your tracking - a custom solution will be mandatory. It is always possible to find a proper solution to your custom requirements, but at this point we do not offer an out of the box solution to this use case. But we are constantly working on improving this situation and there are features on the roadmap that will help to even resolve this use case in the future.
Turn Off Consent Engine in JENTIS Tag Manager
With the following setting you can turn off the Consent Engine in JENTIS Tag Manager. This will result in a configuration where no consent is awaited and tracking can be activated at any time. However all JENTIS Consent functionality is lost at the same time, disconnecting your Tag Management from any consent information.
Navigate to your account administration settings and select “Consent Administration”. Here you will find a toggle to apply this decision.
Warning: Be sure to only use this mode in respect of all legal consequences that are subject of your compliance assessment.
This setting will give you the option to apply different tool and tag configurations based on consent and even before the moment a user interacted with a consent banner. You can combine this with JENTIS Essential Mode.