Checkliste – Vom Bedarf zum Code

Von | 1. Dezember 2015

Adam Greco ist für mich nachwievor der beste Blogger in unserer Branche. Warum? Weil seine Artikel eine wirklich gute Struktur haben: Problem erklären (und zwar aus Sicht des business), Lösungsansatz skizzieren, zeigen was hinten rauskommt, Notizen.

Weil ich das Format mag, habe ich es auch schon ab und an benutzt, zumindest habe ich es versucht. Heute möchte ich versuchen, es als Tool ganz allgemein einzusetzen.

Die Frage: Wie komme ich eigentlich vom Problem zum Report? Versuch einer Antwort in 5 Schritten.

1 — Bedarf und Definition

Jeder weiss: Der erste Schritt einer Reise ist der schwierigste. Das gilt hier auch.

Ich gehe davon aus, dass was ich hier „Bedarf“ nenne normalerweise eine Frage ist — „sag‘ mal, lohnt sich eigentlich unser Engagement auf twitter?“ oder „Was machen wohl die ganzen Kunden heute, die wir letztes Jahr mit der Weihnachtsaktion gewonnen haben?“

Manchmal ist es auch eine vage Idee oder eine Theorie — „hm… wer sich nach Produkt A auch noch Produkt B ansieht, kauft doch nicht Produkt A, oder?“ oder „Ich glaube wir schöpfen das Potential unserer Emailkampagnen nicht aus!“

Zwei der 4 Beispiele sind direkt messbar, und zwar über Transaktionen. Die anderen zwei sind etwas vage: „machen“ und „Potential ausschöpfen“ muss man ja erstmal etwas genauer definieren.

Oder vielleicht muss man das auch nicht, denn Forschung kann ja auch mal komplett in’s Blaue hinein stattfinden. Wobei ich den Verdacht hege, dass es zumindest hilfreich wäre, wenn der Forscher (also der Webanalyst) grob verstünde, welche Zahlen wichtig sind und welche nicht.

Die Definition des Problems ist der grundlegende Teil dessen, was einen typischen Artikel von Adam ausmacht. Seine Definition geht allerdings etwas weiter, als nur eine Frage zu stellen oder eine Theorie zu formulieren.

2 — KPI(s)

Und damit sind wir bei den Kennzahlen.

Fragen oder Theorien zu Themen wie „lohnt sich“, „kaufen“ u.Ä. kann man sehr gut beurteilen, wenn man sich Metriken wie orders und revenue ansieht. Einfach.

Andere Fragen und Theorien sind nicht so simpel, da muss man schonmal nachdenken, an welcher Metrik man eigentlich beurteilen könnte, was gut oder schlecht sein soll. Die Frage ist: Welche Metrik ist relevant für meinen Bedarf?

Die Frage ist wichtig genug, dass ich das Vieraugenprinzip anwenden würde.

Und: „Page Views!“ dürfte häufig die falsche Antwort sein!

Also: zu zweit hinsetzen, Metriken finden, die eine Antwort auf die Frage liefern, oder eine Bewertung der Idee oder Theorie ermöglichen.

Wenn das nicht klappt? Zurück nach Schritt 1 und den Bedarf neu definieren!

Denn: Wenn man keine Metrik finden kann, dann muss das nicht an den Metriken liegen. Manchmal ist auch die Problemdefinition unglücklich oder irreführend.

Ausserdem: Wenn ich das Problem nicht lösen kann: de-scoping ist immer eine Option! In unserem Fall sogar meist eine sehr gute!

3 — Segmente

Alle 4 Beispiele haben eins gemeinsam: Sie beziehen sich nicht auf alle Daten, sondern nur einen Teil („twitter“, „Weihnachtsaktion“, „Produkt A + Produkt B“, „Emailkampagnen“). Das ist gut! Denn sowas können wir direkt auf Segmente abbilden, oder vielleicht auf „Variablen„, also meist eVars.

Weil wir uns nur einen Teil der Daten ansehen, können wir ausserdem ganz bequem mit dem kompletten Datensatz vergleichen, haben also quasi einen eingebauten Vergleichswert. Das ist praktisch und wichtig!

Nach den Metriken ist es daher sinnvoll notwendig zu definieren, ob und welche Dimensionen (Segmente oder „Variablen“) man braucht.

Auch hier gilt: Wenn sich die nicht wirklich finden lassen, dann stimmt vermutlich mit der Formulierung des Bedarfes etwas nicht, also zurück zu Schritt 1.

Erinnert sich noch Jemand an die Geschichte mit dem „3x nachfragen warum“? Das habe ich zum ersten Mal im Artikel „Three Layers of so what“ bei Avinash Kaushik gelesen. An dieser Stelle sollte man das gemacht haben, also in Schritt 1, 2 oder 3.

