5 Min. Lesedauer

Server-vs-Client-Abgleich

Kunden vergleichen ihre Zenovay-Zahlen regelmäßig mit GA4, Stripe-Belegen oder ihren eigenen Backend-Logs und stellen fest, dass die Zahlen nicht ganz übereinstimmen. Manchmal meldet Zenovay mehr Ereignisse, manchmal weniger. Die ehrliche Antwort lautet: Jedes Analytics-Tool — auch Zenovay — liefert eine Schätzung auf Basis dessen, was den Browser, was den Server und was eine Webhook-Bestätigung erreicht hat.

Der Abgleich ist Zenovays Mechanismus, um diese Lücke mit Konfidenz-Labels zu quantifizieren, statt sie zu ignorieren.

Was verglichen wird

Der Abgleich läuft als täglicher Job, der drei Wahrheitsschichten pro Website, Metrik-Typ und Tag vergleicht:

Schicht	Was sie misst	Wo sie liegt
Client	Vom Browser-Tracker ausgelöste Ereignisse	`page_views`, `user_events` mit `source = 'browser'`
Server	Über `POST /api/v1/events` ingestierte Ereignisse	Dieselben Tabellen, `source = 'server'`
Webhook	Stripe-/LemonSqueezy-/Polar-Webhook-Bestätigungen	`payment_events` mit `status = 'succeeded'`

Für jedes (Website, Tag, Metrik)-Tripel werden gespeichert: wie viele Ereignisse jede Schicht gesehen hat, wie viele übereinstimmen, der geschätzte Verlust in Prozent und ein primärer Mismatch-Grund aus einer festen Liste.

Die drei V1-Metriktypen

V1 deckt die drei Metriken ab, für die es eine eindeutige Wahrheitsschicht gibt:

Seitenaufrufe — Client (Browser) vs. Server (POST /api/v1/events).
Ziel-Abschlüsse — Client-Zielereignisse vs. serverseitige Zielereignisse.
Umsatz-Ereignisse — Client-Kaufereignisse vs. Stripe-Webhook-Wahrheit (payment_events).

Benutzerdefinierte Ereignisse, Identify-Aufrufe und andere Ereignistypen sind in V1 nicht enthalten — sie haben keine vergleichbare Wahrheitsschicht.

Wie der Verlust geschätzt wird

Für Seitenaufrufe und Ziele ist die Wahrheitsschicht server_count. Für Umsatz ist die Wahrheitsschicht webhook_count (der Webhook des Zahlungsanbieters ist die Quelle der Wahrheit — er hat tatsächlich den Kunden berechnet).

estimatedLoss = (truth - client) / truth × 100

Negative Werte sind erlaubt: Wenn der Server mehr Ereignisse erfasst hat als der Browser-Tracker, ist auch das eine Information — dies bedeutet, dass Ihr Tracker Ereignisse verpasst hat, die die serverseitige Erfassung aufgefangen hat, und genau dafür betreibt man beide.

Konfidenz-Labels

Jede Abgleichszeile trägt eines von drei Labels:

Label	Wann es greift
Hohe Konfidenz	Beide Schichten haben jeweils ≥100 Ereignisse, geschätzter Verlust unter 30 %.
Mittlere Konfidenz	Eine der Schichten liegt im Bereich 50–100 Ereignisse, oder der Verlust liegt zwischen 30 % und 60 %.
Begrenzte Daten	Unter 50 Ereignisse auf einer Schicht, Verlust über 60 %, oder nur eine Schicht überhaupt vorhanden.

„Begrenzte Daten" ist kein Fehler, der behoben werden muss — es bedeutet nur, dass die Stichprobe zu klein oder einseitig ist, um eine sichere Aussage zu treffen. Konfidenz-Labels halten die Trust-Ansicht ehrlich.

Mismatch-Gründe

Wenn der Abgleich eine relevante Lücke erkennt, wählt er einen von sieben Gründen, sortiert nach Erkennungspriorität:

Grund	Erkennungsregel	Handlungsbedarf?
`webhook_delay`	Client > Webhook um ≥20 % UND heutige Webhook-Anzahl ≥2σ unter 6-Tage-Mittel	✓
`client_blocked`	Server > Client um ≥10 %	✓
`route_mapping`	Top 1–2 Routen verursachen ≥50 % der Lücke	✓
`duplicate_suppression`	Die Ingest-Pipeline hat Browser-Ereignisse innerhalb des Tages dedupliziert	informativ
`id_stitching`	Hohe Varianz nicht zugeordneter Client-Ereignisse über Besucher-Segmente	informativ
`no_server_layer`	`server_count = 0` und `client_count > 0`	informativ
`unknown`	Keine Schwelle erreicht	informativ

Drei Gründe sind handlungsrelevant — die Maßnahme liegt bei Ihnen (CSP korrigieren, SDK-Wiederholung konfigurieren, Stripe-Webhook-Zustellung prüfen). Die anderen vier liefern diagnostischen Kontext.

Wo Sie es sehen

Öffnen Sie Domains, klicken Sie auf Ihre Website und wählen Sie dann den Reiter Trust (unter Zuverlässigkeit). Sie sehen dort:

Den geschätzten Tracking-Verlust der letzten 7 Tage mit Konfidenz-Label.
Eine Aufschlüsselung pro Metrik (Seitenaufrufe, Ziele, Umsatz) mit Client- / Server- / Übereinstimmungs-Zählungen und der Lücke visualisiert als gestreifter Abschnitt eines Vollständigkeitsbalkens.
Die wichtigsten Mismatch-Gründe, sortiert nach Ereignisauswirkung, mit Handlungsschritten für die handlungsrelevanten.
(Pro und höher) Eine Drilldown-Tabelle pro Route, die zeigt, welche Routen den größten Anteil an der Lücke haben.

Was es nicht ist

Es ist keine Garantie für Korrektheit. Es ist eine Messung der Messqualität.
Es ist kein Versuch, die Lücke zu schließen. Die Maßnahmen — CSP-Konfiguration, Webhook-Konfiguration, Route-Normalisierung — liegen auf Ihrer Seite.
Es nennt keine Drittanbieter-Dienste oder Anbieter, die Sie nicht ohnehin schon nutzen. Mismatch-Gründe bleiben generisch, damit die Handlungsschritte unabhängig von Ihrem Stack relevant bleiben.
Es führt keine neue Datenerfassung ein. Der Abgleich liest bestehende Zeilen aus page_views, user_events und payment_events — keine neuen Cookies, keine neuen Identifier, die Cookieless-Tracking-Garantie bleibt unverändert.

Plan-Verfügbarkeit

Der Trust-Reiter selbst ist in jedem Plan verfügbar. Drilldown pro Route und Handlungsschritte für handlungsrelevante Gründe sind ab Pro verfügbar. Free zeigt Aggregate und Grund-Namen ohne Routen-Detail.