Sites
A site is one domain under an application, with its own dashboard and traffic.
A site is one domain you monitor. It belongs to exactly one application, which owns the snippet, the hashes, and every tracker setting; the site is the pure analytics unit: its own dashboard, its own traffic, its own site_id.
Most applications have one site. Add more when several domains should share one snippet and one set of tracker settings; each domain stays a separate site with its own dashboard.
Why it matters
Everything beacon-related lives on the application: the script you embed, the two hashes, the tracker settings, the collector, and the unknown-domain policy. A site is where one domain's data lands.
To organize related properties, attach tags (below). A cross-site analytics scope that reports on every site carrying a tag together is planned; today tags are labels for grouping, not an analytics filter.
When you'd touch it
- Adding a domain. Create a site under the application, or adopt a suggested domain, then embed the application's snippet.
- Changing what the beacon collects. That's an application-level change: edit its tracker settings, or pick a preset.
- Other retention or visitor identifier for one domain. Move the domain into an application of its own.
data_retention_days,store_stitchandcount_visitors_byapply to every site of an application. - Pausing without deleting. Toggle
is_active = falseto keep history but stop ingesting new data. - Tagging to organize sites. Add tags like
env:productionorteam:growth.
What's on a site
A site is deliberately slim. The embed, the collection config and the privacy settings live on the application.
| Field | Type | Notes |
|---|---|---|
id | UUID v7 | Stable identifier (the analytics store's site_id). |
organization_id | UUID v7 | The owning organization. |
application_id | UUID v7 | The application this domain belongs to. |
name | string | How the site appears in the UI. |
domain | string | Bare hostname, no protocol (e.g. acme.com). |
tags | list of strings (max 10) | Free-form labels for organizing sites. Cross-site analytics-by-tag is planned, not yet live. |
is_active | bool | When false, beacons are accepted but not written to analytics tables. |
activated_at | timestamp · nullable | When the site first crossed the activation threshold and went live. |
The hashes, the preset and its switches, the privacy settings, the collector, site_policy, and the page-type ruleset are not here: they belong to the application. See Applications.
Tags
Tags are short labels you attach to a site to group related properties (a "production sites" or "marketing sites" grouping). A cross-site scope by tag is planned. For now, tags don't filter analytics.
Conventions that work well:
env:production,env:staging,env:previewteam:growth,team:productregion:eu,region:ustier:criticalfor sites you alert on aggressively
Max 10 tags per site.
Which domains may send data
Only registered domains send data. A beacon from any other host is handled by the application's site_policy: suggested as a domain (open, the default), added as a site (auto), or dropped (strict). This holds for an application with one site too, so a www. host or a separate checkout host needs a site of its own.
Common scenarios
Production + staging + preview
Two shapes that work:
- One application, one site per domain (
acme.com,staging.acme.com, and each preview domain). The same snippet everywhere; each domain gets its own dashboard. Mark a throwaway application'senvironmentasdevto keep it clearly apart from production. - Separate applications when staging genuinely needs different tracker settings, for example
Fullon staging andStandardin production.
Most teams start with one application and several sites.
Moving to a new domain
Add a site for the new domain under the same application, run both during the cutover, and mark the old one inactive once traffic's moved over.
Common surprises
- The snippet belongs to the application, not the site. Every site under an application embeds the same
source_hash; a beacon is matched to a site by the page's hostname. - Sites can't move between organizations. Ping support if you really need it. Moving a site to another application in the same organization is fine.
is_active = falsekeeps the history. It just stops new writes. Use it for pauses, not for cutting retention.- Deleting a site deletes its beacon data. With a confirmation step. No undo.
Related
- Applications: the embed that owns the snippet and the settings.
- Tracker settings: every setting, one by one.
- Presets: the three starting points.
- The RUM Beacon: what the beacon collects.
- Releases: versioned deploy markers.