Applications

Eine Application ist der Tracking-Embed. Sie bedient eine oder viele Domains, jede davon eine Site.

Die Hierarchie ist Organization → Application → Site:

• Eine Organization besitzt Applications, Members und Tokens.
• Eine Application besitzt das Snippet und die komplette Erfassungs-Config.
• Eine Site ist eine einzelne Domain unter der Application, mit eigenem Dashboard. Siehe Sites.

Die zwei Hashes

Eine Application hat zwei kurze Hashes:

• source_hash steht in der Script-URL (/s/{source_hash}.js) und wählt das Bundle, das an den Browser geht.
• collector_hash steht in der Ingest-URL (/c/{collector_hash}) und sagt, zu welcher Application ein Beacon gehört. Er ist im Script eingebacken.

Beide findest du auf der Karte der Application unter ··· → IDs & Hashes. Beim Rotieren werden beide neu erzeugt, das ausgelieferte Script wird invalidiert, und ein eingefügtes Shopify-Pixel geht kaputt.

Was erfasst wird: Presets

Die Erfassungs-Config lebt auf der Application: ein Preset (minimal / standard / full, Default standard), das sich in Einzelflags entfaltet, alle ins ausgelieferte Bundle gebacken.

Wohin die Beacons gehen: der Collector

collector_mode bestimmt den Host im Snippet:

• default: fastmons geteilter Collector (fastmon.site); aus Sicht deiner Seite Third-Party.
• relative: hostlose /s/- und /c/-Pfade, same-origin über deinen Reverse-Proxy ausgeliefert; First-Party.
• custom: ein absoluter collector_endpoint-Host, den du kontrollierst.

Er wird beim Anlegen gesetzt. Siehe Implementierung.

Unbekannte Domains: site_policy

Kommt ein Beacon von einem Hostnamen, der keine registrierte Site ist, entscheidet die site_policy:

• open (Default): der Beacon wird verworfen, der Hostname aber als vorgeschlagene Domain vermerkt, die du mit einem Klick adoptierst.
• auto: für den Hostnamen wird eine Site angelegt, ihr Traffic wird ab dann behalten.
• strict: der Beacon wird verworfen, ohne Vorschlag; nur registrierte Domains werden bedient.

Environment

environment markiert eine Application als prod oder dev (Default prod). Nutze dev, um Staging und Preview aus deinem Produktions-Traffic herauszuhalten.

Plattform, Shop und SPA

platform nennt das Shopsystem oder CMS, auf dem die Application läuft, etwa shopware6, shopify oder prestashop. Eine selbst gesetzte Plattform ist manual und wird von späterer Erkennung nicht überschrieben.

shop.active sagt, ob die Application ein Shop ist, dazu shop.source für die Herkunft. Ohne Einstellung folgt der Wert der Plattform; bei unbekannter Plattform bleibt er null. spa markiert eine Single-Page-App und wird von Hand gesetzt.

Eine Shopify-Application liefert zusätzlich das Checkout-Event-Pixel aus, gebaut aus source_hash und den Collector-Einstellungen.

Page-Type-Detection

platform sagt, worauf die Application läuft; page_type.body_class schaltet das Lesen des Page-Types (Home, Product, Cart, Checkout) aus der <body>-Klasse ein. Eine Plattform zu wählen schaltet das Lesen nicht ein, und für Shopify und PrestaShop bleibt es aus, weil es für sie kein Ruleset gibt.

Ein Theme, das eine dieser Klassen umbenannt hat, erfasst nichts. pagetype_rules benennt deine eigenen: bis zu 24 exakte Klassennamen, jeder auf einen Page-Type abgebildet. page_type.url_rules ordnet Seiten über die URL zu: bis zu 10 Muster in der Mustersyntax, jedes mit einem Page-Type, das erste passende gewinnt. Im Dashboard sind die Regeln nummeriert und lassen sich nach oben und unten schieben. Das hilft einem Headless-Shop, dessen Body-Klassen nichts verraten, oder einem Shop, der /:lang(de|en)/:slug{/}? von /:lang(de|en)/:cat/:slug{/}? unterscheiden muss.

Der Collector nimmt die erste Quelle, die einen Page-Type liefert:

1. Den Header Server-Timing: pageType.
2. Deine eigenen Body-Klassen, danach deine URL-Regeln.
3. Das Ruleset der Plattform, danach die Shopify-Routen oder den OXID-Controller cl.
4. Die Checkout-Stufe: cart auf einem Warenkorb-Pfad, checkout auf einem Checkout- oder Erfolgs-Pfad.

