Applications

Eine Application ist der Tracking-Embed: Ihr gehören das Snippet und die komplette Erfassungs-Config. Sie bedient eine oder mehrere Domains, jede davon eine Site mit eigenem Dashboard.

Die zwei HashesCopy Anchor Link

Beide Hashes findest du auf der Karte der Application unter ··· → IDs & Hashes.

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

Rotieren erzeugt beide neu, invalidiert das ausgelieferte Script und macht ein eingefügtes Shopify-Pixel kaputt.

Was erfasst wird: PresetsCopy Anchor Link

Ein Preset (minimal / standard / full, Default standard) setzt die einzelnen Flags, die ins ausgelieferte Bundle gebacken werden.

Wohin die Beacons gehen: der CollectorCopy Anchor Link

collector_mode bestimmt den Host im Snippet:

• default: fastmons geteilter Collector (fastmon.site), Third-Party.
• relative: hostlose /s/- und /c/-Pfade über deinen Reverse-Proxy, First-Party.
• custom: ein collector_endpoint-Host, den du kontrollierst.

Er wird beim Anlegen gesetzt. Siehe Implementierung.

Unbekannte Domains: site_policyCopy Anchor Link

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

• open (Default, „Vorschlagen“): Der Beacon wird verworfen, der Hostname landet als vorgeschlagene Domain in der Liste. Du übernimmst sie mit einem Klick.
• auto: Für den Hostnamen wird eine Site angelegt, ihr Traffic bleibt.
• strict: Der Beacon wird ohne Vorschlag verworfen.

Das gilt auch für eine Application mit nur einer Site. Ein www.-Host neben der Apex-Domain oder ein eigener Checkout-Host braucht eine eigene Site.

EnvironmentCopy Anchor Link

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

Plattform, Shop und SPACopy Anchor Link

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 setzt du von Hand.

Eine Shopify-Application liefert zusätzlich das Checkout-Event-Pixel aus.

Page-Type-DetectionCopy Anchor Link

page_type.body_class liest den Page-Type (Home, Product, Cart, Checkout) mit dem Ruleset der Plattform aus der <body>-Klasse. Die Plattform allein schaltet das nicht ein, und Shopify und PrestaShop haben kein Ruleset.

• pagetype_rules: bis zu 24 Klassennamen deines eigenen Themes, jeder auf einen Page-Type abgebildet.
• page_type.url_rules: bis zu 10 URL-Muster in der Mustersyntax, das erste passende gewinnt.
• Meta-Tag: <meta name="fm-page-type" content="product"> oder page-type. Soft-Pageviews lesen es, sobald deine App es neu setzt.

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

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

page-type-sources listet diese Quellen in genau dieser Reihenfolge. detect-pagetype nennt das Shop-System, pagetype/discover schlägt Klassennamen vor. Beide schreiben nichts. Siehe Tracker → pagetype_rules.

Checkout-FunnelCopy Anchor Link

Standardmäßig an, unter shop.checkout. Der Collector markiert jeden Pageview, dessen URL auf ein Warenkorb-, Checkout- oder Abschluss-Muster passt, und erfasst Warenkorb-Requests aus Fetch/XHR. Die drei Pfadlisten erben die eingebauten Muster (null) oder ersetzen sie. Die Markierung wirkt nur vorwärts, und Besucher pro Stufe brauchen store_stitch. Siehe Checkout-Funnel.

Traffic-SamplingCopy Anchor Link

collection.sampling_rate speichert nur einen Teil deiner Besucher statt aller. Der Default ist 1.0, eine Rate unter 0.01 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.

Automatisches SamplingCopy Anchor Link

collection.sampling_mode legt fest, wer die Rate setzt: du (manual, der Default) oder fastmon anhand deiner gebuchten Pageviews (automatic). Im Dashboard ist das Anteil automatisch festlegen unter Besucher & Sampling.

• Stufen: eine feste Leiter von 100 % bis 1 %, höchstens eine Stufe pro Tag.
• Geltung: Produktions-Applications einer Organisation mit festem Pageview-Kontingent. Free, Enterprise, Partner-Tarife, voll abgedeckte Kunden und Trials bleiben unberührt.
• Kontingent: Manuelle Applications bekommen ihren Teil zuerst, die automatischen teilen sich den Rest nach Traffic.
• Rate schreiben: Im Modus automatic gibt eine geänderte sampling_rate 422 zurück, außer derselbe Body setzt sampling_mode auf manual.
• Änderungen: sampling_rate_changed_at und der Audit-Log-Eintrag application.sampling_rate_changed halten jeden Schritt fest. Zurück auf manual bleibt die letzte Stufe.

Fetch- und XHR-SamplingCopy Anchor Link

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.

Empfohlene RateCopy Anchor Link

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 ändert nichts. Das Dashboard zeigt sie unter dem Feld, Übernehmen trägt sie ein.

EventsCopy Anchor Link

Die dataLayer-Einstellungen findest du unter Events aus dem dataLayer im Tab Shop. Siehe Eigene Events → dataLayer.

Datenschutz-Einstellungen für alle SitesCopy Anchor Link

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 hatCopy Anchor Link

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.

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