Skip to main content
The tracking snippet records what happens after the redirect — page views on your landing and destination pages. You install it once, and the same snippet works across all domains and subdomains in your workspace.

Get your snippet

Go to Settings → Workspace, open the Tracking tab, and copy the snippet from the Tracking snippet card. It looks like this:
The data-site value is your workspace’s unique ID — always copy the snippet from the dashboard rather than retyping it. If you only need the bare ID (for a platform install recipe or a customer-operated Worker proxy, both below), grab it directly from the Site ID card under Settings & Integrations instead of extracting it from the full snippet.

Install it

Paste the snippet into the <head> of every page of your landing and destination sites. If your site uses a tag manager or a shared layout template, one paste covers everything.
On hosted pages (Mode D), the snippet is injected automatically — you only need to install it on your own sites.

What it tracks

  • Page views, including client-side navigation in single-page apps.
  • Clicks on links and buttons.
  • Form submissions — emails are hashed in the browser before being sent.

Options

Configure behavior with attributes on the script tag: If your audience requires consent (GDPR and similar), enable Require consent before tracking under Settings → Workspace → Settings & Integrations (Consent card) — it’s a single workspace-wide toggle, not set per domain. The snippet then stays completely silent — no events, no cookies — until a dava-consent=true cookie exists. The dashboard generates a ready-made consent banner you can customize and paste next to the snippet. Any third-party consent tool (CookieBot, OneTrust, …) works too, as long as it sets the dava-consent cookie and calls:

Verify the install

Open one of your pages in the browser, then check the dashboard — the visit should appear within seconds. If nothing shows up, add data-debug="true" to the script tag and check the browser console for errors.

Install method 2: Customer-operated Cloudflare Worker proxy

