Warum ein gutes Tracking-Setup Teil der Website-Planung ist

Es passiert fast jedes Mal. Ein mittelständisches Unternehmen investiert sechsstellig in einen Website-Relaunch. Neues Design, frischer Content, vielleicht sogar ein Headless-CMS-Setup. Der Launch läuft gut. Die Geschäftsführung ist zufrieden. Und dann, drei Monate später, kommt die Frage: „Was bringt uns die neue Website eigentlich?“

Stille.

Niemand kann es beantworten. Nicht, weil die Website schlecht wäre. Sondern weil niemand vor dem Launch definiert hat, was überhaupt gemessen werden soll. Kein Tracking-Konzept. Keine KPIs. Kein Measurement Plan. Das Analytics-Tool wurde irgendwann in der letzten Woche vor Go-Live noch schnell eingebaut — ein Google-Analytics-Snippet im Header, fertig. Und jetzt stehen alle da und schauen auf Seitenaufrufe und Bounce Rates, als würden diese Zahlen irgendetwas Sinnvolles über den Geschäftserfolg aussagen.

Das ist kein Einzelfall. Das ist der Normalzustand im deutschen Mittelstand.

Wenn wir bei happycoding ein Website-Projekt planen, dann gehört das Tracking-Konzept in dieselbe Phase wie Informationsarchitektur, Wireframes und Content-Strategie. Nicht danach. Nicht „wenn wir mal Zeit haben“. Nicht als Nachgedanke.

Warum? Weil Tracking-Entscheidungen die technische Architektur beeinflussen. Ob du serverseitiges Tracking brauchst oder clientseitiges reicht, ob du einen Consent-Layer integrieren musst, welche Daten du an welche Systeme weiterleitest — das alles hat Auswirkungen auf die Implementierung. Wenn du diese Fragen erst nach dem Launch stellst, baust du im besten Fall um. Im schlechtesten Fall lebst du mit einem Setup, das dir keine brauchbaren Daten liefert.

Tracking nachträglich einzubauen ist wie eine Heizung nachträglich in ein fertiges Haus einzubauen. Es geht. Aber es ist teurer, hässlicher und funktioniert nie so gut, wie wenn man es von Anfang an eingeplant hätte.

Der häufigste Fehler, den ich sehe: Teams installieren ein Analytics-Tool und schauen dann, welche Daten es ihnen gibt. Das ist rückwärts gedacht. Die richtige Reihenfolge ist: Zuerst definierst du, welche Geschäftsfragen du beantworten willst. Dann leitest du daraus KPIs ab. Und dann baust du das Tracking so, dass es genau diese KPIs erfasst.

Für ein B2B-Unternehmen mit erklärungsbedürftigen Produkten könnten relevante Fragen sein: Wie viele qualifizierte Leads generiert die Website pro Monat? Welche Content-Formate führen zu Kontaktanfragen? Über welche Kanäle kommen Besucher, die tatsächlich konvertieren? Wie lange dauert die Customer Journey von Erstbesuch bis Kontaktaufnahme?

Aus diesen Fragen ergeben sich konkrete KPIs: Conversion Rate nach Kanal, durchschnittliche Touchpoints bis zur Conversion, Content-Engagement-Scores, Lead-Qualität nach Quelle. Und aus diesen KPIs ergibt sich, welche Events du tracken musst, welche Dimensionen du brauchst und wie dein Datenmodell aussehen sollte.

Diesen Prozess nennt man einen Measurement Plan. Er ist kein Nice-to-have. Er ist die Grundlage dafür, dass dein Tracking überhaupt sinnvolle Daten liefert.

Seitenaufrufe sind die Währung der Neunziger. In einer modernen Web-Applikation — besonders mit einem Framework wie Next.js, das clientseitiges Routing nutzt — sind klassische Pageviews ohnehin nur begrenzt aussagekräftig. Was du brauchst, ist eine durchdachte Event-Tracking-Architektur.

Das bedeutet: Du definierst vor dem Launch, welche Nutzerinteraktionen geschäftsrelevant sind und wie du sie als Events abbildest. Für eine B2B-Website sind das typischerweise: Formular-Submissions, CTA-Klicks, PDF-Downloads, Video-Plays, Scroll-Tiefe auf wichtigen Landing Pages, Interaktionen mit Pricing-Elementen, Chat-Initiierungen. Jedes dieser Events braucht einen klaren Namen, definierte Parameter und eine dokumentierte Bedeutung.

