Docs
Everything you need to install Embaze, read what it tells you, and get more out of it — start to finish, no account required to read this page.
Quickstart
Three steps, same as the setup wizard you'll see right after signing up:
- Create an account and add your website's domain.
- Paste your personal script tag into your site's global <head>, and deploy.
- Open your site once — your dashboard picks up the first pageview on its own.
Your script tag is personal to your site and only shows up once you've added a website — it's on your Settings page, ready to copy, the whole time.
Installing the script
The tag itself is the same everywhere; where it goes depends on how your site is built. It only needs to load once, on every page — it doesn't need to be inside a specific component or re-added per route.
Plain HTML
Paste it directly into the <head> of your HTML, in any template that's shared across every page:
<script defer src="https://embaze.com/api/public/embaze?site=YOUR_SITE_KEY"></script>Next.js / React
Add it to your root layout so it loads on every route, not a specific page:
// app/layout.tsx
export default function RootLayout({ children }) {
return (
<html>
<head>
<script defer src="https://embaze.com/api/public/embaze?site=YOUR_SITE_KEY" />
</head>
<body>{children}</body>
</html>
);
}WordPress
Most themes have a "header" or "insert code in <head>" field under Appearance → Theme File Editor or a plugin like Insert Headers and Footers — paste the same script tag there. Editing header.php directly works too, if your theme supports it.
Squarespace, Webflow, Wix, or any site builder
Look for a setting called "Header code injection," "Custom code," or "Tracking & Analytics" in your site settings — every major builder has one, and the same script tag goes there unchanged.
Verifying it's working
Open your site once after deploying — your dashboard checks for that first pageview on its own every few seconds while you're on the setup screen, and again the moment you switch back to that tab. No pageview after a minute or two usually means the tag didn't make it into the deployed version of your site, not that something's broken on Embaze's end — check that it's actually live by viewing your site's page source and searching for embaze.
Understanding your dashboard
Pageviews vs. visitors
A pageview is counted every time any page loads, including refreshes and repeat visits. A visitor is one person, counted once — so 50 pageviews from 12 visitors means a smaller group is browsing several pages each, not 50 different people each loading one page.
Bounce rate
The share of visits where someone landed on one page and left without visiting a second one or triggering an event. What counts as a "good" bounce rate depends entirely on the page — high bounce on a blog post that fully answered someone's question is often fine; high bounce on a signup page usually isn't.
Avg. visit time
The average time between a visitor's first and last recorded activity in a session. A single-pageview visit with no further activity can't have a measured duration, so it isn't counted toward this average — meaning it reflects engaged visits specifically, not literally everyone who showed up.
Real-time updates
The dashboard is genuinely live — it's subscribed to new events as they happen, not polling on a timer, so a new pageview appears while you're looking at the screen, with no refresh needed.
Custom events
Pageviews are automatic. Events are actions worth tracking on purpose — a signup, a button click, a completed purchase — and they only appear once your own code calls a function, anywhere on the page, any time after the tracking script has loaded:
embaze("signup")
embaze("purchase", { plan: "pro" })The first argument is the event's name — anything you want to call it. The second is optional, for extra detail worth knowing later, like which plan or which button. Events show up on their own tab in your dashboard, ranked by count, the same way pages and referrers are.
Importing historical data
Switching from another analytics tool doesn't have to mean starting your history over at zero. From Settings, you can upload a CSV of past pageviews and events — only created_at is required, everything else is optional and filled in with whatever your old tool actually exported:
created_at,kind,name,path,referrer,country,browser,os,device,screen,visitor_id,session_idMost tools don't export in exactly this shape — Settings has a ready-made prompt you can hand to a coding agent along with your old export, and it'll reshape the file into one you can upload directly. Worth knowing: without visitor_id in the source export, imported rows can't be grouped back into the same real visitor, so "unique visitors" for imported history is an honest approximation, not an exact figure — pageviews and events themselves import exactly. Use your old tool's actual dashboard export or API, not a raw internal database table if that's ever what you're offered instead — a raw table (Umami's own "website_event" table, for example) usually doesn't match what the old tool's dashboard actually showed, and its real per-visitor identity often lives in a separate table entirely.
How tracking works without cookies
Embaze never writes a cookie or any persistent ID to a visitor's browser. Instead, each pageview is identified with a one-way hash built from a server-side salt, the visitor's IP address, their user agent, and the current date — nothing stored client-side at all. Because the date is baked into the hash, the same real person gets a different hash the next calendar day, which is exactly why there's nothing to track someone with across days, and exactly why no cookie banner is needed.
The real cost of that tradeoff: "unique visitors" over a multi-day range trends slightly high, since a returning visitor a day later counts as a new one. Day-level counts are exact. It's the same tradeoff every cookie-free analytics tool makes — worth reading the full mechanics if you want the details.
FAQ
Do I need a cookie consent banner?
Not because of Embaze — it sets no cookies and stores no persistent identifier, so it doesn't trigger the consent requirement cookie-based analytics does. Your own site may still need one for unrelated reasons (ads, other embedded tools); that's outside what Embaze controls.
Does an ad blocker stop it from working?
Some can — ad blockers that maintain lists of known analytics domains will eventually catch any hosted tracking script, cookie-free or not. What Embaze avoids specifically is the consent-banner gate, since there's no persistent identifier requiring one — that's a real difference, not a claim of being unblockable.
How many websites can I add?
One per account on the current free plan. Support for multiple sites is planned for a future paid plan.
Can I get my data out?
Yes — Settings has a CSV export of every event for your site (the most recent 5,000), any time, no plan restriction.
What if a visitor has JavaScript disabled?
No pageview is recorded — the same limitation every JavaScript-based analytics tool has, cookie-free or not. There's no separate no-JS fallback.