Sites
Eine Site ist eine Domain unter einer Application, mit eigenem Dashboard und eigenem Traffic.
Eine Site ist eine Domain, die du überwachst. Sie gehört zu genau einer Application, der das Snippet, die Hashes und alle Tracker-Einstellungen gehören; die Site ist die reine Analytics-Einheit: eigenes Dashboard, eigener Traffic, eigene site_id.
Die meisten Applications haben eine Site. Weitere kommen dazu, wenn sich mehrere Domains ein Snippet und einen Satz Tracker-Einstellungen teilen sollen; jede Domain bleibt eine eigene Site mit eigenem Dashboard.
Warum das zählt
Alles Beacon-Bezogene liegt an der Application: das Script, die zwei Hashes, die Tracker-Einstellungen, der Collector und die Policy für unbekannte Domains. Eine Site ist der Ort, an dem die Daten einer Domain landen.
Zum Gruppieren verwandter Properties hängst du Tags an (siehe unten). Ein Cross-Site-Analytics-Scope, der alle Sites mit einem Tag gemeinsam auswertet, ist geplant; heute sind Tags Labels zum Gruppieren, kein Analytics-Filter.
Wann du sie anfasst
- Domain hinzufügen. Eine Site unter der Application anlegen oder eine vorgeschlagene Domain adoptieren, dann das Snippet der Application einbetten.
- Beacon-Erfassung anpassen. Das ist eine Änderung an der Application: ihre Tracker-Einstellungen bearbeiten oder ein Preset wählen.
- Andere Retention oder anderer Besucher-Identifier für eine Domain. Leg die Domain in eine eigene Application.
data_retention_days,store_stitchundcount_visitors_bygelten für alle Sites einer Application. - Ohne Löschen pausieren.
is_active = falsebehält Historie, stoppt neuen Ingest. - Zum Organisieren taggen. Tags wie
env:productionoderteam:growth.
Was eine Site hat
Eine Site ist bewusst schlank. Embed, Erfassungs-Config und Datenschutz-Einstellungen liegen an der Application.
| Feld | Typ | Hinweise |
|---|---|---|
id | UUID v7 | Stabiler Identifier (die site_id im Analytics-Store). |
organization_id | UUID v7 | Die besitzende Organisation. |
application_id | UUID v7 | Die Application, zu der diese Domain gehört. |
name | string | Wie die Site im UI erscheint. |
domain | string | Reiner Hostname, kein Protokoll (z. B. acme.com). |
tags | Liste von Strings (max 10) | Freie Labels zum Organisieren von Sites. Cross-Site-Analytics per Tag ist geplant, noch nicht live. |
is_active | bool | Bei false nimmt der Collector Beacons noch an, schreibt sie aber nicht in Analytics-Tabellen. |
activated_at | timestamp · nullable | Wann die Site erstmals die Aktivierungsschwelle überschritt und live ging. |
Die Hashes, das Preset und seine Schalter, die Datenschutz-Einstellungen, der Collector, site_policy und das Page-Type-Ruleset stehen nicht hier: Sie gehören zur Application. Siehe Applications.
Tags
Tags sind kurze Labels, die du an eine Site klebst, um verwandte Properties zu gruppieren (eine „Production-Sites"- oder „Marketing-Sites"-Gruppierung). Der Tag-Filter pro Site in der Sidebar wurde entfernt; ein echter Cross-Site-Analytics-Scope, der alle Sites mit einem Tag gemeinsam auswertet, ist geplant. Vorerst sind Tags Labels und filtern Analytics nicht.
Konventionen, die gut funktionieren:
env:production,env:staging,env:previewteam:growth,team:productregion:eu,region:ustier:criticalfür Sites, für die du aggressive Alarme einrichtest
Max 10 Tags pro Site.
Welche Domains senden dürfen
Die frühere Per-Site-Allow-List allowed_origins und der Schalter enforce_domain_match sind weg. Der Ingest wird über die site_policy der Application gesteuert: strict akzeptiert nur exakt registrierte Domains, open (der Default) vermerkt einen unbekannten Hostnamen als vorgeschlagene Domain, die du adoptieren kannst, und auto legt ihn automatisch als Site an. Gesetzt wird das an der Application.
Häufige Szenarien
Production + Staging + Preview
Zwei Wege, beide tragen:
- Eine Application, eine Site pro Domain (
acme.com,staging.acme.comund jede Preview-Domain). Überall dasselbe Snippet; jede Domain bekommt ihr eigenes Dashboard. Markiere dieenvironmenteiner Wegwerf-Application alsdev, um sie klar von Production zu trennen. - Getrennte Applications, wenn Staging wirklich andere Tracker-Einstellungen braucht, etwa
Fullauf Staging undStandardin Production.
Die meisten Teams starten mit einer Application und mehreren Sites.
Auf eine neue Domain umziehen
Eine Site für die neue Domain unter derselben Application anlegen, beide während des Cutovers laufen lassen und die alte auf inactive setzen, sobald der Traffic umgezogen ist.
Häufige Überraschungen
- Das Snippet gehört zur Application, nicht zur Site. Jede Site unter einer Application bettet denselben
source_hashein; ein Beacon wird über den Hostnamen der Seite einer Site zugeordnet. - Sites lassen sich nicht zwischen Organisationen umziehen. Falls doch nötig: Support melden. Eine Site in derselben Organisation zu einer anderen Application zu verschieben, geht.
is_active = falsebehält die Historie. Es stoppt nur neue Schreibvorgänge; gut für Pausen, nicht zum Retention-Kürzen.- Site löschen löscht auch die Beacon-Daten. Mit Bestätigung. Kein Undo.
Verwandt
- Applications: der Embed, dem Snippet und Einstellungen gehören.
- Tracker-Einstellungen: jede Einstellung, einzeln.
- Presets: die drei Ausgangspunkte.
- Der RUM-Beacon: was der Beacon erfasst.
- Releases: versionierte Deploy-Marker.