Google Analytics 4 arbeitet komplett eventbasiert. Das ist ein Paradigmenwechsel gegenüber Universal Analytics, den viele Unternehmen noch nicht vollständig verstanden haben. In GA4 ist jeder Datenpunkt ein Event — auch ein Seitenaufruf. Du kannst bis zu 25 benutzerdefinierte Parameter pro Event mitgeben und bis zu 50 benutzerdefinierte Dimensionen und Metriken anlegen. Das gibt dir enorme Flexibilität, aber nur, wenn du diese Architektur vor dem Launch planst.

Ein Punkt, der gerne unterschätzt wird: die Namenskonvention für Events. Wenn du deine Events nicht konsistent benennst, hast du in sechs Monaten ein Chaos aus „button_click“, „click_button“, „cta_click“ und „CTA_Click“, das niemand mehr auswerten kann. Definiere ein Schema: Verb-Objekt-Format, Kleinbuchstaben, Unterstriche als Trennzeichen. Zum Beispiel: „form_submit“, „pdf_download“, „video_play“, „cta_click“. Dokumentiere es. Halte dich dran. Klingt trivial, spart aber Stunden an Bereinigungsarbeit.

Die Wahl des Analytics-Tools ist keine technische Kleinigkeit, die man an die Entwickler delegiert. Es ist eine strategische Entscheidung mit Auswirkungen auf Datenschutz, Datenhoheit, Kosten und Auswertungsmöglichkeiten.

Google Analytics 4 ist der De-facto-Standard. Es ist kostenlos (in der Basisversion), hat eine riesige Community, integriert sich nahtlos mit Google Ads und bietet mit BigQuery-Export mächtige Analysemöglichkeiten. Aber: Deine Daten liegen bei Google. In den USA. Und die DSGVO-Konformität von GA4 ist — sagen wir mal — ein fortlaufendes Diskussionsthema. Die österreichische Datenschutzbehörde hat Google Analytics bereits für nicht DSGVO-konform erklärt. Ähnliche Entscheidungen anderer europäischer Behörden folgten.

Matomo ist die Alternative für Unternehmen, die Datenhoheit ernst nehmen. Self-hosted auf deiner eigenen Infrastruktur — bei uns typischerweise auf Hetzner mit Coolify und Docker — hast du volle Kontrolle über die Daten. Keine Drittanbieter, keine transatlantischen Datentransfers, keine Abhängigkeit von Googles Geschäftsmodell. Matomo kann in der self-hosted Variante sogar ohne Consent-Banner betrieben werden, wenn du es richtig konfigurierst: IP-Anonymisierung, keine Cookies, keine Drittanbieter-Requests. Das ist ein echter Vorteil, weil Consent-Banner nachweislich 20-40% der Nutzer vom Tracking ausschließen.

Die Entscheidung zwischen GA4 und Matomo hat direkte Auswirkungen auf die technische Implementierung. Unterschiedliche APIs, unterschiedliche Event-Modelle, unterschiedliche Integrationsmöglichkeiten. Wenn du diese Entscheidung nach dem Launch triffst, musst du unter Umständen erhebliche Teile des Tracking-Codes umschreiben.

Bei happycoding empfehlen wir für die meisten B2B-Projekte Matomo self-hosted als primäres Analytics-Tool. Die Gründe: volle DSGVO-Konformität ohne juristische Grauzone, kein Vendor Lock-in, Daten auf europäischen Servern, keine laufenden Lizenzkosten (in der Community Edition). Wenn ein Kunde zusätzlich Google Ads schaltet und die GA4-Integration für Kampagnen-Optimierung braucht, setzen wir GA4 parallel dazu ein — aber eben als Ergänzung, nicht als einzige Datenquelle.

Der Google Tag Manager ist ein mächtiges Werkzeug. Er erlaubt Marketing-Teams, Tracking-Pixel und Events zu verwalten, ohne dass Entwickler jedes Mal Code deployen müssen. Aber er hat eine fundamentale Schwäche: Er läuft im Browser des Nutzers. Und das bedeutet: Ad-Blocker können ihn blockieren. Consent-Ablehnung kann ihn deaktivieren. Browser-Privacy-Features können ihn einschränken.

Server-Side Tracking löst viele dieser Probleme. Statt im Browser des Nutzers zu laufen, werden Tracking-Daten vom Server gesendet. Das ist robuster, schneller (weil keine zusätzlichen JavaScript-Dateien im Browser geladen werden) und gibt dir mehr Kontrolle über die Daten, bevor sie an Analytics-Dienste weitergeleitet werden.

