Blog · Governance
Dokumentation und Data Contracts: wer was liefert
Ein Tracking-Setup ist nur so gut wie das Wissen darüber, warum jeder Parameter existiert. Ohne Dokumentation wird jede Änderung zum Risiko, und jede Übergabe beginnt bei null.
Implementierung ist eine Hypothese
Ein Ticket sagt meist „feuert, wenn X passiert“. Es sagt nicht, ob der Wert stimmt. In einem Audit sah die Event-Abdeckung auf dem Papier vollständig aus. Ob der Umsatz im purchase-Event dem Umsatz im Shop-System entsprach, hatte niemand geprüft. Ich teste deshalb in drei Stufen:
- Technisch: Das Event feuert, einmal, zum richtigen Zeitpunkt.
- Inhaltlich: Die Werte sind korrekt und vollständig, Typen stimmen.
- Abgleich: Summen passen zum Backend. Nicht auf den Cent, aber mit stabiler Abweichung über die Zeit.
Vier Dokumente, die sich bewährt haben
| Dokument | Inhalt | Wer pflegt es |
|---|---|---|
| Tracking-Dokumentation | Zweck, Architekturbild, Komponenten mit Ansprechpartnern, Partner und ob sie client- oder server-side laufen | Tracking |
| Event-Matrix | Jedes Event mit Quelle (Theme, Pixel, Backend) und welche Plattform es erhält | Tracking, mit Marketing abgestimmt |
| Parameter-Log | Jeder Parameter: Herkunft, Ist und Soll, Maßnahme, Begründung, „genutzt im DWH?“ mit Antwort des Data-Teams | Tracking und Data gemeinsam |
| Vorfallberichte | Zeitachse, Ursache, Auswirkung, Behebung, Lehren | Wer den Fix deployt |
Das Parameter-Log ist das unterschätzteste der vier. Es beantwortet die Frage, die bei jedem Aufräumen kommt: „Kann das weg?“ Und es hält fest, wer „ja“ gesagt hat. Ein Beispiel, warum das wichtig ist, steht im Beitrag zu GA4 als Transportschicht.
Zwei Gewohnheiten ergänzen das: Code außerhalb von GTM, etwa ein Shopify-Pixel, liegt in Git. Und Repositories gehören dem Kunden, nicht dem Dienstleister. Ich plane die Übergabe von Anfang an ein.
Data Contract light
Ein formaler Data Contract schreckt Teams oft ab. Ich starte mit einer Tabelle pro Event:
| Feld | Beispiel add_to_cart |
|---|---|
| Event-Name | add_to_cart |
| Auslöser | Artikel wurde erfolgreich in den Warenkorb gelegt (nach Server-Antwort) |
| Pflichtfelder | currency, value, items[].item_id, items[].quantity, items[].price |
| Optionale Felder | items[].item_list_name, items[].index |
| Typen | value als Zahl, ohne Währungszeichen |
| Quelle | Frontend |
| Verantwortlich | Storefront-Team |
Wenn diese Tabelle steht, hat Engineering eine Spezifikation und Tracking einen Testfall.
Was Engineering idealerweise vorbereitet
- Eine zentrale Tracking-Schicht. Ein Modul, über das alle Events laufen, mit Consent-Prüfung und einheitlichem Mapping. Keine
dataLayer.push-Aufrufe verstreut über Komponenten. - E-Commerce-Objekt zurücksetzen. Vor jedem E-Commerce-Event
ecommerce: nullpushen, damit keine Artikel aus dem vorherigen Event nachwirken. - Events am Geschäftsprozess, nicht am Rendering.
purchasefeuert, wenn die Bestellung angelegt ist, nicht wenn die Danke-Seite lädt. Sonst zählt jedes Neuladen doppelt. - Seitenaufrufe an genau einer Stelle. In Single-Page-Apps können GA4-Einstellungen, Google-Ads-Tag und GTM jeweils eigene
page_viewauslösen. Eine Stelle entscheidet. - Werte wie im Backend definiert. Umsatz mit oder ohne Steuer und Versand, Rabatte positiv oder negativ: Das legt nicht das Frontend fest, sondern Finance.
- Eine stabile Kunden-ID. Und eine Antwort darauf, wie ein anonymer Besuch nach Login oder Kauf mit dem Kunden verbunden wird.
- Vorsicht mit zwischengespeicherten Events. Events vor der Einwilligung zu puffern und später zu senden, ist technisch elegant. Zeitstempel und Session-Zuordnung verschieben sich dabei aber. Das muss die Auswertung wissen.
Der Prozess dahinter
Tracking-Änderungen sind Code-Änderungen. Sie bekommen ein Ticket, einen Test in Preview oder Staging und eine Nachricht an Marketing und Data vor dem Release. Das klingt bürokratisch. Es ist billiger als ein Vorfallbericht.