Consent-Storage

CCM19 can store consent data in a cookie, in local storage, or in session storage. Each method has ad- s and disadvantages.

Storage as a Cookie

Storing consent in a cookie allows the consent to be shared across multiple subdomains and different ports, but may slightly increase page load time. This is the traditional method of storing the data.

Storage in Local Storage

Storing consent in local storage allows the information to be retained indefinitely in many browsers. However, consent is limited to a single combination of hostname-and port-.

Storage in Session Storage

Storing consent in session storage keeps 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 form to specify how long the CCM19 cookie should be stored (the default is 365 days). If you enter a "0," the cookie will be deleted when the browser is closed.

The option for “secure” cookies should only be disabled if HTTPS/SSL is used only optionally. This allows consent to be shared between pages without HTTPS and those with HTTPS—though this is extremely rare these days. Furthermore, due to the security features of modern browsers, disabling this option may cause issues with the remaining consent-sharing-functions and when embedding the website in iframes.

Consent-Sharing (Cross-Domain Sharing)

With CCM19, it is possible to share consent across any number of domains and subdomains, independent of third---party-cookies. To do so, enter the domains with which you want to share consent in the field.

This feature is only available in the Business- and Enterprise-plans, as well as the Agency-variant.

For each domain entered, consent can be shared among the subdomains of that domain 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 may cause the consent storage to function unreliably.

Consent is passed via HTML-links, HTML-forms, and iframes.

Consent-Sharing in an Iframe

If you display another website in an iframe on your website—for example, a booking form—the banner will not reappear in the iframe; instead, the consent is transferred. This only works if the website embedded via iframe is included in the list for consent-sharing and if the same script is used on that page as on the main domain.

Force Cookie Reset

These settings allow you to force all visitors who gave their consent before the set date to see the banner again. This feature is relevant if you have made changes to the cookie-banner and want to ensure that even returning visitors can decide again whether to (re)consent to the new policies.

Consent-Lifespan

Consents older than this period are generally revoked. If you leave the field blank 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 case of legally relevant changes” is enabled, legally relevant changes to integrations and cookies will cause consent to no longer be valid and will trigger a new consent request. This includes the following changes:

Embeddings:

• Name
• Purpose
• Manufacturer/Provider (including TCF-providers)
• Description
• Privacy Policy-URL
• Data Collected
• Purpose of Collection
• Legal Basis
• Location of Processing
• Cookies & 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 embed)

• Name
• Description
• Storage Type
• Expiration

Cookies: (Old Administrative Structure)

• Name
• Name of the cookie in the browser
• Purpose
• Manufacturer/Provider
• Description
• Cookie Lifespan
• Data Protection-URL
• Data Collected
• Purpose of Collection
• Legal Basis
• Location of Processing