In einer Next.js-Architektur ist Server-Side Tracking besonders elegant umzusetzen. Du kannst API Routes oder Server Actions nutzen, um Events serverseitig zu erfassen und an Matomo oder GA4 weiterzuleiten. Der Vorteil: Die Tracking-Logik ist Teil deiner Applikation, nicht ein externes Script, das im Browser herumhängt. Du hast volle Kontrolle über Datenqualität und Datenhygiene.

Aber auch hier gilt: Diese Architekturentscheidung musst du vor dem Launch treffen. Ein nachträglicher Wechsel von clientseitigem zu serverseitigem Tracking ist ein signifikanter Umbau.

Cookie-Banner sind für die meisten Nutzer ein Ärgernis. Für Website-Betreiber sind sie ein Datenloch. Je nach Branche und Zielgruppe lehnen 30-60% der Nutzer nicht-essenzielle Cookies ab. Das bedeutet: Mit einem klassischen GA4-Setup, das einen Consent-Banner erfordert, verlierst du bis zur Hälfte deiner Daten. Du siehst nur das Verhalten der Nutzer, die aktiv auf „Alle akzeptieren“ geklickt haben — und diese Gruppe ist nicht repräsentativ.

Es gibt Strategien, damit umzugehen. Google bietet mit dem Consent Mode v2 eine Möglichkeit, auch bei abgelehntem Consent anonymisierte Daten zu erfassen und diese über Machine Learning zu modellieren. Das funktioniert, hat aber offensichtliche Limitationen — modellierte Daten sind eben keine echten Daten.

Die saubere Alternative: Ein Analytics-Tool, das keinen Consent-Banner braucht. Matomo self-hosted, korrekt konfiguriert, kann genau das. Keine Cookies, vollständige IP-Anonymisierung, alle Daten auf deinem eigenen Server. Damit erfasst du 100% deiner Besucher, nicht nur die, die deinem Banner zugestimmt haben. Für B2B-Websites, wo jeder einzelne Besucher potenziell ein hochpreisiger Lead ist, macht das einen riesigen Unterschied.

Die Consent-Management-Strategie beeinflusst deine Tracking-Architektur grundlegend. Welches Consent-Tool du einsetzt (Cookiebot, Usercentrics, eine Custom-Lösung), wie du es in dein Tag-Management integrierst, welche Tracking-Technologien du an welchen Consent-Status koppelst — all das muss vor dem Launch stehen. Ein nachträglicher Einbau führt fast immer zu Dateninkonsistenzen und Compliance-Risiken.

Ich will das nochmal deutlich machen, weil es der Kern des Problems ist. Tracking nachträglich einzubauen ist nicht einfach „spät, aber okay“. Es hat konkrete, messbare Nachteile.

Erstens: Du verlierst Daten. Jeder Tag ohne Tracking ist ein Tag, an dem du keine Daten sammelst. Du kannst sie nicht nachträglich generieren. Wenn du drei Monate nach dem Launch dein Tracking einrichtest, fehlen dir drei Monate Baseline-Daten. Du kannst keine Vorher-Nachher-Vergleiche machen. Du kannst keine Trends identifizieren. Du fliegst blind.

Zweitens: Die technische Implementierung wird teurer. Tracking-Code in eine bestehende Applikation einzubauen bedeutet, existierenden Code anzufassen. Das erfordert Verständnis der bestehenden Architektur, Testing, potenzielle Regression. In einer Next.js-App mit Server Components, Client Components und verschiedenen Rendering-Strategien ist das kein Trivialfall.

Drittens: Du optimierst deine Website im Blindflug. Ohne Tracking-Daten triffst du Design- und Content-Entscheidungen auf Basis von Bauchgefühl statt auf Basis von Nutzerdaten. Welche Landing Pages funktionieren? Wo springen Nutzer ab? Welche CTAs konvertieren? Ohne Tracking weißt du es nicht. Du rätst. Und Raten ist keine Strategie.

Viertens: Die Datenqualität leidet. Nachträgliches Tracking wird oft hastig implementiert. Events werden inkonsistent benannt, Parameter fehlen, die Dokumentation ist lückenhaft. Sechs Monate später versteht niemand mehr, was „event_action_3“ bedeuten sollte. Und dann fängt man von vorne an.

