Definieren Sie stabile Events anhand bedeutender Aktionen und Ergebnisse und erstellen Sie für jedes ein Parameterschema, eine maßgebliche Datenquelle, Datenschutzregeln, eine Version und einen automatisierten QA-Test.
Die Datenschicht trennt die Bedeutung eines Geschäftsereignisses vom konkreten HTML-Selektor und vom Analysetool. Statt jeden Klick auf eine Button-Klasse zu verfolgen, kann die Anwendung melden, dass der Benutzer eine Anfrage gesendet, ein Paket ausgewählt oder einen Schritt abgeschlossen hat. Ändert sich das Design, bleibt die Bedeutung stabil, und Integrationen müssen den Zustand nicht aus der Bildschirmanzeige erraten.
Dieser Vorteil entsteht nur bei einem vereinbarten Kontrakt. Inkonsistente Namen, Freitexte, personenbezogene Daten und Ereignisse, die vor der Bestätigung des Ergebnisses ausgelöst werden, erzeugen nicht vergleichbare Reports. Der Entwurf muss auf einem Messplan beruhen, die Nutzeraktion vom serverseitigen Ergebnis unterscheiden und festlegen, wer neue Events und deren Versionen freigibt.
Ein Event benennt ein Ereignis in der Domäne, kein visuelles Element
Der Name sollte das Objekt und die abgeschlossene Aktion ausdrücken, zum Beispiel den Beginn einer Reservierung oder die Bestätigung einer Bestellung. „Klick_blauer_Button“ verliert bei einem Redesign seine Gültigkeit und sagt nicht aus, was der Klick bedeutete. Unterscheiden Sie Versuch, Erfolg, Fehlschlag und Abbruch, sofern dies für Entscheidungen erforderlich ist. Melden Sie keinen Erfolg, bevor das maßgebliche System geantwortet hat.
Legen Sie eine Konvention für Kleinschreibung, Trennzeichen, Zeitform und Verbform fest. Verwenden Sie keine Synonyme für dasselbe Ereignis und keinen gleichen Namen für unterschiedliche Prozesse. Das Datenwörterbuch sollte Beschreibung, Auslösebedingung, Verantwortlichen und Abnehmer angeben. Ein neuer Name wird vor der Implementierung genehmigt, nicht erst, nachdem er in einem Report auftaucht.
- ein Domain-Ereignis und ein klarer Zeitpunkt
- Unterschied zwischen Versuch und bestätigtem Ergebnis
- konsistenter Name ohne Bindung an CSS
- Verantwortlicher der Definition und Liste der Konsumenten
Parameter ergänzen den Kontext, ohne Tausende von Namen zu erzeugen
Senden Sie Dienst, Schritt, Variante, Fehler oder Platzierung als definierten Parameter, sofern sie das Wesen des Ereignisses nicht verändern. Jeder Parameter benötigt einen Typ, zulässige Werte, eine Angabe zur Pflicht und ein Beispiel. Freitext erzeugt schnell Schreibvarianten, hohe Kardinalität und das Risiko personenbezogener Daten. Bevorzugen Sie kontrollierte Kennungen und Mappings.
Senden Sie keinen Parameter, nur weil er in der Komponente verfügbar ist. Bewerten Sie, welche Entscheidung er unterstützt und welche Verarbeitungskosten entstehen. Eine Produktkennung kann geeignet sein, die E-Mail-Adresse des Kunden nicht. Geben Sie beim Preis die Währung und die Bedeutung des Werts an; verwenden Sie bei einem Fehler einen sicheren Kategoriecode, nicht den vollständigen Servertext oder eingegebene Inhalte.
- Typ und zulässige Werte des Parameters
- Pflichtangabe und Verhalten bei fehlendem Wert
- Einheit, Währung und zeitlicher Kontext
- Verbot personenbezogener Daten und freier Eingaben
Die Datenschicht ist ein versionierter Vertrag der Anwendung
Definieren Sie das Event-Objekt unabhängig von einem bestimmten Analytics-Anbieter. Die Anwendung veröffentlicht freigegebene Daten, und das Tagging-System ordnet sie den Zielplattformen zu. Erstellen Sie keine parallelen Selektoren, die dieselbe Bedeutung erneut aus dem DOM ableiten. Bei serverseitigen Ergebnissen sollten Sie ein sicheres serverseitiges Event oder einen bestätigten Client-Zustand in Betracht ziehen.
Speichern Sie das Schema in einem versionierten Repository mit Änderungshistorie und Tests. Das kompatible Hinzufügen eines optionalen Parameters ist eine andere Änderung als das Umbenennen eines Pflichtfelds. Bei einer inkompatiblen Anpassung sehen Sie eine Übergangsphase oder eine neue Version vor. Nutzer der Schnittstelle benötigen einen Termin, Dokumentation und die Möglichkeit, das Mapping vor der Produktion zu testen.
Einwilligung und Datenminimierung greifen vor dem Absenden
Gliedern Sie Events nach ihrem Zweck und legen Sie auf Grundlage einer fachkundigen rechtlichen und technischen Prüfung fest, welche bei den einzelnen Einwilligungsstatus verarbeitet werden dürfen. Die Datenschicht selbst darf kein verdeckter Speicher für personenbezogene Daten sein. Ein im Browser abgelegter Wert kann für Skripte und Tools zugänglich sein, auch wenn er nicht weitergesendet wurde.
Untersagen Sie E-Mail-Adressen, Telefonnummern, vollständige Namen, Freitextnachrichten, Tokens und interne Geheimnisse in Events. Ist eine Verknüpfung mit dem serverseitigen Ergebnis erforderlich, verwenden Sie eine angemessene pseudonyme Kennung mit kontrolliertem Lebenszyklus und Zugriffsrechten. Pseudonymisierung ist keine Anonymisierung und hebt die Datenschutzpflichten nicht von selbst auf.
- Zweck des Events und erforderlicher Einwilligungsstatus
- minimaler Parameterumfang für die Entscheidung
- sichere Kennung mit begrenzter Gültigkeitsdauer
- Keine Secrets oder personenbezogenen Freitexte
Die QA prüft Anzahl, Reihenfolge und Inhalt der Events
Prüfen Sie in der Testumgebung Erfolg, Fehler, Rücksprung, Doppelklick, Neuladen, mehrere Tabs und verschiedene Einwilligungszustände. Stellen Sie sicher, dass das Ereignis genau einmal, zum richtigen Zeitpunkt und mit den erforderlichen Parametern eintrifft. Vergleichen Sie das clientseitige Event an einer kontrollierten Stichprobe mit dem serverseitigen Ergebnis, ohne echte sensible Daten zu verwenden.
Ein automatisierter Test kann bei jedem Release das Schema und unzulässige Felder validieren. Das Monitoring überwacht plötzliche Rückgänge, Anstiege, neue Werte und Vertragsverletzungen. Annotieren Sie Vorfälle in den Reports und korrigieren Sie die historische Interpretation. Prüfen Sie nach dem Entfernen eines Events Dashboards, Zielgruppen und Integrationen, die es möglicherweise weiterverwendet haben.
Häufige Fragen
Sollte ein Event jeden Klick erfassen?
Nein. Erfassen Sie Aktionen und Ergebnisse, die für eine Entscheidung oder Diagnose nötig sind. Massenhaftes Sammeln von Klicks erhöht Rauschen, Kosten und Risiko ohne klaren Nutzen.
Ist der dataLayer nur an den Google Tag Manager gebunden?
Eine konkrete Implementierung kann diesen Namen verwenden, das Prinzip ist jedoch allgemein: Die Anwendung veröffentlicht einen stabilen Vertrag, der auf verschiedene Konsumenten abgebildet wird.
Dürfen wir eine E-Mail-Adresse als Kennung in ein Event senden?
In der Regel nicht in die Analyseebene. Personenbezogene Daten erfordern einen gesonderten Zweck, eine Berechtigung und ein sicheres Design; verwenden Sie nach fachlicher Prüfung einen minimalen, kontrollierten Identifikator.