So, jetzt sind wir mit der „Definition des Problems nach Greco“ fertig.

4 — Datensammlung

Wir wissen nun, welche Metriken und Segmente wir brauchen. Daraus können wir direkt ableiten, was wir tracken müssen:

  • Jede Kennzahl oder Metrik wird als „Success Event“ getrackt (kurz „event“), d.h. wir senden den entsprechenden event, sobald das passiert, was wir messen wollen.
  • Jede Dimension wird in eine „Conversion Variable“ getrackt. Bedenken muss man an dieser Stelle, wie lange der Wert vorhalten soll, und ob man ihn überschreiben möchte, sobald ein neuer auftaucht. Stichworte: expiry und attribution.

Ein paar Beispiele helfen vielleicht, diese zwei Prinzipien zu verstehen.

Beispiel 1 — Twitter

„Lohnt sich eigentlich unser Engagement auf Twitter?“

Ich definiere „lohnt sich“ mal im Sinne von Retail, also „Generieren wir mehr Umsatz über Twitter, als wir für unser Engagement dort zahlen?“

Damit ist klar: Die Metrik hier ist Umsatz.

„Engagement auf Twitter“ ist etwas komplizierter. Im Grunde muss ich herausfinden, welcher Teil meines Gesamtumsatzes irgendwie auf Twitter zurückzuführen ist. Das ist teilweise relativ einfach — Stichwort „owned content“, den man genau wie Kampagnen messen kann (und soll!), teilweise schwierig — Stichwort „Branding“.

Auch das Thema „Attribution“ spielt hier herein, daher würde ich vorschlagen, es erstmal einfach zu halten:

Wir sehen uns den Teil des Gesamtumsatzes an — Stop, moment, da sehe ich ja sofort: Wir brauchen ein Segment! Super, da sind wir ja schonmal einen Schritt weiter!

Wie definiert sich das Segment?

Also: Wir sehen uns den Teil des Gesamtumsatzes an, bei dem der Benutzer über Twitter (Kampagne oder nicht) zu uns kam.

Erinnert sich noch jemand an die „Container“ bei der Definition der Segmente? Hier ist ein „Visitor“ Container angebracht. (Aufgabe: Warum?)

Für die Regeln im Segment bieten sich ‚Tracking Code beginnt mit „tw“‚ und ‚Referrer ist twitter.com oder t.co‘ an.

Fertig! Vorausgesetzt das Kampagnentracking existierte schon brauchten wir nichtmal extra neues Tracking!

(Später will ich hier sicher erweitern, also über den „last-touch Ansatz“ hinausgehen)

Beispiel 2 — Produkte

„Wer sich nach Produkt A noch Produkt B ansieht, kauft doch nicht Produkt A, oder?“

Auch hier ist die Metrik wieder einfach: „kaufen“ heisst in Adobe Analytics „Orders“ oder „purchase“.

Wir brauchen aber auch noch einen Event für „Produkt ansehen“, und auch den gibt es: „Product View“, oder „prodView“.

Werden „purchase“ und „prodView“ bereits getrackt? Gut!

Für das Reporting und die Segmentierung müssen wir wissen, welche Produkte angesehen und gekauft wurden, wir müssen also Produktnamen oder (besser) Produkt ID oder SKU tracken.

Dafür gibt es in Analytics die s.products „Variable“.

Auch schon implementiert? Gut!

Dann sind wir mit der Datensammlung fertig!

Die 2 Beispiele waren recht einfach. Es kommt selbstverständlich vor, dass man komplexere Setups braucht. Aber die Grundidee ist immer gleich: Events für das was passiert, und eVars für die spätere Unterscheidung oder Segmentierung.

Komplizierter sollte es auch nicht sein. Wunderschönes und hochrelevantes Zitat dazu:

„A natural instinct is to go for the most powerful solution, or a solution that is much more powerful than is actually needed. We should try to do the opposite — find the least powerful solution that will do the job.“

5 — Auswertung

Mit den gesammelten Daten kann ich mich jetzt an die Auswertung machen.

Welche Reports ich mir dafür ansehen sollte, ist eigentlich schon klar, dafür habe ich ja vorher die Dimensionen und Metriken ausgewählt.

Zusätzlich muss ich noch segmentieren, dafür brauche ich also mein Segment. Das Vieraugenprinzip funktioniert auch bei der Definition von Segmenten hervorragend.

Und mit dem Segment, den Metriken und der ursprünglichen Frage/Theorie bin ich in der Lage, Aussagen zu treffen.

Fertig!

Notizen

