Keine „Schlechten“ Daten!

Neulich habe ich bei einem Kunden einen weiteren Grund gesehen, warum man eine Webanalyseimplementierung stutzen muß, und zwar permanent, oder zumindest zur passenden Jahreszeit.

Ich beschreibe erstmal die Situation.

Wir wollten analysieren, ob das Videotracking in einer App optimal ist und sahen uns daher einige Reports an. Dabei kamen Zahlen zum Vorschein, die sich niemand so wirklich im Detail erklären konnte, also sahen wir uns den Code der Apps für Android und iOS an. Siehe da: Es gab Unterschiede.

Ein Report, der aufgrund von Diskrepanzen bei der Implementierung Daten zeigt, die man sich als Benutzer nicht erklären kann. Gift!

Die Entwickler gaben zu bedenken, daß dieser Report vermutlich nicht so wichtig sei. Da hake ich natürlich nach! Simplify! Unnötiges entfernen! Immer gut! Allerdings ist der Konsens, daß die Daten drinbleiben müssen, weil es sein könnte, daß irgendwann jemand genau nach diesen Daten fragt.

Ich kann das Argument verstehen, merke jedoch an, daß im Fall der Fälle die Daten zwar zur Verfügung zu stehen scheinen, es aber praktisch nicht tun, denn was zur Zeit getrackt wird ist nur nach manueller Intervention brauchbar.

Das finde ich so gefährlich, daß es einen Artikel ganz für sich alleine wert ist: Kaputte Daten sind schlimmer als keine Daten!

Ich bin ja ein Freund der starken Aussage, und vielleicht sollte ich das einerseits untermauern und andererseits auch ein wenig abmildern.

Anklage

Falsche Daten sollten entfernt werden!

Erstens besteht die Gefahr, daß nicht alle Benutzer wissen, daß die Daten falsch sind. Daraus ergeben sich im besten Fall Mißverständnisse und Zeitverschwendung, im schlimmsten Fall falsche Entscheidungen aufgrund der Daten.

Wir Webanalysten, Entwickler und Marketers haben eine Verantwortung: Wir müssen dafür sorgen, daß die Daten stimmen. Und zwar wirklich stimmen.

Warum wir?

Weil wir tendenziell die einzigen im Unternehmen sind, die auch nur ansatzweise verstehen, was da eigentlich so alles passiert. Manchmal wissen nicht einmal wir Bescheid, zumindest nicht über das komplette Deployment.

Daß wir in einem solchen Fall (und eigentlich immer!) auf Vereinfachung drängen sollten (Nein sagen!) habe ich schon einige Male erwähnt.

Wenn niemand im Betrieb einen Bestandteil des Trackings erklären kann, dann gibt es keinen Grund, diesen Teil beizubehalten. Dann muß der weg. Wie sonst soll man beurteilen, ob die Daten korrekt sind? Wenn niemand weiß, was die Daten sind, dann kann auch niemand garantieren, daß sie gut sind.

Zweitens erzeugen falsche Daten ein Gefühl von Sicherheit.

Angenommen meine Haustür hätte kein Schloß. Ich wüßte sofort, daß ich etwas tun muß: Das Schloß reparieren oder eins einbauen.

Was aber wenn die Tür durchaus ein Schloß hat, das aber kaputt ist und sich mit einem Fingernagel öffnen läßt?

Das ist gefährlich, weil ich das eventuell gar nicht weiß! Für mich ist da ein Schloß, es funktioniert mit meinem Schlüssel, alles ist gut.

Diese Gefahr gibt es auch bei Daten!

Mein Chef fragt mich nach einer Analyse, weil er am Montag seinem Chef berichten muß. Ich sage forsch „klar Chef!“ und finde mich dann am Sonntag in einer verzweifelten Situation wieder, in der ich die Daten gar nicht habe, bzw. eingestehen muß, daß die Qualität der Daten keine soliden Resultate zuläßt.

In diese Situation sollte man sich nicht bringen! Das muß einfach nicht sein!

Daher sollten Daten von fragwürdiger Qualität lieber entfernt (oder meinetwegen versteckt) werden, bevor irgendjemand meint, daraus könne man Erkenntnisse ableiten.

Vorgehen

Es gibt ein paar verschiedene Ansatzpunkte:

1. Scheduled Reports abschalten
2. Menü anpassen
3. Processing Rules anpassen
4. Tracking anpassen

Die Reihenfolge ist in etwa von „weniger Aufwand und Risiko“ hin zu „mehr Aufwand und Risiko“. Und sie geht von „unbedingt sofort tun“ bis nach „sollten wir machen sobald möglich“.

