GA4 Audit: 7 Fehler, die wir in fast jedem Setup finden, und was sie kosten

GA4 sieht funktionieren aus. Genau das ist bei den meisten Setups das Problem.

Letztes Quartal saßen wir im Audit-Call mit einem Shopify-Kunden im mittleren siebenstelligen Jahresumsatz. Sauberes GTM-Setup, GA4 lief seit der UA-Migration durch, das Marketing-Team optimierte wöchentlich. Die Verantwortliche sagte den Satz, den wir alle paar Wochen hören: „Eigentlich sieht alles okay aus, wir wollen nur einmal jemanden drüberschauen lassen."

Drei Tage später hatten wir elf Fehler dokumentiert. Drei davon waren kritisch: doppelt gefeuerte Purchase-Events (Google Ads bekam jede Bestellung zweimal), Consent Mode V2 falsch konfiguriert, Cross-Domain seit dem Wechsel des Checkout-Anbieters leise kaputt. Die Folge: Smart Bidding optimierte seit Monaten auf Signale, die nicht stimmten. Das Marketing-Budget wurde aufgrund von Daten erhöht, die strukturell falsch waren.

Wir auditen seit drei Jahren GA4-Setups. Healthcare, Retail, B2B-SaaS. Keine zwei sind gleich kaputt. Aber sieben Fehler tauchen so konsistent auf, dass wir sie inzwischen als Default-Annahmen prüfen, bevor wir den Kunden überhaupt sprechen.

Warum das Thema 2026 noch teurer geworden ist: der GA4-BigQuery-Export ist inzwischen die Standardquelle für eine ganze nachgelagerte Werkzeugschicht. RevOps-Dashboards, MMM-Modelle, Marketing-Mix-Optimierer, Customer-Data-Plattformen, AI-Agenten, die Performance-Empfehlungen vorschlagen. Garbage in, garbage out, nur dass „in" jetzt zwölf nachgelagerte Systeme sind. Ein doppelter Purchase-Event in GA4 verzerrt 2026 nicht mehr nur den Google-Ads-Smart-Bidder; er trainiert einen LLM-basierten „Insight-Agent" mit, der dem CMO daraufhin falsche Empfehlungen vorschlägt. Die Halbwertszeit eines Tracking-Fehlers ist damit von „bis zum nächsten Audit" auf „bis zum nächsten Re-Training" gesprungen.

Die These dieses Artikels: Wenn ein GA4-Setup nach der UA-Migration nicht systematisch auditiert wurde, liegen mit hoher Wahrscheinlichkeit mindestens drei der unten genannten Fehler vor, die kritischen meistens inklusive. Hier ist der Audit-Report dahinter, sortiert nach Risiko, mit konkreten Diagnose-Schritten und Business-Impact pro Fehler.

Severity-Matrix: Was zuerst prüfen?

Die Reihenfolge unten ist nicht „häufigste zuerst", sondern „kostet am meisten, wenn der Fehler weiterläuft".

#1. KRITISCH: Conversions werden doppelt an Google Ads gefeuert

Symptom

Die GA4-Conversions liegen systematisch über den Bestellungen aus dem Shop-Backend (Shopify, Shopware, Salesforce). Häufig zwischen 8 und 60 Prozent höher. Smart Bidding in Google Ads liefert seit Wochen „stark", aber der Backend-ROAS fühlt sich schlechter an als die Zahlen behaupten. Klassisches Begleitsymptom: in der GA4-DebugView erscheinen beim Test-Kauf zwei purchase-Events innerhalb derselben Sekunde, mit derselben transaction_id.

Diagnose, drei Checks in 15 Minuten

1. Backend-Vergleich. Eine zufällige Woche aus den letzten 30 Tagen. GA4-Bericht: Werbung → Conversions → purchase. Shop-Backend: tatsächliche Bestellungen im selben Zeitraum. Differenz über 5 Prozent ist ein roter Flag.
2. GTM-Tag-Audit. Container öffnen, alle Tags nach „purchase" oder „transaction" filtern. Mehr als ein Tag pro Conversion-Plattform (z. B. zwei für GA4, oder ein altes UA-Tag plus ein GA4-Tag) = Ursache gefunden.
3. DebugView Live-Test. Test-Bestellung im Inkognito-Modus, GA4 DebugView offen. Es darf genau ein purchase-Event mit der jeweiligen transaction_id ankommen. Mehrere = Doppelung bestätigt.

