Consent-Storage
CCM19 can store the data for consent in a cookie, in local storage or in session storage. The individual methods have advantages- and disadvantages.
Storage as a cookie
Saving the consent in a cookie allows the consent to be shared across several subdomains and different ports, but can slightly increase the page load time. This is the classic storage of data.
Storage in local storage
Storing the consent in local storage allows the information to be retained indefinitely in many browsers. However, the consent is limited to a hostname-port-combination.
Storage in session storage
Saving the consent in the session storage keeps the consent separate for each browser-tab. The moment the tab is closed, the consent is also forgotten.
Properties of the CCM19 element
You can use the mask to specify how long the CCM19 cookie should be stored (default is 365 days). If you enter a "0", the cookie will be deleted when you close the browser.
The option for "secure" cookies should only be deactivated if HTTPS/SSL is only used optionally. This allows the consent to be shared between the page without HTTPS and the one with HTTPS - but this is extremely rare nowadays. In addition, disabling this option can cause problems with the remaining consent-sharing-functions and when embedding the website in iframes due to the security functions of modern browsers.
Consent-Sharing (Cross Domain Sharing)
With CCM19 it is possible to share consent across any number of domains and subdomains independently of third-party-cookies. To do this, enter the domains with which the consent is to be shared in the field.
This function is only available in Business- and Enterprise-tariffs and the Agency-variant.
For each domain entered, the consent can be shared between the subdomains of the domain entered, as long as the same code-snippet is used. For example, enter example.com so that consent only needs to be granted once for example.com, www.example.com and all other subdomains ending in .example.com. Invalid entries can cause the saving of the consent to function unreliably
The consent is passed on via HTML-links, HTML-forms and iframes.
Consent-Sharing in the iframe
If you display another website in an iframe on your website, for example a booking form, the banner will not appear again in the iframe, but the consent will be transferred. This only works if the website integrated via iframe is entered in the list for consent-sharing and the same script is used on the page as on the main domain.
Force cookie reset
These settings can be used to force all visitors who have given their consent before the set date to see the banner again. This function is relevant if you have made changes to the cookie-banner and want to make sure that returning visitors can also decide again whether they (re)agree to the new guidelines.
Consent-Lifetime
Consents older than this period are always canceled. If you leave the field empty or set it to "0", CCM19 will not automatically revoke consent. Please note that if you use TCFv2, a maximum of 390 days (approx. 13 months) is enforced.
If the option "Automatically revoke consent in the event of legally relevant changes" is activated, legally relevant changes to integrations and cookies mean that consent is no longer valid and is requested again. This includes the following changes:
Integrations:
- Name
- Purpose
- Manufacturer/provider (also TCF-provider)
- Description
- Data protection-URL
- Data collected
- Purpose of the collection
- Legal basis
- Place of processing
- Cookie & Co. (Add/Delete/Edit [See EmbeddingAsset])
- Google Consent Mode consents
- TCF purposes
- TCF special processing options
Embedding Asset: (list of cookies and storage elements in an embedding)
- Name
- Description
- Storage type
- Expiration
Cookies: (Old management structure)
- Cookie name
- Name of the cookie in the browser
- Purpose of cookie
- Manufacturer/provider
- Cookie description
- Lifetime of the cookie
- Data protection-URL
- Data collected
- Purpose of the collection
- Legal basis
- Place of processing
.jpg)
.jpg)

