What a Webflow Analytics Install Looks Like
Webflow gives every site a single place to inject markup into the <head> of every published page: Site settings → Custom code → Head code (older accounts may still see this labeled "Project settings"). ClickStream's entire browser install is one script tag, so that field is the whole integration surface. You don't add an embed element to each page, you don't touch the Designer, and there's no app to install.
The install has two halves, and it's worth being honest about which is which:
- The Webflow half — paste a snippet, save, publish. This is a few clicks.
- The DNS half — add a CNAME record and wait for verification and SSL. The dashboard automates the provisioning, but DNS propagation time is set by your DNS provider and the resolvers between you and it, not by us. Usually it's fast; occasionally it isn't.
The DNS half exists because every ClickStream tenant runs through its own first-party tracking domain — a subdomain like t.yourdomain.com that you control. That's not an optional optimization: the SDK bundle loads from your hostname, events post to your hostname, and the visitor cookie is a server-set first-party cookie that persists at the browser's long-term maximum (roughly 400 days) instead of being clamped the way JavaScript-set cookies are under Safari's ITP. The full reasoning is in our first-party cookie persistence deep-dive.
One Webflow-specific constraint to know up front: site-wide custom code requires a paid Webflow site plan. That's Webflow's gate, not ours — and since a paid site plan is also what lets you connect a custom domain, any Webflow site running on its own domain already clears it.
Before You Start
- A ClickStream account at einstein.clickstream.com with a site created as a Website property.
- Your API key (
cs_live_…orcs_test_…) from the dashboard. This key is designed to be publishable — it's gated to your domains, so pasting it into head code isn't a leak. Here's why a stolen analytics key is useless. - A Webflow site on a paid site plan, published to a custom domain, with access to Site settings.
- Access to your domain's DNS records — at your registrar, your DNS host (e.g. Cloudflare), or inside Webflow if you bought the domain through Webflow.
Step 1 — Add the First-Party CNAME
A common point of confusion: connecting a custom domain to Webflow does not move your DNS into Webflow. When you set up your domain, you added records at your DNS provider pointing your domain at Webflow's servers. Your ClickStream tracking CNAME goes into that same DNS zone, right next to those records. It's a new subdomain, so it can't collide with — or break — the records serving your Webflow site.
The one exception: if you purchased the domain through Webflow itself, you manage DNS records from Webflow's domain settings instead of a separate registrar. The record you add is identical either way:
| Field | Value |
|---|---|
| Type | CNAME |
| Name | t (or analytics, data, tracking — your choice) |
| Target | feynman.clickstream.com |
| TTL | Auto (or 3600) |
| Cloudflare proxy | DNS-only ("gray cloud", not "orange cloud") |
The dashboard shows the same target during provisioning — if the value it displays ever differs from this page, copy the dashboard's value.
Then register the hostname: in the dashboard, open Sites → your site → Tracking Domain and enter the subdomain you just created. The control plane polls DNS every 10 seconds for up to 5 minutes; when the CNAME resolves, SSL provisioning starts automatically and typically completes within 60 seconds. When the hostname shows the green Active badge, move on. (Events sent to a hostname that isn't registered and active are rejected — so this step genuinely gates the next one.)
Step 2 — Paste the Snippet into Webflow's Head Code
In Webflow, open Site settings → Custom code and paste this into the Head code field:
<script
src="https://t.example.com/sdk.js"
data-key="cs_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
async
></script>Replace t.example.com with the tracking domain you verified in Step 1, and the data-key value with your own API key. Click Save.
A few notes on what you just pasted:
- It's
async, and it's small. The loader is 344 bytes; it then pulls the full tracker (about 56.5 KB gzipped) from your own subdomain. Neither blocks Webflow's rendering or its interactions engine. The 344-byte pixel breaks down exactly what ships and why. - Site-wide head code covers every page — CMS collection pages, the 404, new pages you add later. There's nothing to maintain per page.
- It coexists with other tags. If you already have other analytics in your head code, you can run them side by side while you evaluate.
Step 3 — Publish
This is the step Webflow users most often skip: site-wide custom code only exists on the published site. You will not see the script in the Designer, and the Designer's preview mode won't run it. Click Publish and push to your custom domain.
Publishing also injects the snippet into your yoursite.webflow.io staging domain. That's expected — and it's a useful demonstration of the domain gate: the collector verifies each request's origin against the domains configured for your API key, so events from the webflow.io origin are rejected with a 403 unless you add that hostname to your site's Allowed Domains in the dashboard. Add it if you want staging traffic visible; leave it off if you'd rather staging stay dark. Either choice is fine — the 403s are the gate working, not an error in your install.
Step 4 — Verify the Install
- Open the dashboard, pick your site, and watch the Live Sessions panel.
- Load any page of your published Webflow site in an incognito tab. A session should appear within 1–2 seconds.
If nothing arrives after 30 seconds, work through these in order:
- Did you publish? Saved-but-unpublished head code is the single most common failure on Webflow. View source on the live site and confirm the script tag is present.
- Are you testing in the Designer? Custom code doesn't run in the Designer or its preview. Test the published URL.
- Check the network tab. In DevTools → Network, filter for your tracking domain. You want
200responses on/sdk.jsand/v1/events. A403means the page's origin isn't in your Allowed Domains (wildcards like*.example.comare supported) — this is what you'll see fromwebflow.iostaging if you didn't add it. - Check the key. Confirm
data-keymatches the key shown in the dashboard. - Check DNS. Run
dig +short t.yourdomain.comand confirm it resolves tofeynman.clickstream.com. On Cloudflare, make sure the tracking CNAME is gray-cloud (DNS-only) — the orange-cloud proxy breaks SSL provisioning for this record.
What Starts Flowing from a Webflow Site
Once verified, the SDK captures pageviews, clicks, form interactions (Webflow's native forms render as standard HTML forms, so they're covered), and sessions — with no per-page setup. Every event is scored by 26 behavioral models with a p95 latency under 3 ms per event, enforced as a CI benchmark rather than quoted from a lucky dashboard sample. That's where Signals like intent and frustration scores come from.
Two things matter specifically for Webflow marketing sites:
- Bot traffic is classified, not counted against you. Public marketing sites attract crawlers, scrapers, and AI agents. ClickStream classifies traffic across 11 bot categories — including 158 named bots and 38 AI agents — and billing counts human pageviews, not raw hits.
- Identity persists. Because the cookie is server-set and first-party on your own subdomain, returning visitors are recognized across the browser's long-term maximum (~400 days) — the foundation for knowing that Tuesday's anonymous reader is Friday's demo request.
Next Steps
With the pixel live, you can go beyond dashboards. The Signals API lets page code read the current visitor's scores — always configure({ apiKey }) first, then getVisitor() — and the effects engine turns those reads into one-line personalization rules. If your team also runs sites on other builders, the same first-party install pattern applies: see the companion guides for Google Tag Manager, Squarespace, and Wix.
The whole Webflow integration is one script tag in one settings field — the part worth doing carefully is the DNS, because that's what makes the data first-party and the identity durable.