Business Impact

Beispielrechnung: ein Shop mit 500 Bestellungen pro Monat à 120 € AOV. Doppelte Conversions bedeuten: Google Ads zählt 1.000 Conversions statt 500. Smart Bidding optimiert auf die doppelte Conversion-Rate, hält den Ziel-CPA stabil, bietet aber für jeden Klick effektiv das Doppelte. Aus einem realistischen CPA von 30 € werden plötzlich 60 €. Bei einem Monatsbudget von 15.000 € landet die Hälfte in Anzeigen, die ohne den Mess-Fehler nie diese Klickpreise gesehen hätten.

Bei B2B mit niedrigem Volumen, aber hohem Ticket-Wert wird der Effekt subtiler, und schlimmer: ein einziges falsch zugeordnetes Lead-Event kann die Kampagnen-Strategie für ein Quartal verschieben.

Fix

Ursache ist fast immer eines von zwei Dingen: alte UA-Tags, die bei der Migration im GTM nicht deaktiviert wurden, oder ein purchase-Event, das sowohl vom Shop-DataLayer-Push als auch von einem GTM-URL-Trigger auf die Thank-You-Seite gefeuert wird (URL-Trigger feuern bei jedem Reload erneut).

Die Lösung in drei Schritten:

1. Alle purchase-Tags im GTM identifizieren und auf genau eines pro Plattform reduzieren.
2. Ausschließlich auf den DataLayer-Event triggern, nie auf URLs.
3. Idempotenz absichern: jede Bestellung muss eine eindeutige transaction_id bekommen. GA4 dedupliziert nur innerhalb derselben Session, bei Reload ist der Schutz weg.

Bei Server-Side-Setups (sGTM) kann derselbe Fehler auf zwei Ebenen passieren: Client-GTM feuert plus Server-GTM forwardet zusätzlich. Hier hilft nur ein End-to-End-Trace mit Request-IDs.

Wer nach diesem Check eine Diskrepanz von über 10 Prozent findet: Smart-Bidding-Optimierungen pausieren, bis der Fehler behoben ist. Jeder weitere Tag verbrennt Budget.

#2. KRITISCH: Consent Mode V2 fehlt oder ist falsch konfiguriert

Symptom

GA4 zeigt 30 bis 50 Prozent weniger Conversions als das Shop-Backend. In Google Ads sind die Conversion-Spalten halb leer. Smart Bidding bekommt zu wenig Signal und schaltet Anzeigen ab, die in Wirklichkeit performen. Im Cookie-Banner zeigt der Tag Assistant denied für ad_storage und ad_user_data, aber GA4 verhält sich, als wäre nie ein Default-State gesetzt worden.

Diagnose

1. Default-State im GTM prüfen. Container öffnen → Consent → Standardeinstellungen. Wenn dort kein Consent-Default-Tag vor allen anderen Tags feuert, fehlt die Grundlage.
2. CMP-Mapping prüfen. OneTrust, Cookiebot, Usercentrics, jede CMP mappt eigene Kategorien auf die Google-Consent-Signale. Häufiger Fehler: ad_user_data und ad_personalization werden nicht oder falsch gemappt. In der CMP-Konsole nachsehen, ob die Google-Consent-Mode-Integration aktiv ist.
3. Tag Assistant Live-Test. Banner ablehnen → Test-Bestellung. Im Tag Assistant prüfen, ob der consent-State in den GA4- und Google-Ads-Tags ankommt. Wenn nicht: das Default-Tag feuert nicht früh genug.
4. Observed-vs-Modeled-Ratio prüfen. GA4 → Werbung → Attribution → Conversion-Pfade. Wenn der Anteil modellierter Conversions konstant über 50 Prozent liegt oder unter 10 Prozent fällt, stimmt etwas in der Consent-Mode-Konfiguration nicht. Gesunde Werte 2026: 15–40 Prozent modelliert.

Business Impact

