Use your own consent banner

The _fontdue_cc cookie is the contract between a consent banner and Fontdue analytics. Fontdue’s cookie consent banner writes it when a visitor responds, and both Fontdue’s in-page tracking script and its backend read it to decide whether analytics is allowed. If you already run your own cookie banner or a consent management platform (CMP), you don’t need Fontdue’s banner on top of it – write the same cookie yourself and Fontdue behaves exactly as if the visitor had accepted on its own banner.

The cookie

Fontdue recognizes two consent categories in the cookie value, stored as a comma-separated list: necessary and analytics. Analytics is treated as granted when the value, split on commas, contains the analytics token – nothing else about the value matters.¹¹Only the presence of the analytics token is checked, so _fontdue_cc=analytics grants analytics just as well. Writing necessary,analytics mirrors Fontdue’s own banner exactly, which keeps the value self-describing if you later add more categories. To match Fontdue’s own banner:

Set it with the same attributes Fontdue’s banner uses, so it persists for a year and is readable everywhere on your site:

document.cookie =
  '_fontdue_cc=necessary,analytics;path=/;max-age=31536000;SameSite=Lax;Secure';

Write it from in-page JavaScript with document.cookie, the way Fontdue’s banner does – not as a server-set cookie on a different domain – so both Fontdue’s in-page script and its tracking requests read the same value.²²Secure requires HTTPS, so the cookie won’t be stored over plain http://. That matches Fontdue’s own behavior and is fine in production; if you test over http://localhost, drop Secure locally.

Grant analytics when a visitor accepts

When Fontdue’s banner accepts, it does two things: writes the cookie, and dispatches a fontdue:consent window event so anything already running on the page picks up the change. Replicate both in your banner’s accept handler:

function grantFontdueAnalytics() {
  document.cookie =
    '_fontdue_cc=necessary,analytics;path=/;max-age=31536000;SameSite=Lax;Secure';
  window.dispatchEvent(
    new CustomEvent('fontdue:consent', {
      detail: { categories: ['necessary', 'analytics'] },
    }),
  );
}

Call grantFontdueAnalytics() when the visitor accepts the category your banner uses for Fontdue analytics – whatever you label it, such as Marketing & Statistics. Set the cookie before dispatching the event: Fontdue re-reads the cookie when the event fires, so the value has to be in place first.³³The event is an optimization, not a requirement. Without it, Fontdue still picks up the new cookie within half a second – it polls – and on the next page load. The event just makes analytics start during the current page view.

Once the cookie carries analytics, Fontdue links page views to a persistent visitor identity – the _fontdue_state cookie – from the next tracked page view onward. The page view already in flight when the visitor accepted stays anonymous, so the identity lags the moment of consent by one view.⁴⁴Fontdue’s own banner closes that gap by also sending a tracking request the instant the visitor accepts, which establishes the identity on the spot. If first-page attribution matters to you, trigger a page view of your own (for example a client-side route refresh) right after grantFontdueAnalytics().

Hide Fontdue’s own banner

Leave Require cookie consent turned on under Settings → Analytics. That setting is what keeps Fontdue cookieless until the cookie grants analytics – if you turn it off, Fontdue tracks every visitor regardless of what they chose on your banner, which defeats the point of gating on consent.

There’s no separate switch for the banner UI – Fontdue’s banner renders only when consent is required and no _fontdue_cc cookie is present when it mounts. So an existing _fontdue_cc cookie suppresses it: write one before Fontdue initializes – with necessary, which grants nothing – and Fontdue’s banner never appears, while consent stays gated until the visitor opts in through your banner.

Write that baseline as early as you can, so Fontdue’s banner has no chance to flash before your cookie lands. Reflect the visitor’s saved choice, defaulting to necessary until they’ve opted in:

