Storefront cookie policy

The WS8 storefront allows the shop owner to enable a cookie policy dialog/overlay for the end user(customer) in the webshop.

Feature setup

The feature is configured using Admin > Settings > Shop settings > Layout > Cookie policy

The cookie policy have two different modes:

  • A “passive info” mode, that will just display the overlay once, showing the defined policy message (like “this site is using cookies”)
    In this mode, no cookies will be blocked and the overlay will ONLY contain the message
  • A “block cookies before consent” mode, that will show the overlay on each request until the end user chooses to accept (or not accept) tracking/marketing cookies.
    In this mode, the native Google analytics, Google remarketing, Google tagmanager and Facebook pixel in the webshop, will NOT start working (and set cookies) until the end user accepts tracking/marketing cookies.

Because activating the “block before consent” mode will have an instant affect on how eg. the native tracking cookies work, the user is prompted for the change with a confirm dialog, that also contains a link to the help section where the the cookie policy feature is explained in depth.

Cookie policy terms

Since it might be required for the shop owner to have some legal text that explains what they are using cookies for and how they do it, the shop have a section of the /shop/terms.html page reserved for this.
It will be the shop owners responsibility to provide the end user with a link to this page from somewhere in the shop UI.

The URL parameter &HideCookieDialog=1 can be used to hide the cookie popup, when the customer follows the link to the terms page

To guide the user to the cookie park of the terms page, an anchor at /shop/terms.html&HideCookieDialog=1#cookieconsent can be added to the link

Cookie details

CookieDetails – automatic detection of native cookies

To expose meta data about cookies that could be set in the shop storefront, the WS8 system contains a table called CookieDetails with cookie meta data.The CookieDetails table is maintained to contain information about known cookies in the WS8 system, both native/core cookies and third party cookies set by standard functions on secondary domains.

  • The CookieDetails list is ONLY in either Danish or English based on the site language
  • Cookies set on primary domains, that are NOT mapped in the CookieDetails table, will have all its meta data displayed as “unknown” until data is added to the table.
    Cookies set on secondary domains, that are NOT mapped in the CookieDetails table, can’t be detected, and will need to be added manually.

The table contain these columns

  • Name – the name of the cookie, this is the main key used by the storefront to match a cookie stored on the client with meta data
  • Description – this description will be shown as meta data for ANY non danish site (from site language setting)
  • DescriptionDK – this description will be shown as meta data for DANISH sites (from site language setting)
  • Category – this MUST contain one of these enum values, it will be used to indentify the cookie category (only for label purpose)
    • system
    • tracking
    • functional
    • statistics
  • ExpireDays – the time that the cookie lives in the client when set
    • Sessions cookies will have 0 in both expire columns
  • IsThirdParty – indicates if the cookie is considered a 3.party cookie, cookies marked with true in this column, will have the text from the ThirdPartyAuthor column displayed in the cookie details section of the storefront
  • ThirdPartyAuthor – name or/and details about the 3.party author of a cookie, eg. “Google LLC” for google analytics

The cookie meta data from the CookieDetails is cached for 2 minutes in an application variable, which means that any changes made to this data can take up to 2 minutes to appear.
This cache is global for the entire shop and cannot be cleared by any “clear cache” parameters

 

CookieDetails – local shop meta data

To also show details about cookies that might have been set as 3.party cookies on a different domain than the one hosting the shop (eg. analytics), it is possible for the shop owner to maintain list of cookie meta data from their admin which will be merged with the details from the native cookies meta data. These local shop meta data will exist for EACH shop individually and will be displayed REGARDLESS if the cookies are actually set on the client (since it is not possible for script running on the shop to read cookies set on different domains)

  • Descriptions and expire texts are maintained for each site
  • Since cookies set on different domains can have same names, the shop owner can add local cookie meta data with duplicate names
  • If a local cookie meta data record have the same name as a cookie defined in the native meta data table, it will be shown INSTEAD of the native cookie meta data, which also means it will be shown even though the cookie have not been set on the client yet

CookieDetails – API v2 endpoints

API v2 CRUD endpoints have been created, to allow updating the local shop cookie list when installing or updating an app.
The endpoints are divided in two, where both are needed to create a complete entry for the cookie meta data list

POST /v2/cookies – will create a new cookie ID containing name, third party information & category

