Consent Management

What the consent abstraction does

A storefront usually loads scripts from several vendors (analytics, ads, chat, retargeting). Each vendor needs the visitor's consent before it runs, and what consent is given for is a purpose — why the data is processed — not a vendor. Laioutr's consent layer separates the two: your code asks "does the visitor consent to analytics?" and the active CMP (Cookiebot, CCM19, OneTrust, custom) answers. Switching CMPs later is a config change, not a rewrite.

The abstraction gives you a consent store with five fixed purposes and a provider-agnostic useConsentStore() composable. A consent adapter maps a concrete CMP's own vocabulary onto them. Other Laioutr features (tracking, GTM) read the store too, so a single source of truth gates every consented behaviour in the frontend.

const consentStore = useConsentStore();

if (consentStore.hasPurposeConsent('analytics')) {
  loadHeatmapScript();
}

The store lives in @laioutr-core/frontend-core. Your Nuxt app must include the module so useConsentStore() and the #frontend/consent types are available.

The five consent purposes

Every adapter translates its CMP's own vocabulary into this fixed shape, so the rest of the app only deals with one model:

The store keeps a single state object with these five booleans. Whenever the visitor accepts or revokes something in the CMP, the active adapter pushes the change into the store, and state updates reactively.

Frontend Core splits its own campaign attribution across two of these: ad click ids such as gclid are stored only under advertising, while utm_* parameters and the entry record need analytics.

A purpose describes processing; a cookie category classifies an artifact. The two are not the same question, and only the first one has an answer for every recipient — a server-side subscriber forwarding orders to a warehouse writes nothing to the browser, so it has no category, but it plainly has a purpose. Adapters therefore report purposes, and a CMP that models categories maps them across. Where a CMP's vocabulary is coarser than ours the mapping loses precision: Cookiebot has one marketing bucket, so it grants advertising and personalization together and a visitor cannot separate them. That is a property of the CMP, not of this API.

Using the consent store

useConsentStore() is scoped to the Nuxt app rather than shared as a process-wide global. On the server that means one store per request: consent is request data, and a process-global would hand one visitor's answers to the next. Auto-imported by frontend-core, you can call it from any component, composable, or plugin.

The methods you will use most:

hasDecision() can return undefined as well as true or false. undefined means no decision signal exists at all — either no CMP adapter is installed, or the installed one has no way to report whether the visitor answered. That is not the same as a visitor who was asked and declined; treat undefined as "unknown", not as "no".

A typical "Cookie preferences" footer link:

<script setup lang="ts">
const consentStore = useConsentStore();
</script>

<template>
  <button type="button" @click="consentStore.openConsentUi()">
    Cookie preferences
  </button>
</template>

Reacting to consent changes outside a template (for example, lazy-loading a chat widget once the visitor accepts advertising):

const consentStore = useConsentStore();

consentStore.onConsentChange((consent) => {
  if (consent.advertising) {
    loadChatWidget();
  }
});

How other features read consent

The store is consumed across the platform, not just by your code:

• The analytics layer gates delivery per destination. A destination declares consent: { purposes: ['analytics'] }, and the bus only hands it an event once that purpose is granted. A destination may also declare onDenied to receive events under refusal in a degraded form rather than going silent. Read the state directly with hasPurposeConsent('analytics') or getPurposeConsents().
• The GTM app sets Google Consent Mode v2 defaults to denied inline in the head, before gtm.js loads, then sends an update once the visitor has actually answered — not when the CMP merely reports its default.

This means once a CMP adapter is active and the user has accepted analytics, GA fires through GTM without any further wiring in your app.

Ready-to-use consent apps

There already are a few standalone Laioutr apps that register a ConsentAdapter for you: the Cookiebot app and the CCM19 app. Add the module, set the credentials, and the store and tracking/GTM consent are wired up.

Building your own consent adapter

If you need a CMP that is not on the list (OneTrust, CookieYes, an in-house solution), you can build a Laioutr app that registers a ConsentAdapter with the store. The full contract, plugin boilerplate, and worked examples drawn from the Cookiebot and CCM19 sources live in Consent Adapters under app development.

Summary

• One store, five purposes, one set of methods. Write your code against useConsentStore() and stop caring about which CMP is behind it.
• Use hasPurposeConsent(purpose) to gate behaviour, onConsentChange to react, and openConsentUi for "Cookie preferences" UI.
• Drop in Cookiebot or CCM19 for ready-to-use providers, or build your own following the Consent Adapters guide.