Eine Performance-Kampagne, die auf modellierte statt echte Daten optimiert, läuft unter Umständen wochenlang auf Schätzungen. Bei einer Healthcare-Marke fanden wir nach der Consent-Mode-V2-Umstellung gleich mehrere Lücken: kein Default-State im GTM, OneTrust hatte ad_storage und ad_user_data nicht sauber auf die Consent-Kategorien gemappt. Knapp zwei Wochen lang lief das Performance-Marketing faktisch blind, bevor wir den GTM als Safety Layer dazwischengelegt haben.

Dazu kommt das rechtliche Risiko: Mehrere Datenschutz-Aufsichten in Deutschland haben 2025 angefangen, Consent-Mode-Konfigurationen aktiv zu prüfen. Ein Cookie-Banner, der consent nicht korrekt verdrahtet hat, ist angreifbar, unabhängig davon, ob er optisch DSGVO-konform aussieht.

Fix

Drei Pflicht-Komponenten, die zusammenpassen müssen:

1. Default-Consent-Tag im GTM, das vor allen Marketing-Tags feuert (Trigger: Consent Initialization. All Pages). Default = denied für alle Werbe-Kategorien.
2. CMP-Update-Tag: nach Banner-Interaktion sendet die CMP ein Update an den GTM, das den Consent-State aktualisiert.
3. Advanced statt Basic. Basic feuert ohne Einwilligung gar nichts und kostet damit alle Conversions ohne Consent. Advanced sendet anonymisierte Pings ohne Identifier, sodass Google die fehlenden Conversions modellieren kann. 2026-Stand: wer noch Basic einsetzt, lässt typischerweise 30–50 Prozent der Conversion-Daten ungehoben. Advanced ist die Default-Empfehlung, sobald die CMP es technisch unterstützt.

Observed vs. modeled: GA4 unterscheidet zwischen beobachteten Conversions (User hat ausreichend Consent → echter Identifier) und modellierten Conversions (User hat abgelehnt → Google extrapoliert aus den anonymen Pings + dem aggregierten Verhalten der Cohort). Eine gesunde Advanced-Consent-Mode-Property liegt bei 60–85 Prozent observed und 15–40 Prozent modeled. Werte außerhalb dieser Range deuten auf eine Setup-Lücke hin, entweder die anonymisierten Pings landen gar nicht (zu wenig modelliert) oder der Identifier wird gar nicht erst geschrieben (zu viel modelliert).

Wer 2026 noch Consent Mode Basic einsetzt, handelt in unseren Augen fahrlässig, dem Marketing entgeht ein zweistelliger Prozentsatz an Conversion-Daten, ohne dass der Datenschutzgewinn das rechtfertigt.

#3. KRITISCH: E-Commerce-Tracking ist nach der Migration kaputt

Symptom

Im GA4-E-Commerce-Report fehlen Produkt-Namen oder es stehen seltsame Strings. Conversion-Werte sind 10× zu hoch (Komma-vs-Punkt-Problem im Preisfeld). Der Coupon-Code wird im purchase-Event nicht mitgesendet, also kann das Marketing nicht mehr nachvollziehen, ob die Aktion gewirkt hat. Im Vergleich zwischen GA4, Meta-Pixel und Klaviyo schwanken die „Verkäufe" um mehrere Prozent.

Diagnose

1. DebugView mit echter Test-Bestellung. GA4 → DebugView → eine echte Test-Bestellung durchklicken. Auf das purchase-Event klicken und die Items-Liste prüfen.
2. Felder gegen die GA4-Spezifikation matchen. Pflicht-Felder: item_id, item_name, price, quantity. Wenn dort id oder name ohne Prefix steht, nimmt GA4 es nicht oder nur teilweise an.
3. Plattform-Cross-Check. Bestellbestätigung öffnen, alle E-Commerce-Tags identifizieren (Network-Tab, gefiltert auf collect, pixel, track). Wenn drei oder mehr Tools dieselbe Bestellung tracken, lohnt sich ein Tag-by-Tag-Vergleich der gesendeten Item-Felder.

Business Impact

