Webflow Analyze and Optimize

Match Webflow's built-in analytics and personalization to the analytics category.

Webflow Analyze and Optimize aren't script tags you can tag and block. They're built into the Webflow platform and they run as part of the page, so adding data-category="analytics" to something doesn't reach them. They do expose a tracking consent API, which is what CookieBeam uses.

This makes Webflow a consent bridge in the same sense as Meta or Shopify. We speak Webflow's API and Webflow decides what to stop doing.

Consent category. analytics.

What happens per regime

The bridge gates on the resolved analytics_storage value, which is the regime engine's answer rather than a raw category. That single check gives you the right behaviour in both places:

Under a European opt-in preset, analytics_storage starts denied, so Webflow tracking stays off until the visitor accepts analytics.
Under a US opt-out preset, analytics_storage starts granted, because US opt-out laws scope sale and sharing rather than analytics. Webflow tracking runs unless the visitor opts out.

If you'd rather treat US analytics as opt-in too, set that through regional rules. The bridge picks it up with no extra configuration, because it reads the resolved value rather than deciding regional policy itself.

How it works

Webflow stamps data-wf-intellimize-customer-id on the <html> element of a site that has Analyze or Optimize enabled. The bridge reads it and exits immediately if it isn't there, so a site without these products pays nothing.

The visitor's decision is stored by Webflow in localStorage, under a key built from that site ID. Optimize reads it as its bundle starts, which can happen before consent resolves, so the bridge writes deny synchronously at load whenever the key holds neither allow nor deny. An unasked visitor is a denied visitor, and that pre-seed is what makes it true in the window before anything else has run.

An existing allow isn't downgraded by the pre-seed. It's a real choice, and if consent contradicts it the next step corrects it in the same tick.

Then the decision is applied through Webflow's API:

wf.ready(function () {
  wf.allowUserTracking({ activate: true });
});

or, when analytics isn't granted:

wf.ready(function () {
  wf.denyUserTracking();
});

The bridge applies once at load from the stored consent record and again on every consent update. The load-time read matters for returning visitors: a page view with valid stored consent can resolve without firing a consent event, so without it, someone who accepted analytics yesterday would sit at the deny pre-seed today.

Repeated identical decisions are skipped, so Webflow isn't called again for a state it's already in.

Setup

On by default. Toggle it under Vendor Consent Signals on the banner's App Integrations page, then publish.

Nothing else is needed. You don't supply the site ID, because it's already on the page.

Scanner coverage

The scanner recognises the Webflow Optimize engine and files it under analytics, separately from Webflow's site asset hosts, which stay necessary. A site can serve Optimize from the same asset host as its CSS and images, so the match is on the engine name in the URL rather than the host alone.

Testing

Confirm the site ID is present:

var siteId = document.documentElement.getAttribute('data-wf-intellimize-customer-id');
siteId;

If that's null, Analyze and Optimize aren't enabled on the site and there's nothing for the bridge to do.

Then watch the stored decision as you change consent:

localStorage.getItem('intellimize_user_tracking_choice_' + siteId)

It should read deny for a fresh European visitor, flip to allow when they accept analytics, and go back to deny if they withdraw. You can also read Webflow's own view of it:

wf.getUserTrackingChoice()