Back to the Basics – Vorbereitung

Ich möchte heute mal ein Thema anreißen, das nur selten rechtzeitig besprochen wird: Die Vorbereitung.

Das Thema passt hervorragend in die „Back to Basics“ Serie, denn die angesprochenen Vorbereitungen machen in vielen Fällen genau den Unterschied zwischen „viel Geld ausgeben“, „Wow, DAS ist interessant!“ und „Dank Analytics haben wir im letzten Jahr unser Geschäft ver-x-facht“.

Also los.

Benutzeridentifikation

Das Wort allein ist schon kompliziert. Ich habe mich gerade zweimal verschrieben.

Die Problematik ist folgende: Man gibt Geld für’s Marketing und für die Acquise von Benutzern aus. Dafür möchte man sehen, was hinten heraus kommt, ob man also das Geld sinnvoll angelegt hat oder nicht.

Als Marketer muß ich nicht wissen, ob Herr Mustermann aus Kutenholz meine Email geöffnet hat, aber ich will verfolgen können, ob ein Besucher der heute gekauft/subscribed/konvertiert hat/ist, irgendwann vorher einen oder mehrere berührungspunkte mit meinen Marketingkampagnen hatte. Nur so kann ich abschätzen, ob ich mein Geld an der richtigen Stelle ausgebe.

Das kann schwierig sein.

Erstens benutzen praktisch alle Webanalysetools Cookies, um über die Zeit hinweg Besucheraktionen zu verknüpfen, und Benutzer torpedieren das und löschen Cookies. Zweitens haben die wenigsten Benutzer heutzutage nur ein Fenster zu uns, zumindest in Europa. Laptop bei der Arbeit, PC zuhause, Tablet, Taschentelefon — sie alle werden benutzt, gerne im schnellen Wechsel. Drittens interagieren Benutzer nicht nur mit Websites sondern auch mit Apps, Callcenters und in „richtigen“ Läden.

Durch die Vielfalt an Interaktionen und Gerät kann die Verknüpfung zwischen Marketingmaßnahme und Konversion komplett verloren gehen.

Das Problem hat zwei Aspekte:

1. Idee — man muß Wege finden, Benutzer an den unterschiedlichsten Stellen im Prozeß zu identifizieren. Das könnte bedeuten, vor Downloads nach Emailadressen zu fragen, oder beim Start der App nach einem Login. Oder es könnte bedeuten, Cookies sinnvoll zwischen Websites zu transportieren. Oder eine ganz andere Lösung. Hier sind die Techniker und Webentwickler gefragt. Die Identifizierung darf gerne anonym sein!
2. Integration — eine Lösung wird zwangsläufig verschiedene IDs aus verschiedenen Datenquellen auf eine zentrale „unique ID“ mappen. Das sollte selbstverständlich automatisiert und möglichst in Echtzeit geschehen. Man benötigt dazu also jede Menge Integration; Exports von Daten, ETL, Imports. Manche dieser Daten kommen aus Systemen, die mit der Webanalyse rein gar nichts zu tun haben, und die meisten Daten sind unter IT Kontrolle. Solche Projekte sind naturgemäß zeitaufwändig und schwierig zu motivieren.

Leider gibt es für beide Probleme keine Patentlösung. Zu unterschiedlich sind die Besucher der Websites, und zu inhomogen die internen Systeme der meisten Kunden.

Wer über Webanalyse nachdenkt, sollte sich aber unbedingt auch über diese beiden Aspekte Gedanken machen! Letzterer kann sicher irgendwann mithilfe besserer Tools seitens der Anbieter gelöst werden, aber ersterer wird immer unter alleiniger Kontrolle der Kunden sein.

Das Problem ist nicht einfach zu lösen, aber wer es löst, auf den wartet eine hohe Belohnung: Customer Analytics, wie unsere Evangelists es nennen, also kundenzentrierte Analyse. Und eine gute Antwort auf die Frage, ob der Marketingetat erfolgreich ist oder nicht.

Agilität & ROI

Im Grunde habe ich dieses Thema schon in Analytics und ROI beschrieben: Wer sinnvoll Webanalyse treiben will, der muß über’s Reporting hinauswachsen. Wer Analysen durchführt und interessante Ergebnisse erzielt, der will die dann hoffentlich auch umsetzen.

Und genau das scheint ebenfalls ein spezifisches Problem in Deutschland zu sein: Agilität, oder der Wille, aufgrund von Analysen auch mal etwas zu verändern.

Mich ärgert das. Wie oft höre ich Kunden sagen „Ich weiß, unsere Website könnte besser sein, aber …“ Ja dann macht halt!

Wenn eine Website gelinde gesagt schlecht ist, und meine Webanalyse mir sagt, was auf ihr so alles nicht oder nur schlecht funktioniert, dann sollte doch bitte der nächste Schritt sein, die faulen Stellen wegzuwerfen oder zu verbessern!

Hier fehlt oft die absolute Grundlage: Wille zur Veränderung.

Das geht weiter als nur Releasezyklen! Ich habe schon Situationen erlebt, wo Kunden ganz offen gesagt haben, das ein bestimmter Aspekt der Site geändert werden muß, „aber erstmal setzen wir das Reporting richtig auf.“

Meine Meinung: Webanalyse in solchen Fällen weglassen. Was soll ich mich mit Implementierung, Reports, Analysen, Zahlen, Präsentationen, Meetings und Emails herumschlagen, wenn es keine Chance gibt auf irgendein Resultat? Und wenn Verbesserungen so offensichtlich sind, daß man sie ohne Webanalyse sehen kann, dann sollte man sie bitte zuerst machen!