Ein Measurement Plan ist ein Dokument, das die Brücke zwischen Geschäftszielen und technischer Tracking-Implementierung schlägt. Er beantwortet drei Fragen: Was wollen wir wissen? Wie messen wir es? Und wie setzen wir die Messung technisch um?

Ein guter Measurement Plan hat typischerweise fünf Ebenen. Ganz oben stehen die Geschäftsziele: Lead-Generierung steigern, Markenbekanntheit erhöhen, Self-Service-Quote verbessern. Darunter die KPIs, die diese Ziele messbar machen: Anzahl qualifizierter Leads, Newsletter-Abonnenten, Support-Ticket-Reduktion. Dann die konkreten Metriken: Conversion Rate, durchschnittliche Session-Dauer auf Produktseiten, Download-Zahlen. Darunter die Events und Dimensionen, die du tracken musst, um diese Metriken zu berechnen. Und ganz unten die technische Implementierung: Welcher Code feuert welches Event, mit welchen Parametern, an welchem Punkt in der User Journey?

Dieses Dokument entsteht in Zusammenarbeit zwischen Business-Stakeholdern, Marketing und Entwicklung. Es ist kein reines IT-Thema und kein reines Marketing-Thema. Es ist ein Geschäftsthema. Und es muss stehen, bevor die erste Zeile Tracking-Code geschrieben wird.

Für B2B-Unternehmen ist die Website nur ein Touchpoint in einer langen Customer Journey. Der eigentliche Wert entsteht, wenn du Website-Daten mit deinem CRM verknüpfen kannst. Wenn du siehst, dass Lead X, der gerade einen 50.000-Euro-Deal abgeschlossen hat, vor sechs Monaten über einen bestimmten Blog-Artikel auf deine Website gekommen ist, drei Whitepaper heruntergeladen hat und dann über die Pricing-Seite ein Kontaktformular ausgefüllt hat — dann verstehst du, welcher Content wirklich Umsatz treibt.

Diese Verknüpfung ist technisch anspruchsvoll, aber machbar. Du brauchst eine User-Identifikation, die über die Website hinaus funktioniert — typischerweise über eine E-Mail-Adresse, die bei der Formular-Submission erfasst wird. Diese ID verbindet den anonymen Website-Besucher mit dem Lead in deinem CRM. Tools wie Supabase können als Zwischenschicht fungieren, um Website-Events mit CRM-Daten zu korrelieren, bevor sie an ein Reporting-Tool weitergeleitet werden.

Aber auch hier: Diese Integration muss von Anfang an mitgedacht werden. Welche Daten fließen vom Website-Tracking ins CRM? Welche Felder im CRM werden befüllt? Wie sieht der Datenfluss technisch aus? API-Calls, Webhooks, Batch-Imports? Diese Fragen in der Planungsphase zu klären, spart Wochen an nachträglicher Integrationsarbeit.

Tracking-Daten sind nur dann wertvoll, wenn sie tatsächlich angeschaut werden. Und hier liegt ein weiteres Problem vieler Unternehmen: Sie haben Daten, aber niemand schaut regelmäßig rein. Das Google-Analytics-Dashboard wird einmal im Quartal geöffnet, wenn der Vorstand nach Zahlen fragt. Den Rest der Zeit verstaubt es.

Die Lösung: Automatisiertes Reporting. Statt darauf zu warten, dass jemand sich in ein Analytics-Tool einloggt, schickst du die relevanten Zahlen proaktiv an die richtigen Leute. Und genau hier kommt n8n ins Spiel.

n8n ist ein self-hosted Workflow-Automation-Tool, das wir bei happycoding für genau solche Aufgaben einsetzen. Du kannst Workflows bauen, die morgens automatisch die wichtigsten KPIs aus Matomo oder GA4 ziehen, sie aufbereiten und als Slack-Nachricht, E-Mail oder Dashboard-Update an das Team senden. Kein manuelles Einloggen, kein Export, keine PowerPoint-Slides. Die Daten kommen zu dir, nicht du zu den Daten.

Ein typischer n8n-Workflow für ein B2B-Reporting sieht so aus: Jeden Montag um 8 Uhr zieht n8n die Vorwochendaten aus Matomo. Besucher, Conversions, Top-Landing-Pages, Conversion Rate nach Kanal. Er vergleicht die Zahlen mit der Vorwoche, berechnet prozentuale Veränderungen und formatiert alles in einer Slack-Nachricht mit grünen und roten Pfeilen. Das Marketing-Team hat seine Zahlen, bevor der erste Kaffee fertig ist.