const accepted = /* your banner's stored analytics decision */ false;
document.cookie =
  '_fontdue_cc=' + (accepted ? 'necessary,analytics' : 'necessary') +
  ';path=/;max-age=31536000;SameSite=Lax;Secure';

Where you run that depends on how Fontdue loads:

• Script-tag embed – set the cookie immediately before you call fontdue.initialize(...).
• React / npm package – set it before <FontdueProvider> mounts. In a server-rendered app, a small inline script in the document <head>, which runs before hydration, is the most reliable place.⁵⁵The banner starts hidden on the server and on first client paint to avoid a hydration mismatch, then a useEffect reveals it if no cookie is found. Writing the cookie before that effect runs is what closes the gap with no flash.

Mirror the visitor’s saved choice rather than a blanket necessary, so a returning visitor who previously accepted isn’t silently downgraded.⁶⁶Most consent platforms store the choice and expose a callback that fires on every load with the current state – write the cookie from there. A visitor who has already chosen never sees Fontdue’s banner, and a new visitor sees only yours.

Withdraw consent

If a visitor turns analytics back off, write the cookie without the analytics token and dispatch the event again:

document.cookie =
  '_fontdue_cc=necessary;path=/;max-age=31536000;SameSite=Lax;Secure';
window.dispatchEvent(
  new CustomEvent('fontdue:consent', { detail: { categories: ['necessary'] } }),
);

Fontdue stops linking new page views to a persistent identity from the next request onward and returns to cookieless counting.⁷⁷The cookie controls collection going forward; it doesn’t retroactively remove page views already recorded under a granted identity.

React sites

If your banner is a React component in a site using the fontdue-js package, the same cookie and event are all you need – there’s no React-specific API to call. The useConsent hook and any consent-gated scripts both re-read _fontdue_cc whenever the fontdue:consent event fires, so components that depend on consent re-render as soon as your handler runs.

Running analytics with no cookies at all

Some sites want Fontdue’s pageview numbers but no tracking cookie under any circumstances – and therefore no banner either, since there’s nothing left to ask permission for. The same cookie covers that case: keep consent required, write necessary on every page load, and never write analytics.

Turn on both Enable analytics tracking and Require cookie consent under Settings → Analytics, then write the baseline cookie in the same place as above, without the branch on a stored choice:

document.cookie =
  '_fontdue_cc=necessary;path=/;max-age=31536000;SameSite=Lax;Secure';

Leaving Require cookie consent on is what does the work – it’s the switch that holds Fontdue in cookieless mode, and the pre-written cookie only stops the banner from appearing.⁸⁸Turning Require cookie consent off would also remove the banner, but it tells Fontdue that tracking is allowed unconditionally, so _fontdue_state is set on the first pageview – the opposite of what this setup is for. Since your script rewrites the cookie on every load, its lifetime doesn’t matter here; dropping max-age to make it a session cookie works just as well.

Fontdue then behaves for every visitor exactly as it does for one who chose Necessary only:

• Pageviews are recorded and appear in website analytics, broken down by page and country as usual.
• The _fontdue_state cookie is never written. It’s the only cookie Fontdue’s analytics sets, so the _fontdue_cc cookie you write yourself – holding the string necessary and no identifier – is the only one left on the site.
• Nothing is forwarded to configured destinations. Facebook Conversions API, Google Ads conversions, Segment, and Mixpanel stay silent for pageviews and orders alike, and any consent-gated scripts never activate.⁹⁹Order and revenue figures still appear in Fontdue’s own reports – the consent gate governs what leaves the platform, not what Fontdue records for you.

The one number that changes meaning is Unique visitors. Without a stored identity, each full page load sends a freshly generated id that’s thrown away when the page unloads, so the count tracks page loads rather than people and can’t tell a returning visitor from a new one.¹⁰¹⁰Client-side route changes within a page load send no id at all, so a single-page-app visit counts once however many routes the visitor moves through. Read Pageviews as the reliable figure and treat Unique visitors as an upper bound on sessions.