---
title: "Webflow Analyze and Optimize"
description: "Match Webflow's built-in analytics and personalization to the analytics category."
url: "https://cookiebeam.com/docs/integrations/webflow"
lang: "en"
---

# 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](https://cookiebeam.com/docs/configure/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:

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

or, when analytics isn't granted:

```js
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:

```js
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:

```js
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:

```js
wf.getUserTrackingChoice()
```