POST /v2/cookies/{id}/translations/{siteId} – to specify cookie description, third party author description & expire information for each cookie and site

All endpoints can be found in Swagger under Cookiedetails

Example

How meta data is displayed in storefront

Details about cookies (both from native and local meta data table) is displayed in a grid that can be toggled on the cookie consent dialog and the same grid can be added to the cookie description text on the terms page by using the replace variable [[CookieDetails]].

The WS8 storefront allows the shop owner to enable a cookie policy dialog/overlay for the end user(customer) in the webshop.

Changing previous given consent

If an end user want to change the given cookie consent, this is done by appending a querystring parameter called “ChangeCookiePolicyConsent” to any shop storefront url.
This implementation of a link for this is a task for the shop owner as it will depend much on the shop layout where such a link belongs.
For example a link could be added to the shops storefront like “/shop/frontpage.html?ChangeCookiePolicyConsent=1

When such a link is requested by the client two things will happen:

  1. The cookie used to indicate that consent have already been given (which hides the policy overlay) will be deleted, this making the overlay re-appear
  2. The shop will do a 302 to the same route but with the value of the ChangeCookiePolicyConsent changed to 0. This will make sure reset the cookie consent to its starting point.

End user cookie consent history (GDPR)

Any time an end user gives or changes their consent for cookies, this is logged in the shop database.

  • Since GDPR rules dictates that even log history cannot be stored forever, the shop anonymizer service will delete any cookie policy consent data older than 5 years. There is NO setting to change or deactivate this automatic deletion
  • If a shop customer invokes their GDPR right to access or to be forgotten, the shop admin can manage log data through the “Settings→Admin settings” section of the admin. This will require the end user to provide the shop owner with the IP address reported by their client when they made changes to cookie consent
  • If a shop owner want to force deletion of cookie consent log data faster than the 5 years done by the anonymizer, they can use the Maintenance section of the admin settings page to choose a specific date. Note that this will delete ALL consent logs based on choosen date.

Cookies set by custom scripts and 3.party apps

Because app partners and shop owners can inject javascript that sets cookies, the “block cookies before consent” mode, requires these scripts to handle the cookie consent int their scripts, in order to make sure no tracking/marketing cookies will be set without the end user consent.

To do this, the WS8 system provides the app partners with a way of reading the status of the end user consent.

  1. A global javascript variable named “CookiePolicy” will be present in the DOM of all shop pages This variable will hold information about
    1. If the shop is running in the “block cookies before consent” mode, this is read using the cookiesRequireConsent property
    2. If the end user have given consent to setting tracking/marketing cookies, this is read using the allowTrackingCookies property
    3. If the end user have given consent to setting functional cookies, this is read using the allowFunctionalCookies property
    4. If the end user have given consent to setting statistics cookies, this is read using the allowStatisdicsCookies property

When a javascript that sets cookies are injected into the webshop either by an app or manually by adding the script to shop code script fields, the author of the script have different options to adjust their script to make it comply to the cookie consent given by the end user.

Implement cookie consent logic and consent revoke logic in the script it self

1. This requires the script to be adjusted to make conditions (using the global CookiePolicy variable) that only sets cookies if the consent is given.
2. When the end user changes their consent to cookies, the app script developer should make sure to remove any cookies they have that does not comply to the given cookie consent by looking at the CookiePolicy variable

Example

Download .zip file with javascript example by clicking here

Adjust both inline and included script tags to make the shop enable them only if consent is given

Inline scripts
  1. This requires the type attribute of <script> tags used by the custom script to be adjusted to make sure they are only executed if consent is given
  2. Inline scripts must be changed to have the type attribute set to “text/plain” and be decorated with a style attribute that tells which kind of cookie this script sets
    1. cpc-script-inline-tracking
    2. cpc-script-inline-functional
    3. cpc-script-inline-statistics
  3. The shop will enable/run the script on page load based on the given cookie consent
  4. Example: <script data-cpc-src=”/javascript/cookie-tracking-example.js” class=”cpc-script-src-tracking”></script>
  5. It is important to include a script which removes any cookies set by the app/script, when cookie consent is revoked (see example code below)

Example

 


Du finder dokumentationen til DanDomain Webshop her: https://webshop-help.dandomain.dk x