Ist doch wahr.

Das Problem dürfte in den meisten dieser Fälle sein, wer wo die Prioritäten festlegt, und welche Teams in der Folge welche Kompetenzen haben. Anders gesagt: Marketing oder die Webanalysten können gar nicht viel machen.

Doch! Das Problem darlegen! Die Entscheidung anfechten! Irgendwer irgendwo sitzt hoch genug in der Hierarchie und wird die Problematik verstehen. Man muß halt gewillt sein, sich bis dahin hochzuarbeiten.

Ja: Das ist nicht einfach.

Und wahrscheinlich ist es auch ein wenig ein Henne und Ei Problem. Wenn die Abteilung Webanalyse nur Reporting macht oder nie auf Änderungen drängt, warum sollte dann jemand weiter oben in der Hierarchie auf die Idee kommen, ihr irgendwelche Kompetenzen oder Verantwortung zuzuteilen?

Also los, Webanalysten! Macht euch einen Namen, verschafft Euch den Respekt, den Ihr verdient!

Kommunikation

Das allgegenwärtige Versprechen aller Anbieter: Jeder kann sich seine Daten einfach so holen, wenn er sie braucht.

Daten bedeutet hier in der Regel „Reports“, beziehungsweise es ist theoretisch möglich, daß ein beliebiger Benutzer tiefer eintaucht und eine Analyse durchführt.

Ich denke ich werde nicht viel Widerspruch ernten wenn ich sage, daß das in der Praxis nicht stattfindet. Wir sind ja tatsächlich immer noch an dem Punkt, wo wir Webanalyseteams damit kämpfen, zuviel Reporting und zuwenig Analyse zu machen!

Daher Grundlage Nummer 3: Kommunikation. Paßt nicht so ganz zu den „Vorbereitungen“, weil man sich permament darum kümmern muß, aber ist dafür umso wichtiger.

Ich denke hier an zwei Richtungen.

1. Webanalysten > Businessuser — Meiner Meinung nach ist es Aufgabe Pflicht des Webanalyseteams, das Thema Webanalyse im Unternehmen zu missionieren.
2. Businessuser > Webanalysten — Umgekehrt müssen die Endbenutzer unbedingt dem Webanalyseteam sagen, was genau sie eigentlich benötigen, und vor allem wofür.

Missionieren

Ein starkes Wort. „Missionieren“. Eigentlich nicht stark genug.

Es geht zuerst um Verständnis (Was bedeutet das hier?) und das Vermitteln von Möglichkeiten (Wusstet Ihr daß wir XYZ messen können?), aber auch um Grundlagen (So macht man ein Segment und das ist sinnvoll weil…).

Das Webanalyseteam ist die Quelle allen Wissens um die Webanalyse im Unternehmen. (Sonst läuft was falsch.) Ich habe das Wort „Quelle“ hier ganz bewußt gewählt, denn im Idealfall sollte all dies Wissen aus der Quelle heraussprudeln wie frisches Wasser damit anderswo Analysen und Daten für Änderungen genutzt werden so wie stromabwärts Wasser für alle möglichen Zwecke eingesetzt wird.

Genau wie Missionare wird die Webanalyse mit dem Problem zu kämpfen haben, daß die Endbenutzer teilweise wenig Interesse zeigen.

Ein paar Tips für solche Fälle gibt es durchaus: Zuhören statt Predigen, mit dem Ziel besser zu verstehen, was die Endnutzer brauchen. Das kann man dann liefern und sich damit Türen öffnen. Analysieren und interessante Anomalien intern publizieren.

Meine Lieblingsanekdote dazu stammt von einem Analysten aus Schweden. Er hatte monatelang probiert, per Email seine Kollegen zu animieren, mußte aber irgendwann eingestehen, daß seine Emails nicht gelesen wurden. Er fing dann an, kurze Analysen zu drucken, mit Notizen und offenen Fragen. Die Zettel verteilte er im Büro — genauer gesagt in den Toiletten, wie kleine Denksportaufgaben. Und das funktionierte: Er bekam Rückmeldungen und Interesse!

Requirements & Warum

Wo wir gerade beim Interesse sind: Ich erwarte von den Endnutzern, daß sie dem Analyseteam sagen, worauf es ihnen ankommt.

Zu oft baut ein Analyst Reports für Endnutzer die am Bedarf weit vorbeigehen. Die werden selbstverständlich nicht genutzt, ähnlich wie am grünen Tisch entwickelte Software keine Chance hat.

Webanalysten: Hört den Nutzern zu! Sucht den Dialog! Stellt Fragen und mehr Fragen. Redet mit Eurem CFO, damit Ihr versteht, wie die Firma tickt! Und benennt Eure Metriken um, um Gottes Willen! Eine gute Metrik heißt genau so, wie der Endnutzer sie nennt. (Analog zum Setzen der pagename Variable.)

Endnutzer: Erzählt dem Analyseteam was Ihr braucht! Und vor allem: Erklärt dem Team, warum Ihr das haben müßt! Sagt Ihnen, wogegen Euer Bonus berechnet wird! Helft dem Team Eure KPIs zu verstehen!

Avinash Kaushik beschreibt den „Three Layers Of So What“ Test, ein wundervoller Name für ein sehr mächtiges Tool. Ich erwarte von Webanalysten, daß sie den Benutzer so befragen, und ich erwarte von Benutzern, daß sie den Webanalysten erklären, was für sie wirklich wichtig ist.

All dies ist wie gesagt nicht einfach. Wäre ein einfacher Job nicht langweilig?