A first-party data setup guide told as a timeline — DNS in minutes, SSL in under a minute, a ~400-day identity from the very first request, and what the dashboard shows at hour 1, hour 6, and hour 24.
Most analytics migrations are measured in sprints. A ClickStream install is measured in one working morning: paste a script tag, add a CNAME record, and watch the dashboard. This whitepaper is a first-party data setup guide structured as a timeline — what actually happens between minute zero and hour 24. We walk the only real wait in the process (DNS verification, where the dashboard polls every 10 seconds and most records resolve within the first few minutes; SSL provisioning, which typically completes in under 60 seconds), explain why the very first request already carries a server-set visitor cookie with a ~400-day lifetime, and then narrate the dashboard hour by hour: live sessions within seconds, the human/bot split taking shape across the first hours, and the first identity resolutions and stabilizing behavior scores by hour 24. It closes with a distilled go-live checklist and an honest account of what day one cannot tell you yet.
The gap between "installed analytics" and "trustworthy analytics" is usually weeks of configuration debt: filtering bots after the fact, patching identity after Safari expires your cookies, reconciling numbers nobody trusts. ClickStream front-loads the durable decisions — your own first-party tracking domain, server-set identity, per-event bot classification — into the install itself. The consequence is the subject of this paper: the data you collect in hour one is already the data you will still be using in year two.
We are not going to promise you an install time in minutes. Every DNS provider caches differently, every CMS has its own deploy pipeline, and every team has its own change window — a vendor who quotes you a universal number is quoting marketing, not operations. What we can describe precisely is the sequence: which steps are yours, which are automated, and which involve short waits on systems neither of us controls. For most teams, the whole sequence fits comfortably inside a working morning. Live before lunch is the honest framing.
Three things exist before minute zero, all covered in the install guide:
cs_live_… or cs_test_…) minted from the dashboard. It is pasted once into the tag; it is also domain-gated, so it is useless anywhere except the domains you configure.t.yourdomain.com or similar — which is what sections 2 and 3 set up.Everything after that is observation. The rest of this paper is the timeline.
The install itself is one script tag in your site's <head>:
Notice what the src is not: a shared vendor CDN. Every ClickStream tenant loads the SDK from its own registered subdomain — first-party delivery is the only supported mode, and it is the architectural decision the rest of this timeline depends on. The tag goes on every page; single-page apps need it once in the shell, because the SDK handles route changes internally.
Build-tool-managed apps can install the same pixel through the stable npm package, @clickstreamhq/sdk (1.4.0):
Tag managers and site builders work the same way — the tag is just HTML. If that is your stack, the platform walkthroughs cover Google Tag Manager, Webflow, Squarespace, and Wix specifically.
The one step that involves genuine waiting is pointing your tracking subdomain at ClickStream. It is a single CNAME record:
| Field | Value |
|---|---|
| Type | CNAME |
| Name | t (or analytics, data, tracking) |
| Target | feynman.clickstream.com (copy the dashboard value if it differs) |
| TTL | Auto (or 3600) |
| Proxy (Cloudflare only) | DNS-only — gray cloud, not orange |
After you register the hostname in the dashboard, the control plane polls DNS every 10 seconds for up to 5 minutes. In practice most CNAME records resolve within the first few minutes of that polling window, though a slow resolver can stretch propagation toward an hour — that variance belongs to your DNS provider, not to ClickStream. The moment the record resolves, the status flips to "CNAME verified" and SSL provisioning starts automatically via Cloudflare for SaaS. SSL typically completes within 60 seconds. When the hostname shows the green Active badge, the wait is over — permanently. You never touch DNS again unless you choose to rotate domains.
Verification is one command:
If verification stalls, the causes are boringly consistent: the Cloudflare proxy left on (turn the specific record to gray-cloud — Cloudflare for SaaS requires direct DNS resolution), a TTL that has not elapsed yet, or a typo in the target. The install guide covers each case.
Here is the part of the first 24 hours that most teams do not realize is happening — and the reason the first-party domain is mandatory rather than cosmetic.
When the first visitor's browser calls your tracking subdomain, the collector's HTTP response carries Set-Cookie headers: _cs_vid, the visitor identifier, with a Max-Age of 400 days (34,560,000 seconds), and _cs_sid, the session cookie, with a 24-hour lifetime. That distinction — server-set, on your domain — is doing quiet, compounding work. Safari's Intelligent Tracking Prevention caps cookies written by JavaScript at 7 days; cookies set by an HTTP response on a first-party domain persist at the browser's long-term maximum, roughly 400 days. A visitor who lands during your first hour and comes back next quarter is the same visitor, in Safari, without any workaround. (And no, it is not "two years" — no browser honors that anymore, and we are careful to claim only what browsers actually do. The full mechanics are in our post on first-party cookie persistence.)
The payload doing this work is deliberately small: a 344-byte loader that fetches the full tracking bundle — roughly 56.5 KB gzipped — from your own subdomain, asynchronously, without blocking render. The engineering behind that split is documented in The 344-Byte Pixel. The practical takeaway for day one: identity durability is decided at request one. It is not a setting you tune later; it is a property of how the install works.
With the hostname Active and the tag deployed, open the dashboard, pick your site, and load any page of your own site in an incognito tab. A session appears in the Live Sessions panel within 1–2 seconds. That is the whole verification: events are flowing from browser to your subdomain to the dashboard in real time.
Over the first hour, the analytics surfaces begin to populate:
The numbers will be small, and that is fine — hour one is for verification, not analysis. If nothing arrives within 30 seconds of a test pageload, the diagnosis path is short: open DevTools → Network, filter for your tracking domain, and look for 200 responses on /sdk.js and /v1/events. A 403 means the page's origin is not in your site's Allowed Domains (wildcards like *.example.com are supported) — which is the domain gate doing its job, just pointed at the wrong list.
Every event has been classified from the moment the tag went live — bot detection is not a nightly batch job. But a split needs volume to be readable, and by hour six most sites have enough traffic for the Traffic Quality page to say something meaningful: a human percentage, a bot breakdown across 11 bot categories, and named entries from the 158-bot registry — including 38 named AI agents — as they come through.
Two properties of this split matter on day one:
And because every classifier has a false-positive rate, disagreement has a mechanism rather than a support ticket: the mark-it-human override reclassifies any visitor from the dashboard, effective immediately.
By hour six your engagement and bounce rates are also starting to firm up — still noisy, but recognizably describing your site rather than a handful of test loads.
Somewhere in the first day, the People count — identity-resolved persons, bot-excluded — starts to diverge from the raw visitor count. Two forces drive it. The ~400-day cookie from section 4 means every returning browser is already recognized as the same visitor, no sign-in required. And every identify() call — a login, a signup, an email click-through — attaches a deterministic identifier: the SDK normalizes and SHA-256-hashes the email before it leaves the browser, and matching hashes merge into one person record. The merge rules are deterministic and auditable (email hash, phone hash, customer ID, social login), not probabilistic guesswork; the full architecture is in Inside the Identity Graph, and the compliant path from anonymous visitor to CRM contact is covered in its own guide.
On day one, expect single digits, not fireworks. Identity resolution compounds with authentication events, and a day-old install has seen very few. What matters at hour 24 is that the machinery is demonstrably working — you can watch an anonymous visitor become a person in the dashboard the first time they log in.
ClickStream's 26 behavioral models score every event as it arrives — the pipeline is held to a CI-enforced benchmark of p95 under 3 ms per event — so individual sessions have had live intent, frustration, and engagement scores since hour one. Intent alone is a 0–100 score built from four behavioral stages, and each session earns its scores from its own behavior in real time.
What changes at hour 24 is not the per-session scores but the distribution. One session with intent 74 is an anecdote; a day of sessions tells you what typical intent looks like on your pricing page versus your blog, where frustration clusters, which pages produce engaged reading versus bounces. Hour 24 also closes your first complete daily cycle — morning commute traffic, lunchtime browsing, evening research — which becomes the baseline every future day is compared against. The honest version of "scores stabilizing" is exactly that: the models were always running; by hour 24 there is enough of your traffic behind them to trust the shape.
Everything above happens in the dashboard, but the same scores are readable from page code through the Signals API (@clickstreamhq/signals, currently a 0.1.0-alpha developer preview — APIs may change before general availability):
Day one is a good time to wire this in precisely because the stakes are low: you can log decisions rather than act on them, watch how scores move against real sessions, and turn on actual personalization once you trust what you see. The full walkthrough is in Getting Started with the Signals API.
The whole timeline, distilled to the checks that matter. Each row is verifiable in the dashboard or a terminal — no step is "wait and hope."
| # | Step | Done When |
|---|---|---|
| 1 | Create the site and mint an API key in the dashboard | A cs_live_… key is visible for the site |
| 2 | Add the CNAME: t.yourdomain.com → feynman.clickstream.com | dig +short t.yourdomain.com returns the target; gray-cloud if on Cloudflare |
| 3 | Register the hostname in the dashboard | Status shows "CNAME verified" (polled every 10s, up to 5 min) |
| 4 | Wait for SSL provisioning | Green Active badge — typically under 60 seconds after verification |
| 5 | Deploy the tag on every page (or installClickstreamPixel in the app shell) | The script tag resolves from your subdomain in view-source |
| 6 | Verify events end to end | An incognito pageload appears in Live Sessions within 1–2 seconds |
| 7 | Confirm the domain gate | 200s on /sdk.js and /v1/events; no 403s (check Allowed Domains if so) |
| 8 | Optional: add Cloudflare edge capture | Crawlers and AI agents that never run JavaScript appear in Traffic Quality |
Step 8 deserves a note: search crawlers and answer engines mostly fetch raw HTML and never execute your pixel. The optional edge-capture Worker observes them at the HTTP layer on the same first-party domain, which is how AI answer-engine traffic becomes measurable at all.
A setup guide that only lists what you get is an advertisement. Here is what hour 24 does not give you:
@clickstreamhq/signals, /react, /next, /react-native — are 0.1.0-alpha developer previews. Only @clickstreamhq/sdk (1.4.0) is stable. The tag install in this paper rides entirely on the stable surface.The first 24 hours of first-party data compress a lot of infrastructure into a quiet morning: a script tag served from your own domain, a CNAME the dashboard verifies in minutes, an SSL certificate provisioned in under a minute, and a server-set visitor identity that will still be valid ~400 days from now — established on the very first request. From there the dashboard fills in on its own schedule: live sessions in seconds, a readable human/bot split within hours, the first identity resolutions and a trustworthy score distribution by the end of day one.
None of it required a data team, a consent-shredding workaround, or a migration project. That is the point of doing first-party data correctly at the install layer: the hard decisions are made once, at minute zero, and everything after is just watching the evidence accumulate.
One script from your own domain, DNS verified in minutes, SSL in under a minute — and a ~400-day first-party identity from the very first request.
Start free