Der Vorteil von n8n gegenüber Cloud-Lösungen wie Zapier: Es läuft auf deiner eigenen Infrastruktur. Keine Daten, die an Drittanbieter fließen. Keine monatlichen SaaS-Kosten, die mit dem Datenvolumen skalieren. Self-hosted auf Hetzner mit Coolify, genau wie der Rest des Stacks. Kein Vendor Lock-in.

Noch wertvoller als regelmäßige Reports sind Echtzeit-Alerts. n8n kann nicht nur periodische Reports generieren, sondern auch auf Anomalien reagieren. Conversion Rate bricht plötzlich ein? Sofortige Benachrichtigung. Ein bestimmter Blog-Artikel geht viral? Du erfährst es, bevor es in der Kaffeepause Thema wird. Formular-Submissions stoppen komplett? Alarm, bevor du drei Tage lang Leads verlierst, weil ein JavaScript-Fehler das Kontaktformular lahmlegt.

Diese Art von proaktivem Monitoring ist nur möglich, wenn das Tracking-Setup von Anfang an sauber aufgesetzt ist. Wenn deine Events konsistent benannt sind, wenn deine KPIs klar definiert sind und wenn die technische Infrastruktur steht, die Daten in Echtzeit verarbeiten kann.

Wenn Tracking so wichtig ist, warum machen es dann so wenige? Ich sehe drei Hauptgründe.

Der erste: Tracking ist unsexy. In einem Website-Projekt kämpfen Design, Content und Features um Budget und Aufmerksamkeit. Tracking kommt als letzter Punkt auf die Liste, wenn das Budget schon verbraucht und die Deadline überschritten ist. Es gibt kein Stakeholder-Meeting, in dem jemand sagt: „Wow, dieser Measurement Plan ist fantastisch.“ Tracking-Arbeit ist unsichtbar — bis sie fehlt.

Der zweite: Fehlendes Know-how auf Agenturseite. Viele klassische Webagenturen können Design und Entwicklung, aber haben keine Tracking-Expertise. Sie installieren GA4, setzen einen Cookie-Banner und haken „Analytics“ auf ihrer Checkliste ab. Ein echtes Tracking-Konzept mit Measurement Plan, Event-Architektur und CRM-Integration übersteigt ihre Kompetenz. Und was man nicht kann, bietet man nicht an.

Der dritte: Die Konsequenzen kommen verzögert. Ein fehlendes Tracking-Setup tut am Launch-Day nicht weh. Die Website sieht gut aus, sie lädt schnell, die Inhalte stimmen. Erst Monate später, wenn die erste ROI-Diskussion kommt, fällt auf, dass man nichts messen kann. Und dann ist es zu spät für einen sauberen Start — du hast bereits Monate an Daten verloren.

Wenn du den einen Punkt aus diesem Artikel mitnimmst, dann diesen: Tracking ist kein Marketing-Feature. Es ist Teil der technischen Architektur deiner Website. So wie du Authentifizierung, API-Design oder Datenbank-Schema in der Planungsphase definierst, gehört auch das Tracking-Setup in diese Phase.

Bei happycoding haben wir einen Tracking-Workshop als festen Bestandteil unserer Projekt-Kickoffs etabliert. In diesem Workshop definieren wir gemeinsam mit dem Kunden Geschäftsziele, leiten KPIs ab, entscheiden über die Tool-Landschaft (Matomo, GA4, oder beides), planen die Event-Architektur und dokumentieren alles in einem Measurement Plan. Das dauert einen halben Tag. Es kostet einen Bruchteil des Gesamt-Budgets. Und es spart Wochen an nachträglicher Arbeit und Monate an verlorenen Daten.

Die Frage ist nicht, ob du dir ein Tracking-Setup leisten kannst. Die Frage ist, ob du es dir leisten kannst, ohne eines zu launchen. Und die Antwort ist ziemlich eindeutig: Nein.

Wenn du ein Website-Projekt planst und sicherstellen willst, dass das Tracking von Tag eins an funktioniert — nicht als Nachgedanke, sondern als integraler Bestandteil der Architektur — dann sprich uns an. Wir bauen keine Websites, die gut aussehen und sich dann nicht messen lassen. Wir bauen Websites, die funktionieren. Und funktionieren heißt: messbar Ergebnisse liefern.