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.