Bei einem Retail-Kunden, den wir vor einem Jahr übernommen haben, fanden wir auf der Bestellbestätigung vierzehn verschiedene E-Commerce-Tags. Universal-Pixel, GA4-Tag, Meta-Pixel mit eigenen Item-IDs, Klaviyo-Pixel mit nochmal anderen IDs. Jedes Tool sah leicht andere Zahlen. Zwischen den Plattformen variierten die „Verkäufe" um etwa 8 Prozent. Konsequenz: Reports an die Geschäftsführung waren je nach Tool-Quelle unterschiedlich. Die Diskussionen, welche Zahl „stimmt", kosteten mehr Zeit als der Fix selbst.

Wenn die Item-Daten unvollständig sind, fallen außerdem alle nachgelagerten Auswertungen weg: Top-Produkte, Kategorie-Performance, Cross-Sell-Patterns. Das ist die Datenbasis für Sortimentsentscheidungen, wenn sie kaputt ist, wird mit Bauchgefühl statt mit Daten entschieden.

Fix

Ein einheitliches DataLayer-Schema nach GA4-Spezifikation, das Quelle für alle Marketing-Pixel ist. Unten der typische „Vorher/Nachher": links der kaputte Push, den wir in Audits regelmäßig finden (Pflicht-Felder fehlen), rechts der gefixte mit allen GA4-Spec-Feldern.

·dataLayer.push({
·event: 'purchase',
·ecommerce: {
·transaction_id: 'T_12345',
−// value: missing
−// currency: missing
·items: [{
−id: 'SKU_001',
−name: 'Produktname',
−// price: missing
−// quantity: missing
·}]
·}
·});

Alle Marketing-Tags (GA4, Meta, TikTok, Klaviyo) ziehen aus genau diesem Push ihre Variablen. Eine Quelle, ein Schema, eine Wahrheit. Die Migration alter Tags auf das neue Schema ist Tagelange-Fleißarbeit, aber sie räumt einen ganzen Topf von Folgeproblemen ab.

#4. HOCH: Cross-Domain-Tracking fehlt oder ist gebrochen

Symptom

Die Conversion-Quellen-Reports zeigen ungewöhnlich viel (direct) / (none), gerade bei Sessions, die offensichtlich aus Google Ads stammen. Die Sessions-Anzahl in GA4 ist auffällig höher als die User-Anzahl, weil derselbe Nutzer auf zwei Domains als zwei Sessions erscheint.

Diagnose

1. Funnel manuell durchklicken. Von marke.de bis zur Bestellbestätigung auf shop.marke.de. In den DevTools (Network-Tab) prüfen, ob beim Domain-Wechsel der ?_gl=-Parameter in der URL angehängt wird, das ist der Linker. Fehlt er, ist Cross-Domain nicht aktiv.
2. Client-ID-Konsistenz prüfen. In der GA4 DebugView vor und nach dem Domain-Wechsel die Client-ID des Test-Users vergleichen. Ändert sie sich, ist die Verlinkung kaputt.
3. Datenstream-Konfig öffnen. Admin → Datenstreams → Web → Tagging-Einstellungen konfigurieren → Domains festlegen. Beide Domains müssen explizit aufgeführt sein. Sub-Domains werden nicht automatisch erfasst, auch nicht checkout.marke.de.

Business Impact

Der Nutzer kommt über Google Ads auf marke.de, klickt sich durch, springt auf shop.marke.de und kauft. Ohne Cross-Domain wird die Conversion shop.marke.de zugeschrieben, als (direct). Die Google-Ads-Kampagne, die den Trip eigentlich gestartet hat, bekommt keine Attribution. Smart Bidding optimiert weg von Anzeigen, die scheinbar nicht konvertieren, und schaltet sie ab. Echtes Geld, falsche Entscheidung.

Wir hatten letzten Sommer einen Retail-Kunden, bei dem Cross-Domain seit anderthalb Jahren leise kaputt war, niemand hatte den Wechsel des Checkout-Anbieters auf eine neue Sub-Domain im GA4-Setup nachgezogen. Die Performance-Kampagnen waren systematisch unter ihrem realen Wert bewertet.

Fix

In der GA4-Property: Datenstream → Tagging-Einstellungen → Domains festlegen → alle relevanten Domains und Sub-Domains eintragen. Bei mehreren Datenstreams (z. B. Web + App) muss die Cross-Domain-Konfiguration für jeden Stream separat passen.