Deploy a Cloudflare Worker in your own account that proxies the tracking script and event endpoint through a dedicated subdomain (e.g. collect.yourdomain.com). This avoids the browser loading anything from cdn.davazmysel.com, without touching the DNS/proxy configuration of your main site at all — sometimes called a “first-party proxy” or “server-side install”.
Why a dedicated subdomain, not a path on your main domain. An earlier version of this guide recommended routing yourdomain.com/_dava/* through a Cloudflare Workers Route on your existing domain. In practice this breaks silently for any site fronted by another CDN/host in front of Cloudflare (Cloudflare nameservers assigned but the DNS record itself set to “DNS only”, with a different edge — e.g. WP Engine’s own Cloudflare-based edge — actually serving traffic). A brand-new subdomain bound via Cloudflare Custom Domain sidesteps this entirely: it does not depend on your root domain’s existing proxy status, and Cloudflare provisions the DNS record and SSL certificate for you.

Prerequisites

  • A Cloudflare account with owner or admin access (a zone for your domain must already exist in it — Custom Domains require the zone, even though you are only adding a new subdomain).
  • wrangler CLI installed (run npm install -g wrangler or pnpm add -g wrangler, then wrangler login).

Setup

1

Create a Worker project

In a new directory, scaffold a Worker:
When prompted, accept the defaults. This creates a wrangler.jsonc and a starter src/index.ts — replace both with the files below. (Do not also keep a wrangler.toml alongside wrangler.jsonc — Wrangler silently prefers one over the other if both exist, which is a confusing way to deploy the wrong file.)
2

Paste the template files

Copy the wrangler.jsonc and src/index.ts shown below into your project, replacing the generated files.In wrangler.jsonc’s vars, set DAVA_WORKER_URL to the Worker endpoint URL shown in your Dáva workspace under Settings → Workspace → Settings & Integrations. DAVA_SNIPPET_URL is the same public CDN URL as in the standard script tag — leave it as-is. In src/index.ts’s ALLOWED_ORIGINS, list every real origin your pages are served from (bare domain, www, and any other app subdomains that will load the script) — this is a genuine cross-origin call now, and only listed origins get a valid CORS response.
3

Deploy

4

Add a Custom Domain to the Worker

In the Cloudflare dashboard, go to your Worker (Workers & Pages → dava-proxy → Settings → Domains & Routes) and Add Custom Domain — enter your dedicated subdomain, e.g. collect.yourdomain.com. Cloudflare creates the DNS record and issues the SSL certificate automatically; no manual DNS step needed. If a stale DNS record already exists for that exact subdomain, delete it first or the Custom Domain add will fail with a conflict.
5

Update your script tag

Replace the standard Dáva snippet on every page with one that loads through your Worker proxy, using the full absolute URL of your dedicated subdomain — a relative path here silently resolves against your page’s own origin instead, which 404s:
The data-endpoint attribute is required, and its path must be exactly /_dava/events — the same value as EVENTS_PATH in the Worker above. There are two ways to get this wrong, and both silently lose every event:
  • Leaving it out. The snippet falls back to the page’s own origin plus its default /t/event path, which hits your origin server instead of your Worker.
  • Gluing that default path onto the proxy prefix — i.e. https://collect.yourdomain.com/_dava/t/event. The Worker does not handle that path, so the request falls through to the “pass everything else through to your origin” branch and dies there. Use /_dava/events, never /_dava/t/event.
Both mistakes look healthy at a glance: the preflight OPTIONS returns 204 (the Worker answers OPTIONS on every path), while the actual POST fails with net::ERR_FAILED. If you see that exact pair in DevTools, check the data-endpoint path before anything else.
wrangler.jsonc — deploy under any Worker name you like:
src/index.ts Requires "types": ["@cloudflare/workers-types"] in your tsconfig.json (added automatically by wrangler init).

Caveats and limits

Forward the real request’s headers — a proxy that drops them corrupts or silently loses data.Three separate, confirmed-in-production failure modes, all from the same root cause (a header the browser sent was not forwarded to Dáva):
  • Missing/wrong X-Forwarded-Host (only relevant for non-data_site installs) → 200 filtered: "no_hostname" or "unknown_domain", event discarded silently.
  • Missing User-Agent → the event is still accepted, but device_type/browser/os land as null/null/"desktop" regardless of the visitor’s real device — Dáva parses these from User-Agent on whatever request it receives, and without forwarding, that request is this Worker’s own fetch() call, not the browser’s.
  • Sending the visitor’s IP as CF-Connecting-IP instead of X-Forwarded-For → silently dropped. This Worker calling Dáva’s Worker is a cross-zone subrequest (different Cloudflare accounts) — Cloudflare unconditionally overwrites any CF-*-prefixed header on a cross-zone subrequest with its own internal value (anti-spoofing), so Dáva never sees what you set — client_ip_truncated lands null and geo (cf_country) falls back to wherever Cloudflare routed this Worker’s own connection to Dáva, not the visitor’s. Forward it as X-Forwarded-For instead (see the template above) — that header name has no such restriction and survives the hop.
To debug missing or malformed events, open your Worker’s real-time log in the Cloudflare dashboard (Workers & Pages → dava-proxy → Observability).
CORS must allow every real origin your pages load from. Because the Worker sits on a dedicated subdomain, the browser’s request to /_dava/events is cross-origin. If ALLOWED_ORIGINS doesn’t include the exact origin the page is served from (check www vs bare domain, and any other app subdomains), the browser blocks the response even though Dáva accepted the event server-side — the request still lands in Dáva (so DB inspection can mislead you into thinking it “worked”), but your own JS never sees a successful response. Check the browser console for Access-Control-Allow-Origin errors, not just the network tab’s status code.
Cloudflare Workers free-tier limit. The free plan allows 100,000 Worker invocations per day. A typical page view generates two invocations (one script load, one event POST), and a page with CTA or form tracking may generate three or more. A site with a few thousand daily visitors can exhaust the free quota within hours. Check your traffic before relying on the free tier; a paid Cloudflare Workers plan removes the daily cap.
Domain ownership. Cloudflare’s Custom Domain feature proves you control the zone your collector subdomain lives in — but that only covers the collector subdomain itself, not the domain your actual pages are served from. The ALLOWED_ORIGINS allowlist in the Worker is the real boundary here: only requests whose Origin header matches an entry you listed get a valid CORS response and get forwarded. Keep that list to origins you actually control.