So funktioniert es
Von deiner Domain zu verifizierten Conversions auf jeder Plattform
Ein Snippet auf deiner Site, eine geführte Sitzung mit dem Assistenten, eine signierte Konfiguration, die du freigibst. Ab da übernimmt Track die Events — mit Consent-Prüfung für jede Destination und einem Debugger, der dir zeigt, was passiert ist.
Vier Meilensteine, eine Sitzung
Das ist die Sicht des Kunden. Die technischen Prüfungen hinter jedem Meilenstein stehen weiter unten.
Site anlegen
Registriere dich mit deiner Domain. Track legt die Site, eine öffentliche sechsstellige Tracking-ID und das einzeilige Snippet an.
- Du
- Domain eingeben und Snippet einfügen — oder die Shopify-, WooCommerce- oder Shopware-App installieren
- Du bekommst
- eine verifizierte Installation: Track sieht den ersten Seitenaufruf und bestätigt die Inhaberschaft per DNS, Datei oder Meta-Tag
Das Snippethtml<script async src="https://cdn.track.site/v1/tracker.js" data-site-id="TRACKING_ID"></script>Von einem First-Party-CDN-Host ausgeliefert; die geladene Konfiguration ist Ed25519-signiert und wird geprüft, bevor irgendetwas läuft.
Den Assistenten die Einrichtung vorschlagen lassen
Der Assistent erkennt Plattform und Consent-Tool, schlägt einen Eventplan für deinen Geschäftstyp vor und fragt nach den öffentlichen IDs der Plattformen, die du nutzt.
- Du
- ein paar Fragen beantworten, Pixel-IDs im Chat und Access-Tokens in der Tresor-Karte eingeben
- Du bekommst
- eine entworfene Konfiguration mit gemappten Events und einen echten, vom Anbieter akzeptierten Testevent
Geführte Einrichtung
Beispieldaten: Statischer Beispielzustand — kein Live-Traffic, keine echten Kundendaten.Track AI
example-shop.test läuft auf Shopify mit Cookiebot als Consent-Tool (hohe Konfidenz). Für einen Shop schlage ich view_item, add_to_cart, begin_checkout und purchase vor. Soll ich den Plan für Meta und Google Ads entwerfen?
Du
Ja, Meta zuerst.
Track AI
Pixel-ID geprüft. Die Conversions API braucht einen Access-Token — bitte in der Tresor-Karte unten eingeben; er erscheint nie in diesem Chat.
Tresor-Karte · Meta-Access-Token
Verschlüsselt gespeichert; für niemanden sichtbar, auch nicht für das Modell.
gespeichertTestevent · purchase
Durch die echte Pipeline gesendet, mit dem Test-Event-Code des Anbieters.
von Meta akzeptiertwartet auf deine FreigabeVersion 13 veröffentlichen
Gebunden an genau dieses Diff und an dich als freigebende Person.
- + destination meta: browser + server
- + mapping purchase → Purchase (event id, order id)
- ~ consent: marketing required for meta
Freigeben und veröffentlichenDer Assistent schlägt vor, Tools validieren, du gibst frei.
Freigeben und veröffentlichen
Du siehst das Diff, die Empfänger und die Consent-Anforderung jeder Destination. Eine Freigabe veröffentlicht ein signiertes, versioniertes Bundle.
- Du
- das Diff lesen und auf Freigeben klicken
- Du bekommst
- eine live geschaltete Konfiguration mit Versionsnummer, Rollback per Klick
Konfiguration · Version 13
Beispieldaten: Statischer Beispielzustand — kein Live-Traffic, keine echten Kundendaten.live- Freigegeben von
- dir, gebunden an das gelesene Diff
- Signatur
- Ed25519, vom SDK geprüft
- Destinationen
- Meta (Browser + Server), Google Ads (Server)
- Rollback
- Version 12, ein Klick
Beobachten und verbessern
Der Debugger zeigt jedes Event mit seiner Entscheidung, der Health-Score meldet, was zu tun ist, und der Assistent schlägt die Lösung vor.
- Du
- den Score prüfen, wenn er sich ändert; Verbesserungen freigeben
- Du bekommst
- verifizierte Conversions auf jeder Plattform, mit Nachweis pro Event
Tracking-Zustand
Beispieldaten: Statischer Beispielzustand — kein Live-Traffic, keine echten Kundendaten.Score
86 / 100
Komponenten
- Consent-Abdeckung91 · 20 % Gewicht
91 % der Events tragen ein explizites Consent-Signal
- Kritische Events78 · 25 % Gewicht
7 von 9 geplanten kritischen Events gesehen
- Schemaqualität74 · 15 % Gewicht
74 % der Events bestehen Schema- und PII-Prüfungen
- Duplikate96 · 10 % Gewicht
1,0 % Duplikate
- Zustellung88 · 20 % Gewicht
94 % zugestellt, 1 Integration mit Credential-Problemen
- Aktualität100 · 10 % Gewicht
Letztes Browser-Event vor 4 Minuten
Offene Probleme
- purchase ohne currencyLösung: Event-Mapping aktualisieren
12 Events in den letzten 24 h fehlt der Pflichtparameter
- Consent-Signal fehltLösung: CMP-Adapter verbinden
9 % der Events kamen ohne expliziten Consent-Zustand an
Gewichtete Komponenten; ein niedrigerer Score zeigt immer auf seine Ursache.
Woher deine Events kommen
Wechsle zwischen den Zustellmodi. Jede Destination kann nur per Browser, nur per Server oder mit beidem laufen; der hybride Modus ist der Standard, weil die beiden Wege die Lücken des jeweils anderen abdecken.
Events aus dem Browser-SDK
Das Snippet erfasst Seitenaufrufe, Produktansichten und Warenkorb-Events im Browser des Besuchers und sendet sie an den Ingest-Host von Track. Anbieter-Tags laden erst nach Consent. Dieser Modus ist schnell installiert, hängt aber vom Browser ab: blockierte Skripte und geschlossene Tabs verlieren Events.
- Installation: ein Snippet
- Consent: im Browser geprüft und erneut auf dem Server
- Lücke: kein Event, wenn das Skript blockiert wird oder der Tab zu früh schließt
Events von deinem Server oder Shop
Dein Shopsystem, Backend oder CRM sendet Conversions mit einem Source-Key an die Server-API. Käufe, Erstattungen und Offline-Conversions kommen zuverlässig an und werden im Browser nie blockiert. Matching-Daten sind auf das beschränkt, was dein Server weiß.
- Installation: Shop-App oder eine signierte Anfrage aus deinem Backend
- Zuverlässig für Käufe, Erstattungen, Leads aus deinem CRM
- Lücke: weniger Browser-Signale fürs Matching
Beide Wege, eine Event-ID
Browser und Server senden dieselbe Conversion mit derselben Event-ID. Track normalisiert beide, wendet die Consent-Entscheidung pro Destination an und leitet weiter; die Anbieter deduplizieren über Event-ID oder Bestellnummer. Du bekommst die Reichweite des Server-Wegs mit der Matching-Qualität des Browser-Wegs.
- Standardmodus für jede Destination, die beides unterstützt
- Deduplizierung: Event-ID (Meta, TikTok, Pinterest, Snapchat, Microsoft, LinkedIn …), Bestellnummer (Google Ads)
- Consent: eine Entscheidung pro Event und Destination für beide Wege
Was Track unterwegs prüft
Technische Prüfungen hinter den vier Meilensteinen anzeigen
Diese Prüfungen laufen in der geführten Sitzung und später im Worker. Sie sind der Grund, warum die vier Meilensteine reichen — du musst sie nicht von Hand nachprüfen.
Site und Installation
- Domain-Format und Erreichbarkeit
- Inhaberschaft per DNS-Eintrag, Verifikationsdatei oder Meta-Tag
- Snippet vorhanden und Konfigurationssignatur im Browser geprüft
- Erster Seitenaufruf auf dem Ingest-Host empfangen
Plattform, Consent-Tool und Eventplan
- Shop- oder CMS-Plattform mit Konfidenzangabe erkannt
- Consent-Tool erkannt (TCF 2.2, GPP, Cookiebot, OneTrust, Usercentrics oder Consent-API)
- Eventplan-Vorlage für den Geschäftstyp gewählt (Shop, Leadgenerierung, SaaS, Publisher)
- Pflichtparameter pro Standardevent, Namensregeln für Custom-Events, PII in Properties blockiert
Destinationen und Zugangsdaten
- Öffentliche IDs gegen das Format des Anbieters geprüft
- Access-Tokens per Karte oder OAuth im Tresor abgelegt; nie im Transkript
- Von jeder Destination benötigter Consent-Zweck erfasst
- Click-ID-Matrix geprüft: jede ID nur an ihre Plattform weitergegeben
Test, Review und Veröffentlichung
- Testevent durch die echte Queue und den echten Worker gesendet; Anbieterurteil protokolliert
- Diff, Empfängerliste und Freigebende an ein Freigabe-Token gebunden
- Bundle mit Ed25519 signiert, versioniert und unveränderlich
- Audit-Eintrag für jeden Tool-Aufruf und jede Freigabe
Nach dem Go-live
- Health-Score: Consent-Abdeckung, kritische Events, Schemaqualität, Duplikate, Zustellung, Aktualität
- Retries mit Backoff, Circuit Breaker und Dead-Letter-Queue pro Destination
- Probleme nach Fingerprint gruppiert, jedes benennt das Tool, das es löst
- Rollback auf jede frühere Version
Zwei Ebenen, eine signierte Konfiguration
Eine Control Plane für Menschen und den Assistenten, eine Data Plane für Events. Sie teilen nichts außer der signierten Konfiguration — ein technischer Beleg nach den Meilensteinen, keine Voraussetzung, um Track zu nutzen.
| Komponente | Aufgabe |
|---|---|
| Browser-SDK | Consent-gesteuerter Speicher, CMP-Adapter, gebündelter Transport, SPA-Tracking, Anbieter-Loader mit gemeinsamen Dedup-IDs. Durch ein CI-Budget unter 30 KB gzip gehalten. |
| Collector | Origin-Allowlist, Rate-Limits, HMAC-signierte Server-Requests, Kill-Switches, Übergabe an die dauerhafte Queue vor der 202-Antwort. |
| Worker | Normalisierung, PII-Scan, Consent-Policy, Event-Store, Conversion-Dedup, Usage-Ledger, Fan-out, Zustellung mit Retries und DLQ. |
| Control Plane | Dashboard und Assistent: typisierte Tools, Freigaben, Audit-Log, RBAC, Abrechnung, Datenschutz-Center — getrennt von der Datenebene. |
Fragen
- Brauche ich einen Tag-Manager?
- Nein. Der Tracker lädt Anbieter-Tags nach Consent selbst. Bestehende GTM-Setups können während der Migration parallel laufen.
- Wo werden Daten verarbeitet?
- In der EU. Anbieter-APIs erhalten nur, was du konfiguriert hast, auf der bei jeder Destination dokumentierten Übermittlungsgrundlage.
- Wie ist die Konfiguration geschützt?
- Bundles sind unveränderlich, versioniert und Ed25519-signiert; das SDK prüft die Signatur, bevor eine Konfiguration angewendet wird.
- Was ist, wenn der KI-Anbieter nicht erreichbar ist?
- Dieselben Einrichtungszustände gibt es als regelbasierten Assistenten. Nichts in der Pipeline hängt davon ab, dass ein Modell online ist.
Bereit, wenn du es bist
Site anlegen, Snippet einfügen und den Assistenten die erste Destination einrichten lassen.