> ## Documentation Index > Fetch the complete documentation index at: https://docs.davazmysel.com/llms.txt > Use this file to discover all available pages before exploring further. # Install the tracking snippet > Add one script tag to your landing and destination pages to track visits across all your domains. 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: ```html theme={null} ``` 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 `` 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](/domains/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: | Attribute | Default | Effect | | ---------------------- | ------- | -------------------------------------------- | | `data-track-cta` | on | Track clicks on links and buttons | | `data-track-forms` | on | Track form submissions | | `data-require-consent` | off | Hold all tracking until the visitor consents | | `data-debug` | off | Log snippet activity to the browser console | ## Consent mode 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: ```js theme={null} window.dava.checkConsent() ``` ## 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](https://developers.cloudflare.com/workers/wrangler/install-and-update/) installed (run `npm install -g wrangler` or `pnpm add -g wrangler`, then `wrangler login`). ### Setup In a new directory, scaffold a Worker: ```bash theme={null} wrangler init dava-proxy cd dava-proxy ``` 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.) 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. ```bash theme={null} wrangler deploy ``` 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. 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: ```html theme={null} ``` 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: ```jsonc theme={null} { "name": "dava-proxy", "main": "src/index.ts", "compatibility_date": "2026-07-18", "vars": { // Paste the value from Dáva workspace settings → Settings & Integrations → Worker endpoint URL. "DAVA_WORKER_URL": "https://dava-worker.YOUR_CF_ACCOUNT.workers.dev", // Dáva's public snippet CDN — same URL as the standard script tag. "DAVA_SNIPPET_URL": "https://cdn.davazmysel.com/t.js" } } ``` **`src/index.ts`** Requires `"types": ["@cloudflare/workers-types"]` in your `tsconfig.json` (added automatically by `wrangler init`). ```ts theme={null} // Paths this Worker intercepts — change to whatever you prefer. // Use the same values in the snippet's src attribute and data-endpoint on your pages. const LISTEN_PATH = "/_dava/listen.js"; const EVENTS_PATH = "/_dava/events"; // This Worker is bound to a DEDICATED subdomain (Cloudflare Custom Domain), not // your main site — so requests from the real page arrive cross-origin. List every // real origin your pages are served from. const ALLOWED_ORIGINS = new Set([ "https://yourdomain.com", "https://www.yourdomain.com", ]); export interface Env { /** Dáva event Worker endpoint — copy from workspace settings → Settings & Integrations. */ DAVA_WORKER_URL: string; /** Dáva snippet CDN. Default: https://cdn.davazmysel.com/t.js */ DAVA_SNIPPET_URL: string; } export default { async fetch(request: Request, env: Env): Promise { const url = new URL(request.url); const origin = request.headers.get("Origin"); if (request.method === "OPTIONS") { return new Response(null, { status: 204, headers: corsHeaders(origin) }); } if (url.pathname === LISTEN_PATH) { return proxySnippet(env); } if (url.pathname === EVENTS_PATH && request.method === "POST") { // The real page hostname (e.g. yourdomain.com) is NOT url.hostname here — // this Worker sits on its own dedicated subdomain. Derive it from Origin // instead. Not required for account-wide-pixel installs (data_site in the // payload bypasses this entirely), kept for defense-in-depth. const pageHostname = origin ? new URL(origin).hostname : url.hostname; return proxyEvent(request, env, pageHostname, origin); } // All other paths pass through to your origin unchanged. return fetch(request); }, } satisfies ExportedHandler; function corsHeaders(origin: string | null): HeadersInit { if (!origin || !ALLOWED_ORIGINS.has(origin)) return {}; return { "Access-Control-Allow-Origin": origin, // Required: the snippet's sendBeacon fallback (clicks, form_submits, and the // fetch-failure retry) is ALWAYS credentialed, so the browser demands // Allow-Credentials: true on both the preflight and the response — omit it and // every beacon-delivered event is silently dropped by CORS. Safe with a // specific (non-"*") Allow-Origin, which is exactly what we echo above. "Access-Control-Allow-Credentials": "true", "Access-Control-Allow-Methods": "POST, OPTIONS", "Access-Control-Allow-Headers": "Content-Type", "Access-Control-Max-Age": "86400", Vary: "Origin", }; } /** 1:1 passthrough of the Dáva snippet from the CDN. No CORS needed —