Multi-site analytics
One dashboard. Every site you run. Not one mess.
Run several stores or domains? Multi-site website analytics keeps each in its own isolated project, visible from a single interface — with per-site funnels, reports, and switching built in.
The problem
The wall of separate dashboards
Running multiple sites usually means logging into multiple analytics accounts and dragging numbers into a spreadsheet yourself.
The moment you operate more than one site — a flagship store, a regional storefront, a blog, a test domain and an app — analytics multiplies into tabs. Every extra dashboard is a place where a metric goes stale and a decision gets made blind.
Aggregate, but don't merge
The correct pattern is isolation plus convenience: each site is a separate project with hard boundaries, while one interface switches between them and lets you compare. Merged data is a privacy violation waiting to happen; separated data under one roof is just good tooling.
Head to head
How multi-site analytics is handled
| Approach | Multi-site UX | Privacy |
|---|---|---|
| One script, all sites merged | Simple, but sites blend together | Cross-site mixing by default |
| Separate accounts per site | Logins and tabs everywhere | Isolated, but painful to operate |
| Multi-project workspace | One interface, per-site projects | Tenant-isolated per project |
How it works
The workflow
Sign in with a Tradly account, select the workspace returned by the tenant-access API, and the chosen tenant becomes the analytics project. Add another site as its own project and both live in the same workspace — funnels, acquisition, and reports per site, without data crossing between them. It's the multi-site convenience with the isolation your customers' data actually needs.
Multi-site, without the mess
Add every site you run. See it all from one interface — tenant-isolated, privacy-first.
Install the pixelRelated reading