page_view oder purchase. Deine KPIs und die meisten Graphs zählen Events.Jeder KPI und jeder Graph auf der Seite reagiert auf dieselbe Filterleiste oben, scope also die gesamte Ansicht auf das Segment, das du möchtest, bevor du anfängst, die Zahlen zu lesen.
Du kannst alle Grafiken filtern nach:
Die 4 Kacheln oben sind deine Headline-Metriken. Jede zeigt den aktuellen Wert für die aktiven Filter und dessen Veränderung im Vergleich zum vorherigen Zeitraum gleicher Länge.
Ein kurzer Hinweis zu den Trend-Farben, denn ein Aufwärtstrend ist nicht immer gut:
• Bei Total GA4 events und Consent rate ist ein Aufwärtstrend positiv und wird in Grün angezeigt.
• Bei Tracking prevention impact und Adblock impacted events wird ein Aufwärtstrend in Rot angezeigt. Ein Anstieg hier bedeutet, dass mehr deines Traffics von Datenverlust betroffen ist, Daten, die TAGGRS in deinem Auftrag zurückgewinnt, aber trotzdem ein Signal, das du im Auge behalten solltest.
Die Gesamtanzahl der GA4-Events, die server-seitig für den ausgewählten Scope erfasst wurden. Das ist dein Basis-Volumen.
Lies es als: deine Headline-Aktivitätszahl. Vergleiche sie mit dem vorherigen Zeitraum, um unerwartete Rückgänge oder Spikes zu erkennen.
Was tun, wenn sie sich verändert: Ein plötzlicher Rückgang bedeutet meistens, dass ein Tag nicht mehr feuert oder ein Deploy etwas kaputtgemacht hat. Wechsle zu Last 24 hours, filtere nach Event name und finde heraus, welches Event gefallen ist.
Drill into: Signal Comparison und Request distribution.
Der Anteil der Events, den Browser-Tracking-Prevention-Funktionen (Safari's ITP, Firefox's ETP und Ähnliches) bei einem rein client-seitigen Setup blockiert hätten – die TAGGRS aber trotzdem server-seitig erfasst.
Lies es als: wie viel deines Publikums hinter Browser-Datenschutzmaßnahmen sitzt und wie viel Daten diese Maßnahmen dich sonst kosten würden.
Was tun, wenn er sich verändert: Prüfe zunächst, ob sich dein Browser-Mix verschoben hat, bevor du von einem Tracking-Problem ausgehst.
Drill into: Improved data quality and Browser Analytics.
Der Anteil der Events, den Ad Blocker ohne Server-side Tracking blockiert hätten – zurückgewonnen durch das TAGGRS Enhanced Tracking Script.
Lies es als: Daten, die eine rein client-seitige Implementierung still verloren hätte, jetzt gerettet.
Was tun, wenn er sich verändert: Ein steigender Wert ist ein starkes Signal für den Mehrwert, den Server-side Tracking bringt. Bestätige, dass das Enhanced Tracking Script auf jeder Seite eingebunden ist.
Drill into: Improved data quality.
Der Prozentsatz der Nutzer, die vollständig zugestimmt haben, ein schneller Gesundheitscheck deines Consent-Setups.
Lies es als: Eine stabile oder steigende Rate ist gesund; ein plötzlicher Rückgang deutet auf ein Problem mit deiner Consent Management Platform (CMP) oder deinem Banner hin.
Was tun, wenn sie sich verändert: Öffne die Aufschlüsselung nach Consent-Typ, um zu sehen, welche Kategorie gefallen ist, anstatt es als eine einzige seitenweite Zahl zu behandeln.
Drill into: Consent Approvals.
Jeder Graph unterhalb der KPIs ist die Detailansicht hinter einer oder mehreren Kacheln. Nutze sie, um die Ursache einer Veränderung zu finden und zu entscheiden, was als Nächstes zu tun ist.
Drills into:Tracking prevention impact und Adblock impacted events.
Dies spiegelt sich auch im Graphen „Improved data quality" wider:
• Prevented from browsers blocking tracking: Events, die durch Browser-Tracking-Prevention blockiert worden wären, aber zurückgewonnen wurden. Das ist das Detail hinter dem KPI Tracking prevention impact.
• Prevented from ad blockers: Events, die durch Ad Blocker blockiert worden wären, aber zurückgewonnen wurden. Das ist das Detail hinter dem KPI Adblock impacted events.
So nutzt du ihn: Wenn sich einer der KPIs bewegt, öffne diesen Graph, um zu sehen, ob die Änderung ein einmaliger Spike oder ein anhaltender Trend ist, und welche der beiden Recovery-Quellen dafür verantwortlich ist. Ein starker Anstieg in der Ad-Blocker-Linie an einem einzelnen Tag lässt sich zum Beispiel oft auf eine Kampagne zurückführen, die besonders datenschutzbewussten Traffic angezogen hat.
Context for: Tracking prevention impact.
Browser Analytics zeigt den Browser-Mix deiner Besucher für den ausgewählten Zeitraum. Tracking Prevention betrifft jeden gängigen Browser außer Chrome: Safari's Intelligent Tracking Prevention, Firefox's Enhanced Tracking Protection und so weiter.
Je größer dein Nicht-Chrome-Anteil, desto mehr bist du client-seitigem Datenverlust ausgesetzt – und desto mehr Mehrwert bringt dir Server-side Tracking.
So nutzt du ihn: Betrachte das als die Erklärung hinter deinem KPI Tracking prevention impact. Ein steigender Safari- oder Firefox-Anteil treibt diesen KPI nach oben; eine Verschiebung hin zu Chrome zieht ihn nach unten.
Drills into:Consent rate.
Dieser Graph schlüsselt die einzelne Consent rate-Zahl in ihre zugrundeliegenden Zustände über die Zeit auf: Granted, Denied by Default und Not Set.
So nutzt du ihn: Beobachte die Linien auf Verschiebungen, anstatt nur den aktuellen Snapshot zu lesen. Eine steigende Denied by Default-Linie kann zum Beispiel auf eine CMP-Fehlkonfiguration oder eine Seite hinweisen, auf der das Consent-Banner nicht feuert.
Unterhalb des Graphs zeigt eine Aufschlüsselungstabelle die zugestimmten Events, die Approval Rate und die abgelehnten Events für jeden Consent-Typ:
So nutzt du sie: Vergleiche die Approval Rates über die verschiedenen Typen hinweg. Wenn ein Typ – zum Beispiel Analytics measurement – deutlich unter den anderen liegt, deutet das in der Regel darauf hin, dass eine einzelne Consent-Kategorie falsch konfiguriert ist, kein seitenweites Consent-Problem.
Context for:Total GA4 events, hier kommt dein server-seitiger Uplift her.
Signal Comparison zeigt, wie viele Daten dein Server-Container im Vergleich zu einem rein client-seitigen Setup erfasst. Es werden drei Datenreihen dargestellt:
Die Lücke zwischen den server-seitigen und client-seitigen Linien ist dein Uplift, die zusätzlichen Daten, die du durch Server-side Tracking gewinnst.
So nutzt du ihn: Wenn Total GA4 events niedriger aussieht als erwartet, zeigt dir dieser Graph, ob das Defizit auf der Server-Seite liegt oder einfach den client-seitigen Verlust widerspiegelt, den du inzwischen zurückgewonnen hast. TAGGRS misst den Uplift direkt aus den eingehenden Server-Container-Daten, nicht aus deiner client-seitigen Tag-Konfiguration – die Zahl wird also nicht durch Consent-Probleme, fehlerhafte Event-Verarbeitung oder fehlerhafte client-seitige Tags verzerrt. (Das client-seitige Tag wird dennoch benötigt, um die Vergleichslinie für die Client-Seite im Graph bereitzustellen.)
Context for: Gesamtes Traffic-Volumen und deine Plan-Nutzung.
Der Request distribution-Graph in deinen Analytics zeigt die Gesamtanzahl der Requests, die dein Server-Container über die Zeit erhalten hat. Denk daran: Ein Request ist jeder HTTP-Call an den Container – Pageviews und Google Tag Manager Client-Deployments (gtm.js, analytics.js, gtag.js), nicht nur getrackte Events – weshalb diese Zahl höher ist als deine Total GA4 events.
Durch Aktivieren des Show categories-Toggles im Requests-Graph kannst du detaillierte Typen von Requests und deren Quellen einsehen.
Folgende Request-Typen werden unterschieden:
So nutzt du ihn: Beobachte den Trend auf unerwartete Volumenveränderungen, die deine Plan-Nutzung beeinflussen könnten, und aktiviere dann Show categories, um zu sehen, welche Quelle sie verursacht.
Ein Event ist ein einzelner getrackter Analytics- oder Conversion-Hit, wie page_view oder purchase – das ist es, was deine KPIs zählen. Ein Request ist jeder HTTP-Call, den dein Server-Container empfängt, inklusive Script-Loads und Cookies, und deshalb immer eine größere Zahl. Nur der Request distribution-Graph zählt Requests; alles andere auf dieser Seite zählt Events.
Deine Nutzung wird automatisch berechnet und oben in deinem Account angezeigt. Sie hängt hauptsächlich von der Anzahl der Clients ab, die du nutzt (z. B. GA4), deinem Website- oder App-Traffic (Pageviews) und der Anzahl der zusätzlichen Events, die du trackst (wie E-Commerce-Events). Du möchtest eine detaillierte Aufschlüsselung? Sieh dir unsere Seite zu den Server-side Tracking-Kosten an.
Die TAGGRS-Uplift-Messung basiert direkt auf den eingehenden Server-Container-Daten und nicht auf deiner client-seitigen TAGGRS-Tracking-Tag-Konfiguration. Das macht sie deutlich zuverlässiger: Deine Uplift-Werte werden nicht länger durch Consent-Probleme, fehlerhafte Event-Verarbeitung oder client-seitige Tag-Fehlkonfigurationen beeinflusst. Das client-seitige Tag wird weiterhin benötigt, um die Vergleichsdaten für die Client-Seite im Signal Comparison-Graph bereitzustellen.