Wichtig nach jedem Wechsel von Sub-Domains, Checkout-Anbietern oder Payment-Providern: Cross-Domain-Setup explizit nachprüfen. Das ist die häufigste Ursache für „plötzlich performt nichts mehr".

#5. HOCH: Enhanced Conversions sind nicht aktiv (oder leer)

Symptom

In Google Ads zeigt die Spalte Enhanced Conversions Status entweder „nicht aktiviert" oder „aktiv, aber unter 50 % Match-Rate". Die Conversion-Volumes wirken speziell auf Safari und iOS systematisch zu niedrig.

Diagnose

1. Google Ads → Tools → Conversions → einzelne Conversion-Aktion öffnen. Im Reiter „Diagnose" steht der Match-Rate-Status. Unter 70 % = handlungsbedürftig.
2. GTM-Variable prüfen. Im Conversion-Tag schauen, ob das user_data-Object verlinkt ist und ob die Variablen email, phone_number, address aus dem DataLayer gefüllt werden.
3. DataLayer-Check. Auf der Bestellbestätigungsseite Konsole öffnen, dataLayer ausgeben. Wenn die Felder leer sind oder erst nach dem Tag-Fire befüllt werden, läuft Enhanced Conversions ins Leere.

Business Impact

Enhanced Conversions hashen E-Mail, Vorname, Nachname und schicken sie verschlüsselt an Google Ads, sodass Google die Conversion einer Anzeige zuordnen kann, auch wenn der Cookie längst weg ist (Safari, iOS, Adblocker). Klingt nach DSGVO-Risiko, ist es nicht: die Daten werden vor dem Senden gehasht, Google sieht keinen Klartext. Korrekt umgesetzt ist es DSGVO-konform.

Was es bringt: 10 bis 30 Prozent zusätzliche Conversion-Zuordnungen für Google Ads. Das heißt: 10 bis 30 Prozent mehr Daten für Smart Bidding. Was wiederum bedeutet: bessere Auslieferung, niedrigerer CPA. Nicht magisch, aber real. Etwa die Hälfte der Setups, die wir auditen, hat Enhanced Conversions gar nicht aktiv. Ein weiteres Viertel hat es aktiviert, aber die DataLayer-Variablen liefern leere Strings, also läuft es ins Leere.

Fix

Voraussetzung ist ein sauberer DataLayer, der auf der Bestellbestätigung die Käuferdaten enthält. Dann im GTM:

1. Variablen anlegen für user_data.email_address, user_data.phone_number, user_data.address.first_name etc.
2. Im Google-Ads-Conversion-Tag diese Variablen im Feld User-provided data verlinken.
3. Wichtig: E-Mail vor dem Hashing in Lowercase normalisieren. Das ist der häufigste Fehler. Mixed-Case-Mails matchen nicht.

Im Tag Assistant kontrollieren: bei einer Test-Conversion müssen sha256_email, sha256_phone_number und address-Felder befüllt sein.

#6. MITTEL: Event-Spam und nicht gefilterter Bot-Traffic

Symptom

Top-Quellen: (direct) / (none) mit auffällig hohem Volumen. Sessions mit Dauer = 0 sind deutlich häufiger, als sie sein sollten, und in Conversion-Reports tauchen Käufe oder Lead-Events auf, die im CRM nie ankommen. Die Tages-Partition im BigQuery-Export wächst unverhältnismäßig schnell. Zeilen mit kuriosen Event-Namen. Oder identischen User-Pseudo-IDs.

Diagnose

1. Sessions nach Dauer = 0 sortieren. GA4 → Berichte → Engagement → Seiten und Bildschirme. Hohe Anzahl Zero-Duration-Sessions auf bestimmten URLs ist verdächtig.
2. Page-Path-Auffälligkeiten. URLs prüfen, die nur DevOps oder externe Tools aufrufen würden. Health-Checks, Status-Pages, Pre-Production-URLs.
3. User-Agent-Analyse. Wenn BigQuery-Export aktiv ist: nach User-Agents gruppieren. Die echten Browser-Strings haben charakteristische Patterns; Crawler und Monitoring-Skripte fallen sofort auf.
4. Event-Count-Heatmap im BigQuery-Export. SELECT event_name, COUNT(*) FROM events_* GROUP BY 1 ORDER BY 2 DESC. Wenn scroll, click oder page_view die Tabelle dominieren und die Conversions im einstelligen Prozentbereich liegen, läuft das Setup auf Event-Spam.