page-type-sources listet diese Quellen einer Application in genau dieser Reihenfolge. Zwei Endpunkte schlagen vor, was zu setzen ist, und schreiben nichts: detect-pagetype nennt das Shop-System, pagetype/discover findet die Klassennamen. Siehe Tracker → pagetype_rules.

Checkout-Funnel

Standardmäßig an, unter shop.checkout. Der Collector markiert jeden Pageview, dessen URL auf ein Warenkorb-, Checkout- oder Abschluss-Muster passt, und registriert die Warenkorb-Requests der Shopseiten aus Fetch/XHR. checkout_tracking ist das Opt-out; die drei Pfadlisten erben jeweils die eingebauten Muster (null) oder ersetzen sie komplett. Die Markierung wirkt nur vorwärts, und Besucher pro Stufe zu zählen braucht store_stitch. Siehe Checkout-Funnel.

Traffic-Sampling

collection.sampling_rate speichert nur einen Teil deiner Besucher statt aller. Der Default ist 1.0, eine Rate unter 0.1 lehnt die API ab. Die Edge behält oder verwirft die Pageviews eines Besuchers gemeinsam, und eine neue Rate greift nach etwa einer Minute.

Pageviews, Besucher und Fehlerzahlen werden hochgerechnet. Perzentile, Anteile, Mindeststichproben, der Beacon-Explorer und Histogramme rechnen mit den gespeicherten Zeilen. Gesampelt wird nur eine Application, die stitch speichert, und jede Analytics-Antwort nennt die Einstellung in meta.sampling.

Checkout-Schritte und Käufe sind bei jeder Rate exakt, weil sie Stage-Events zählen. Auch die Live-Ansicht zählt jeden Besucher. meta.sampling.estimated_metrics nennt die Felder einer Antwort, die hochgerechnet sind, und das Dashboard markiert sie mit ~.

PATCH /applications/{app_id}
{ "collection": { "sampling_rate": 0.5 } }

Im Dashboard heißt die Rate Erfasster Besucheranteil unter Besucher & Sampling.

Fetch- und XHR-Sampling

collection.fetch_xhr_sampling_rate behält die Fetch- und XHR-Aufrufe nur für einen Teil der gespeicherten Besucher. Der Rest des Pageviews wird vollständig gespeichert. Eine neue Application startet mit 0.25, und die Rate greift nie über sampling_rate hinaus.

Aufrufe und Fehler werden hochgerechnet. Perzentile und die gelisteten Aufrufe beruhen nur auf den behaltenen Aufrufen. Warenkorb-Interaktionen zählen mit der Pageview-Rate. Im Dashboard heißt das Feld Besucheranteil mit Fetch/XHR und erscheint, solange die Fetch/XHR-Erfassung an ist.

Empfohlene Rate

GET /applications/{app_id}/sampling-recommendation empfiehlt die Rate, die über die letzten sieben vollen Tage etwa 20.000 Pageviews am Tag behält. Sie rundet auf die nächsten 0.05 auf, geht nie unter 0.2 und antwortet bei weniger Traffic mit 1.0. inputs enthält pageviews_per_day und pageviews_per_month, und die Abfrage ändert nichts.

Das Dashboard zeigt die Empfehlung unter dem Feld. Übernehmen trägt sie ein, speichern musst du selbst.

Datenschutz-Einstellungen für alle Sites

site_defaults enthält drei Einstellungen, die für jede Site der Application gelten: data_retention_days (Default 90), store_stitch und count_visitors_by. Eine Site kann sie nicht überschreiben. Braucht eine Domain andere Werte, gehört sie in eine eigene Application.

Was eine Application hat

Die Response gruppiert ihre Felder in page_type, shop, collection, collector, script und site_defaults. Create und Update nehmen dieselben Gruppen als Teilobjekte und lehnen jeden unbekannten Key ab. Die flachen Zwillinge, die diese Gruppen ersetzt haben, antworten nicht mehr.

Sechs Felder bleiben für das Shopware-Plugin flach: source_hash, collector_hash, proxy_secret, collector_mode, collector_endpoint und pagetype_ruleset.

Sites: adoptieren, verschieben, löschen

• Domain hinzufügen: eine Site anlegen oder eine vorgeschlagene Domain adoptieren.
• Site verschieben: sie übernimmt die Config der neuen Application. Eine Domain gehört immer zu genau einer Application.
• Site löschen: entfernt die Daten dieser Domain, mit Bestätigung.

Verwandt

• Sites: die Per-Domain-Einheit.
• Presets: was der Beacon erfasst.
• Implementierung: eine anlegen und das Snippet einbetten.
• Der RUM-Beacon: was das ausgelieferte Script tut.