Fangen wir mal oben an: Wer regelmässig Reports verschickt, in denen dubiose Daten vorkommen, kann diese einfach stoppen. Theoretisch sollten keine Beschwerden kommen, denn es kann ja eigentlich nicht sein, daß niemandem aufgefallen ist daß die Daten falsch sind.

Falls es doch einen Aufschrei gibt, kann man die Reports einfach wieder versenden, genau wie vorher. Es hat sich ja sonst nichts geändert. Man hat dann auch einen guten Aufhänger für eine Diskussion über die Qualität der Daten. Und kann Druck machen, sie zu reparieren, weil jemand sie wirklich benötigt!

An zweiter Stelle (aber eigentlich parallel): Man sollte Reports mit fragwürdigen Daten nicht zeigen. Dann ist die Gefahr insofern gebannt, als daß zumindest niemand diese Daten benutzt.

Man kann Reports relativ einfach mit dem Menüeditor verstecken, ohne daß man an der Sammlung der Daten etwas ändern müßte. Auch hier wieder der Vorteil: Wenn jemand die Daten wirklich braucht, kann man einfach den Menüeintrag wieder sichtbar machen, die Daten sind ja nachwievor da.

Nachteile dieser Lösung: Irgendwann sind keine Variablen mehr frei, weil die versteckten Altlasten immer noch Daten sammeln. Und die Implementierung wird auch immer komplexer, bis niemand mehr weiß, welche Variablen korrekt sind und welche nicht.

Platz 3: Wer Context Data und Processing Rules nutzt, der kann ohne Änderungen an der eigentlichen Implementierung einfach die Zuweisung von Context Data an Variablen unterbrechen.

Das ist dann gut, wenn man z.B. Apps trackt oder Sites mit langem Deploymentzyklus.

Die Daten werden zwar nachwievor zu den Servern bei Adobe gesendet, dort aber nicht kopiert sondern verworfen.

Vorsicht! Wenn man Processing Rules ändert oder streicht, modifiziert man das Tracking! Die falschen Daten werden dann nicht mehr gesammelt! Nirgendwo!

Ich sage das hier nur nochmal, weil das ein grober Eingriff ist. In diesem Fall ist es natürlich ein guter Eingriff. Man sollte sich nur vorher irgendwo „weiter oben“ ein Ok holen.

Platz 4, der tiefste und umfassendste Eingriff: Änderung des Trackings.

Bei falschen Daten gibt es zwei Möglichkeiten: Reparieren oder nicht mehr tracken.

Wir haben schon eine ganz gute Lösung für nicht mehr tracken gesehen: Processing Rules anpassen. Wenn man aber keine Processing Rules nutzt, oder wenn man die Daten wirklich nicht mehr will und auch den Code (s_code.js oder Code auf den Seiten) vereinfachen, dann sollte man das Tracking entfernen, sozusagen an der Quelle.

Je nach Entwicklungszyklus kann das dauern, und es dauert natürlich genau so lange, das Tracking wieder einzubauen, falls es doch wieder nötig sein sollte.

Wer den Fehler reparieren möchte, ist hier klar an der richtigen Stelle. Fehler sollte man immer an der Quelle ausmerzen, andernfalls erhöht man nur die Komplexität und Undurchschaubarkeit des Deployments.

Wann soll man den Fehler reparieren versus das Tracking entfernen?

Wenn die Daten wichtig sind, natürlich (Aber seit wann besteht der Fehler? Warum wurde er nicht eher entdeckt? Sind sie wirklich wichtig?). Wenn die Daten klar und einfach genug sind, daß sie die Komplexität nicht nennenswert erhöhen, vielleicht. Wenn niemand das Entfernen abzeichnet.

Verteidigung

Und was hat die Verteidigung zu sagen?

Nicht viel, nur dies: falsche Daten sind in den Händen eines guten Analysten manchmal brauchbar, nämlich dann wenn eine manuelle Analyse angefragt wird und die Daten noch genug Anhaltspunkte liefern.

Das gilt natürlich nur dann, wenn die falschen Daten nicht zu sehr verwurstet sind. Beispiel: Wenn zwei Seiten auf der Website den gleichen s.pageName senden, sich aber anhand anderer Daten unterscheiden lassen, dann kann man das manuell eben noch retten.

Wichtig ist, daß Endnutzer nicht die Rohdaten geliefert bekommen sondern nur die Ergebnisse der manuellen Analyse.

Eigentlich ist das aber sowieso immer besser ☺