Business Impact

GA4 filtert „bekannte Bots" (Googlebot, Bingbot) automatisch. Was es nicht filtert: Crawler-Bots aus China, SEO-Tools, Uptime-Monitor-Pings, Test-Bots aus eigenen CI-Systemen. Bei kleineren Websites kann das 20 bis 40 Prozent des Traffics ausmachen.

Schlimmer: wenn ein Bot zufällig eine Cookie-Banner-Einwilligung simuliert, mehrmals dieselbe Seite lädt und dann eine „Add-to-Cart"-Aktion durch einen JavaScript-Trigger auslöst, landet das alles in GA4 als legitimer Besuch. Wir haben das bei einer Versicherungs-Website gesehen, wo ein altes Performance-Monitoring-Skript jede halbe Stunde „Quote anfragen" simuliert hat. Vierzig Prozent der „Conversions" waren Skript-Aufrufe. Niemand hatte das in zwei Jahren bemerkt.

Was 2026 dazukommt, der BigQuery-Kosten-Faktor. GA4 schreibt jeden Event als eigene Zeile in den BigQuery-Export. Bei aktivem Streaming-Export und einem typischen E-Commerce mit 1 Mio. Sessions/Monat sind das schnell 30–80 Mio. Event-Rows pro Monat. Bots und überpathologisches Click-/Scroll-Tracking blasen diese Zahl problemlos um den Faktor 3–5 auf. Bei Standard-BQ-Preisen sind das eher Cents pro Tag für Storage, aber jede einzelne Query, die ein nachgelagertes Dashboard oder ein AI-Agent gegen diese Partition fährt, scannt das aufgeblasene Volumen mit. Wir haben Setups gesehen, bei denen 70 Prozent der monatlichen BQ-Compute-Rechnung auf Event-Spam zurückgingen, und das Marketing-Team wusste nicht einmal, dass es einen BigQuery-Export gab. Jeder unnütze scroll-Event wird damit mehrfach bezahlt: einmal in der Speicherung, einmal in jeder Modell-Query, einmal in der falschen Aggregation, die ein AI-Agent darauf trainiert.

Fix

In der GA4-Property unter Datenstream → Tagging-Einstellungen → Internen Traffic definieren Filter setzen, auf User-Agent, IP, oder über benutzerdefinierte Regeln. Für Monitoring-Skripte: einen Custom-Header senden und im GTM einen Trigger-Block einbauen, der Tags bei Anwesenheit dieses Headers nicht feuert. Zusätzlich auf Event-Hygiene gehen: Scroll-Tracking nur auf den Pages, wo es wirklich gebraucht wird; click-Events nur auf interaktive Elemente, nicht auf jeden Wrapper-Div.

#7. MITTEL: Interne Zugriffe verfälschen den Traffic

Symptom

Die Bounce-Rate verhält sich seltsam, auf Pages, die für Mitarbeiter relevant sind (Karriere, Login, interne Tools), ist sie auffällig niedrig. Heatmap-Tools zeigen Klickmuster, die keinem Kundenverhalten entsprechen.

Diagnose

1. Internal-Traffic-Filter prüfen. Admin → Datenstreams → Web → Tagging-Einstellungen → Internen Traffic definieren. Sind die IPs aktuell? Decken sie auch das Home-Office des Marketing-Teams ab?
2. Office-IP gegenrechnen. Eine Stunde aus dem Office surfen, dann in DebugView prüfen, ob diese Sessions als „internal" markiert ankommen.
3. Externe Dienstleister-Zugriffe. IPs externer Dienstleister einsammeln und mit den Filtern abgleichen.

Business Impact

