Track

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.

Snippet → Track → PlattformenDas Snippet auf deiner Website sendet Events aus dem Browser; dein Shop oder Server sendet dieselben Conversions mit einer gemeinsamen Event-ID. Track prüft Consent an einem Policy-Gate und leitet jedes Event an Meta, Google Ads, Google Analytics 4 und TikTok weiter.Websiteeine Event-IDBrowser-SDKServer-APITrackConsent / PolicyConsent erteiltMetazugestelltGoogle AdszugestelltGA4zugestelltTikTokzugestellt
Snippet → Track → Consent/Policy → Plattformen. Dasselbe Bild siehst du im Debugger für jedes echte Event.

Vier Meilensteine, eine Sitzung

Das ist die Sicht des Kunden. Die technischen Prüfungen hinter jedem Meilenstein stehen weiter unten.

  1. 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.

  2. 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.
    1. 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?

    2. Du

      Ja, Meta zuerst.

    3. 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.

    gespeichert

    Testevent · purchase

    Durch die echte Pipeline gesendet, mit dem Test-Event-Code des Anbieters.

    von Meta akzeptiert

    Version 13 veröffentlichen

    Gebunden an genau dieses Diff und an dich als freigebende Person.

    wartet auf deine Freigabe
    • + destination meta: browser + server
    • + mapping purchase → Purchase (event id, order id)
    • ~ consent: marketing required for meta
    Freigeben und veröffentlichen

    Der Assistent schlägt vor, Tools validieren, du gibst frei.

  3. 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
  4. 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 currency

      12 Events in den letzten 24 h fehlt der Pflichtparameter

      Lösung: Event-Mapping aktualisieren
    • Consent-Signal fehlt

      9 % der Events kamen ohne expliziten Consent-Zustand an

      Lösung: CMP-Adapter verbinden

    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.

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
Beide Wege, eine Event-IDDie Website sendet Events aus Browser-SDK und Server-API mit einer gemeinsamen Event-ID an Track; das Consent-Gate ist offen und die Events erreichen die Destinationen.Websiteeine Event-IDBrowser-SDKServer-APITrackConsent / PolicyConsent erteiltMetazugestelltGoogle AdszugestelltGA4zugestelltTikTokzugestellt

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.

Zwei Ebenen, eine signierte Konfiguration
KomponenteAufgabe
Browser-SDKConsent-gesteuerter Speicher, CMP-Adapter, gebündelter Transport, SPA-Tracking, Anbieter-Loader mit gemeinsamen Dedup-IDs. Durch ein CI-Budget unter 30 KB gzip gehalten.
CollectorOrigin-Allowlist, Rate-Limits, HMAC-signierte Server-Requests, Kill-Switches, Übergabe an die dauerhafte Queue vor der 202-Antwort.
WorkerNormalisierung, PII-Scan, Consent-Policy, Event-Store, Conversion-Dedup, Usage-Ledger, Fan-out, Zustellung mit Retries und DLQ.
Control PlaneDashboard 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.