Dass ich ein grosser Fan von keep it simple bin, muss ich nicht mehr erwähnen. Das merkt man diesem Artikel sicher auch an.

Zielgruppe ist diesmal die Consultingzunft, also ich selber, meine Kollegen und die vielen Partner, mit denen wir und andere arbeiten.

Mir wird immer noch viel zu häufig von „Implementierung“ gesprochen, wenn es doch eigentlich sinnvoller wäre, den ganzen gezeigten Prozess pro Aufgabe/Problem/Fragestellung/Theorie zu durchlaufen… dabei ist doch Implementierungsphase == doof.

Mal was anderes: Ist noch jemandem aufgefallen, dass Adam in letzter Zeit kaum noch postet? Kennt irgendwer ein (noch) unbekanntes, gutes Blog, dem ich folgen sollte? Lücke ausfüllen und so?

4 Gedanken zu „Checkliste – Vom Bedarf zum Code

  1. Bijan S.

    Jan, da hast Du Dir ein schönes und sehr komplexes, aber eigentlich ganz einfaches Thema ausgesucht und recht gut verdeutlicht 🙂 Aber warum schreibe ich das so komisch? Ja, weil:

    ‚Du schriebst: „Lohnt sich eigentlich unser Engagement auf Twitter?“
    Du interpretierst es als: Ich definiere „lohnt sich“ mal im Sinne von Retail, also „Generieren wir mehr Umsatz über Twitter, als wir für unser Engagement dort zahlen?“
    Und für Dich ist damit klar: Damit ist klar: Die Metrik hier ist Umsatz.‘

    Ich gehe einen Schritt weiter, die Frage „Lohnt sich eigentlich unser Engagement auf Twitter?“ hätte bei mir sofort eine Frage ausgelöst, nämlich ‚Was war denn das Ziel?‘, dann gibt es -vermutlich- eine direkte Antwort und ’schmückendes Beiwerk(nächster Absatz)‘.

    Warum mache ich das? Häufig ist es durch Device- und Medienbruch nicht so einfach einen direkten Zusammenhang herstellen zu können und ich gehe mal davon aus, dass Du nicht nur den lapidaren direct-klick analysieren möchtest, sondern auch den Einfluß der Tweets aka SocialMediaActivities in Abhänigkeit der Inhalte/Ziele auf die Kennzahlen der Website; was Revenues sein könnten (dumm nur wenn der inhalt nur BrandAwareness und kein direktes Kaufverhalten hervorruft). Natürlich kann man ALLE Kennzahlen der Website basierend auf einem ‚Twitter-Segment‘ analysieren, aber das macht doch erst im zweiten Schritt Sinn, oder?

    Aaalso, ich folge ja Dir* 😉 Und, Implementierung ist heute essentieller denn je.
    Adam ist gut ohne Frage, allerdings ist bei hm alles straight forward basierend auf einer schicken (oldschool-) SC-Implementierung. Die Zeit ist leider vorbei, heute sind andere, erheblich schlauere, feinere und dynamischere Arten der Implementierung gefragt um die Fragestellungen exakt beantworten zu können. Heute ist Ajax nicht nur ein Minifeature auf einem Miniteil der Webseite, heute werden diese bspw. als SinglepageApps gebaut, die auch noch Fragmente, oder in Abhängigkeit von Nutzererkennung und -Interaktion, Seiten oder Apps nachladen; also ein munteres Durcheinander bei dem das Implementierungkonzept noch viel bedeutsamer wird, damit der geneigte Webanalyst aus den Zahlen auch ein Bild zu generieren vermag, auch wenn er die Website nicht en Detail kennt 😉 Ach ja, ich bin ebenfalls ein großer Fan von KISS.

    Zurück zu den 5 Punkten, eins – 1 – ist der Schlüssel zur richtigen Antwort, denn all das oben Geschriebene sind böhmische Dörfer für den Anforderer, das weiß er nicht, das interessiert ihn auch nicht und das muß es auch nicht – wohl aber uns – damit er die für ihn richtige Antwort erhält 🙂

    Oh, ist viel geworden, sorry.

    * Ich denke da kann man Dir kaum jemanden vorschlagen den Du nicht kennst. In persona fallen mir da spontan Avinash Kaushik, Brent Dykes, Justin Cutroni und Gary Angel ein…

    Antworten
    1. Jan Exner

      Danke für den ausführlichen Kommentar.

      Ich habe die Twitterfrage absichtlich erstmal klein definiert, denn die grössere Frage, wie Du sie stellst, ist schwieriger zu behandeln, da hast Du vollkommen recht.

      Avinash und Brent lese ich teilweise, Justin noch nicht genug, und bei Gary weiss ich manchmal nicht, was ich davon halten soll 😉

      Antworten

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.