Bei kleineren Sites mit 5.000 Besuchern pro Monat ist das tödlich. 200 interne Zugriffe pro Tag = 6.000 pro Monat. Der Traffic-Verlauf wird zur Karikatur, Bounce-Rate-Werte werden unbrauchbar, Heatmap-Tools zeigen Klickmuster, die nicht von echten Kunden kommen. Bei größeren Sites verschwindet der Effekt zwar in der Masse, aber die Conversion-Quote in GA4 wird trotzdem verzerrt, weil interne Tester selten kaufen.

Fix

User-Properties statt IP-Filter (sicherer, weil Home-Office-IPs ständig wechseln): einen Cookie oder LocalStorage-Wert setzen, der Mitarbeiter markiert, im GTM als Variable einlesen, an GA4 als User-Property senden. Im Bericht filterbar, und gleichzeitig per Setting ganz aus dem Reporting ausschließbar. Plus: ein dedizierter Test-Datenstream für QA, der nicht ins Hauptreporting fließt. Drei Tage Aufwand, zahlt sich für Jahre aus.

Self-Audit in 30 Minuten

Drei Checks, die sich heute Nachmittag intern selbst durchführen lassen:

• [ ] Backend-Diff (Fehler #1): GA4-Conversions vs. Shop-Bestellungen, eine Woche, Diff über 5 Prozent?
• [ ] DebugView E-Commerce (Fehler #3): Test-Bestellung im Inkognito-Modus, purchase-Event-Items prüfen, alle Felder befüllt (item_id, item_name, price, quantity)?
• [ ] Cross-Domain-Linker (Fehler #4): Funnel manuell durchklicken, beim Domain-Wechsel auf ?_gl=-Parameter in der URL achten?

Wenn einer davon raus fällt: ein Anhaltspunkt steht, was die nächsten Wochen Geld kostet. Die schwierigeren Sachen. Consent-Mode-Konfig im Detail, Cross-Domain mit mehreren Sub-Domains, Server-Side-Setup, Enhanced Conversions korrekt verdrahtet, BigQuery-Schema-Sanity, lassen sich nicht in 30 Minuten prüfen.

Was es kostet, nichts zu tun

Wer bis hier gelesen hat, hat wahrscheinlich bei mindestens zwei der sieben Fehler genickt. Das ist statistisch normal. Die unangenehme Nachricht: jeder Tag, an dem ein kritischer Fehler weiterläuft, ist ein Tag, an dem das Marketing-Team auf falschen Daten Entscheidungen trifft. Bei Performance-Marketing summiert sich das schnell. Selten in einem dramatischen Einzelposten, eher in dauerhaft schlechter Budget-Allokation, die niemand direkt zuordnen kann.

2026 ist die Folgekosten-Kette länger geworden. Der GA4-BigQuery-Export speist Looker-Studio-Dashboards, MMM-Modelle, Customer-Data-Plattformen und immer öfter AI-Agenten, die dem Marketing-Team Empfehlungen geben („pausiere Kampagne X", „erhöhe Budget bei Y"). Garbage in, garbage out gilt unverändert, nur dass die Garbage jetzt durch drei nachgelagerte Modelle propagiert, bevor sie als „Insight" auf dem Manager-Dashboard landet. Wer 2026 in AI auf eigenen Daten investiert, ohne vorher den Daten-Layer zu prüfen, baut ein Empfehlungssystem, das überzeugt klingende falsche Antworten gibt. Ein Audit ist in diesem Setup keine optionale Hygiene mehr; er ist die Voraussetzung dafür, dass die nachgelagerten AI-Investments überhaupt Sinn ergeben.

Unser Audit-Sprint:

• 2 Wochen Turnaround.
• ab 1.500 € (Web-only) / ab 3.500 € (E-Commerce mit Server-Side).
• Output: priorisierte Fehler-Liste mit Severity-Score, geschätztem Business-Impact pro Fehler, konkretem Fix-Pfad.
• Kein Strategiepapier. Kein Sales-PDF. Eine Tabelle, mit der das interne Team oder wir am Montag anfangen können.

Mehr zur Methodik gibt es auf der Measurement & Privacy Engineering Service-Seite.

Außenperspektive auf das Setup gefragt? Audit Sprint anfragen →, kostenloser Discovery-Call vorab (30 Min, wir gucken live ins Setup und sagen, ob ein Audit Sinn macht oder nicht).