smartmetrics

Customer Journey

Neben den traditionellen Web Analytics Methoden versuchen manche Hersteller im Online Marketing eine neue Analyseform für Werbemittelnutzung, speziell für Displaywerbung, zu etablieren - die „Customer Journey”.

Unbefangene erwarten bei einer Customer Journey die Abbildung von Geschäftsbeziehungen und Überzeugungsgraden, (also den Customer Lifecycle) ergänzt um den Übergang zwischen diesen Zuständen - oder, etwas weniger formell die Antwort auf folgende Fragen:

• Wieviele Erstkontakte machen wir und wie?
• Wieviele unserer Besucher können ihr Bedürfnis schon in Worte fassen und warum?
• Wieviele kennen schon unsere Lösungsangebote, die zu ihren Bedürfnissen passen? Und woher?
• Wieviele haben bereits erkannt, dass unser Preis-Leistungsverhältnis für sie passt? Was war das wirkungsvolle „Argument”?
• Wieviele haben neu gekauft?
• Wieviele verspüren nach einem Kauf/Abschluss bereits ein Folgebedürfnis? Ist es ein neues Bedürfnis oder ein Upsell?
• …

Doch - Ach! - die am Markt befindlichen Customer- Journey-Produkte sagen einem nur, welche verschiedenen Werbemittel(-gruppen) vor einem Kauf in welcher Reihenfolge geklickt wurden. Wenn man “Pech” hat, werden auch noch die Views in diese Werbemittelnutzungspfade eingebaut. Und wenn man ganz viel “Pech” hat - dann bekommt man diese Pfade nicht nur für die Käufe, sondern auch noch für jeden beliebigen Zustand dazwischen.
Doch ich greife voraus - bleiben wir zunächst dabei und verwenden statt dem hochtrabenden Begriff “Customer Journey” den langweiligen Technikbegriff „Werbemittelnutzungspfad”.

Wie funktioniert die Messung des Werbemittelnutzungspfad?

Customer-Journey-Tools messen die Views und Klicks auf Kampagnen in Werbenetzwerken und erlauben somit Analysen über die sogenannten Touchpoints der potentiellen Kunden auf Werbemittel. So können auch die Kampagnen herausgefunden werden, die nicht direkt zur Konversion geführt haben, jedoch an dem Konversionsprozess beteiligt waren.

Die einzige Voraussetzung ist, dass der Nutzer immer mit demselben Endgerät im Netz unterwegs ist und selten seine Cookies löscht. Die Cookie-Lösch-Quote liegt bei ~20%. Aber wer von Ihnen nimmt den Bürorechner mit nach Hause oder verwendet ihn gar zum mobilen Surfen?

Die Ziele der „Customer Journey”-Analysen aus Analystensicht:

• Die Abbildung des Online-Werbemittelnutzungspfades (der Verlauf sowie Anzahl und Art der Touchpoints auf Werbemittel und -Kanäle)
• Eine gewichtete Erfolgs- und Kostenverteilung der an der Customer Journey beteiligten Maßnahmen aufzuzeigen
• Ein besseres Verständnis für die Werbemittelnutzung zu erlangen

Die herkömmliche Erfolgsanalyse betrachtet i. d. R. die reinen First- oder Last-Cookie-Wins-Verteilungen. Diese Sicht ist bei vielen Vermarktern nach wie vor die einzige Sicht für die Abrechnung, sie entspricht aber nicht den Anwenderanforderungen:

1. Alle Werbekosten lückenlos einzubeziehen
2. Eine gewichtete Zuweisung von Erfolg und Kosten auf Kanäle/Partner bzw. Werbemittel

Insofern treffen diese Tools durchaus auf ein prinzipielles Bedürfnis.

Anforderungen an Customer Journey Tools

Für den Analysten stellt sich nun die Frage nach der Gewichtung: Ist jeder Touchpoint gleichwertig, oder sind die Letzten bzw. Ersten stärker zu bewerten?

Die Gewichtung pro Touchpoint kann abhängig gemacht werden von der Anzahl und von der Art des Touchpoints. So sind zumeist Views deutlich geringer zu gewichten als Klicks, da Klicks eine aktive Aktion des Kunden darstellen. Der letzte Touchpoint, der letztendlich zur Konversion führt, bekommt i.d.R. die stärkste Gewichtung, oft wird aber auch der Erste als besonders wichtig angesehen. Eine denkbare Gewichtung wäre also 30% des Ertrags gelten als Erfolg für den Erstkontakt, 40% für den letzten und 30% für alle Kontakte. Wie immer in der Kostenrechnung ist aber auch hier die Zuordnung natürlich willkürlich. Ich empfehle daher, sie innerhalb eines Unternehmens und Jahres wenigstens konstant zu halten.

Stärken Customer Journey

• Komplette Sichten der Touchpoints von einem Device und der Interdependenzen auf Online Marketing-Maßnahmen
• Relativ einfache Vertaggung auf der Website - alle Landing Pages plus Konversionspunkte.
• Post View Conversion (nur Display Ads!) wird meist mit abgebildet.
• Verursachungsgerechte Kostenermittlung der Konversion. Die gewichteten Maßnahmen oder Werbekanäle können mit Ihren Kosten der Konversion gegenübergestellt werden. Voraussetzung: Die Kosten (Fix- und variable Kosten) für die Maßnahme liegen vor und lassen sich eindeutig zuordnen.

Schwächen Customer Journey

• Customer-Journey-Tools bilden den Werbemittelnutzungspfad pro Device ab. Nutzt ein- und derselbe Kunde mehrere Endgeräte, so wird er pro Endgerät einen Werbemittelnutzungspfad hinterlassen - sofern Cookies das einzige Identifikationsmittel sind. Was sich bei einer „Last Cookie Wins” -Betrachtung naturgemäß weniger stark auswirkt als bei Analysen von Wechselwirkungen.
• Importe von Stornos, Retouren etc. sind eine Domäne der klassischen Web Analytics Tools
• Analysen sind nicht möglich 1

Summary

Die derzeitigen Customer-Journey-Tools bieten aus unserer Sicht noch keine kompletten Analysemöglichkeiten auf den Erfolg der Kampagnen. Sie bilden den Werbemittelnutzungspfad ab und liefern somit wertvolle Antworten auf die Frage:

• Welche Kanäle, Werbepartner und Werbemittel werden bevorzugt genutzt und welchen Beitrag zur Konversion liefern sie?

Aber es bleiben auch einige Fragen unbeantwortet:

• Ich bediene immer 5 Kanäle und stelle fest, dass 3 Kanäle immer am Erfolg beteiligt sind. Kann ich dann die Schlussfolgerung treffen, mich ausschließlich auf diese 3 Kanäle zu fokussieren?
• Wie hoch waren die Kosten der Maßnahmen im Bezug zur Konversion?

Fußnoten

Fußnote 1:

Eine Analyse ist aus folgenden Gründen nicht möglich:

1. Datengrab Werbemittelnutzungspfad

Baut man den Werbemittelnutzungspfad auf Basis der einzelnen Trackingcodes auf, indem man sich nicht nur die verwendete Kampagne oder den Kanal sondern tatsächlich das einzelne Werbemittel merkt, so müssen bereits kleine Marketingabteilungen mit nur 20.000 unterschiedlichen Marketing-Links mit rund 20.000³ = 800.000.000.000 verschiedenen Pfaden mit maximal 3 Kontakten rechnen. Bei nur 80.000.000 Einwohnern ist also jeder Pfad der Länge „3″, der von 2 Nutzern verwendet wurde, ein „interessanter” Ausreißer!

Erfasst man aber nur den Kanal oder die Kampagne, so stellt man leider fest,

• nur für 15% der Nutzer sind zwei unterschiedliche Kanal-Kontakte nachweisbar.
  [Die Direkteingabe inkl. Der Branded-Search sehe ich hier ausdrücklich nicht als Kanal.]
  (Liebe Hersteller, ich erwarte ungeduldig Ihren untermauerten Widerspruch!)
  
• die Resultate sind etwas grob. Wer möchte schon auf das gesamte SEM verzichten, weil er die ineffizienten Keyword-Groups nicht erkennt?

2. Kosten-Nutzen-Betrachtungen

Eine Kosten-Nutzen-Betrachtung einer Kampagne ist nur möglich, wenn die gewichteten Erfolge/Erträge einer Kampagne ihren Kosten gegenübergestellt werden. Die Kosten sind aber auf Ebene der Kampagne zumindest für den wichtigen Kanal SEM sehr heterogen. Für alle Kampagnen mit homogener Kostenstruktur bekomme ich neben den Views², Klicks, Umsätzen, Deckungsbeiträgen und „CPO” dann auch „Gewichtete Umsätze” und „Gewichtete CPO”.

3. 7>3 ist keine Analyse

Ein „Customer Journey Tool” mag mich davon abhalten, eine Kampagne abzuschalten, die „viele Vorlagen zu Käufen” geleistet hat. Aber die unter Punkt 2 der Fußnote genannten Kennzahlen werden mir niemals sagen, warum. Es gibt auch keine weiteren Drilldown-Möglichkeiten. Und ich werde auch bis auf weiteres nicht in der Lage sein, nur für Nutzer, die ein bestimmtes Banner gesehen haben, eine bestimmte Keyword-Anzeige zu schalten.

Fußnote 2:

Die Views gibt es natürlich nur für Banner. Für Mails, SEO und SEM sind die Views nicht mess- bzw. verknüpfbar. Wieso soll ich aber die Brandwirkung eines Banners höher bewerten als die einer Keyword-Anzeige? Ist sie wertvoller, nur weil ich sie besser messen kann?

Liefert der SiteCatalyst Marketing-Channel-Report die “richtigen” Zahlen?

Adobe SiteCatalyst bietet mit seinem Marketing-Channel_Report (MCR), die Möglichkeit, zu jedem Marketing-Kanal ohne zusätzliche Implementierung die Zielerreichungen (Käufe, Umsätze, Logins,…) nach “First Cookie Wins” (FCW) und “Last Cookie Wins” (LCW) gleichzeitig zu betrachten. Hierbei wird die Direkteingabe oder der Besuch über SEO-Maßnahmen als Kanal betrachtet und der Besucher wie üblich mit einem Cookie (30 Tage) versehen.

Das klingt geil, oder?

• Im MCR wird standardmäßig immer jede Session einem Kanal zugewiesen

Auch das klingt geil, oder?

Zu den Marketingkanälen zählt Adobe SiteCatalyst allerdings auch die Direkteingabe oder die SEO-Maßnahme und hier liegt das Problem.

Ein Beispiel:

1. Kontakt:Kampagne A
2. Kontakt Kampagne B
3. Kontakt: Direkteingabe und 10€ Umsatz

a) Sicht im MCR

Ergebnis: Keine Konversion für B

- siehe auch Fußnote -

b) Sicht im Kampagnenreporting auf Basis s.campaign

Im Kampagnenreporting auf Basis der s.campaign und Last-Cookie-Wins haben wir folgendes Bild:

oder auf Basis einer zusätzlichen eVar (=s.campaign) und First-Cookie-Wins:

Nun haben wir zwei Reports, ist aber wenigstens richtig.

Sollte man besser den Marketing-Channel-Report also lieber nicht nutzen, da er wirtschaftlich unsinnige Werte ausgibt?

Statements:

1. Wirtschaftliches Online-Marketing führt die besten Kunden immer in den Kanal “Direkteingabe”
2. Im Affiliate Marketing würde immer ein Vergütung von Kampagne B erfolgen, aufgrund des 30-Tage-Cookies.
3. Wer eine Direkteingabe für einen Marketingkanal hält, hat den 30-Tage-Cookie nicht verstanden.

Ist das MCR-Reporting also unsinnig und nicht verwertbar?

Nein, wer beides will - den Marketing Channels Report und “richtige” Zahlen, sollte folgendes an seiner Implementierung ändern:

Wenn ein Trackingcode übergeben wird, reicht es nicht aus, nur die s.campaign zu füllen. Sondern es muss auch ein Cookie mit zwei Werten gesetzt werden:

• Trackingcode des soeben geklickten Werbemittels und aktuelles Datum/Uhrzeit.

Bei jedem folgenden Visit muss, wenn ein “kostenfreier Kanal” genutzt wurde und daher kein neuer Trackingcode vorliegt, der Trackingcode aus dem Cookie ausgelesen und wieder an s.campaign übergeben werden. Dies muss solange erfolgen, bis das Datum in dem Cookie mehr als 30 Tage zurück liegt.  Dann respektiert das Regelwerk des MCR die Logik “eine Traffic-Quelle ohne Trackingcode überschreibt niemals einen teuren Kampagnen-Klick”. Nur leider verdirbt das die Metrik der Click-Troughs. Dafür setzen wir bei jedem “echten” Kampagnen-Klick einen eigenen Event und arbeiten stattdessen mit diesem. Diese erweiterte Kampagnenlogik fügen wir pflegeleicht in die Plugin-Sektion des JavaScripts ein.

Die einzige Fehlerquelle dieser Lösung steckt in der Identifikation des “neuen Visits”. Das fragen wir mithilfe eines Session-Cookies ab - denn wenn der Nutzer keine Cookies akzeptiert und wir ihn daher zu häufig “als neuen Visit” erkennen würden, haben wir auch keinen Cookie, dessen Kampagnenwert wir auslesen könnten.

Fußnote: Adobe hat dieses Problem offenbar beschäftigt und mit dem letzten Release die CRM-Kanäle besser konfigurierbar gemacht. Jetzt kann für jeden Kanal angegeben werden, ob dieser Kanal in der Last-Bewertung ältere Kanäle überschreiben darf (”Override Last-Touch Channel” bzw “Last Touch-Kanal außer Kraft setzen”). Es ist uns aber aus der Praxis noch kein Fall bekannt, bei dem es gelungen ist, die Abrechnungspraxis im Marketing-Channel-Report stimmig abzubilden.

Straft Google fremde Web-Analytics-Systeme ab?

Am 18. Oktober hat Google angekündigt, in Zukunft die Suchanfrage-Informationen im Referrer bei angemeldeten Benutzern zu verschlüsseln. Benutzer, die an irgendeinem der zahllosen Dienste von Google angemeldet sind und eine Suche in Google ausführen und anschließend auf eines der Ergebnisse klicken, würden einen erhöhten Schutz ihrer Privatsphäre erhalten, so Google in der Erklärung. Der genaue Wortlaut kann hier nachgelesen werden.

Nun ist ja Google gemeinhin nicht für sein altruistisches Handeln bekannt und schon gar nicht für vorauseilendem Gehorsam in Sachen Datenschutz - es gibt niemanden der sich bisher darüber beschwert hat, dass man im Referrer nachführen kann, wonach der Anwender gesucht hat. Und wieso gilt das nur für angemeldete, aber nicht für anonyme Besucher - man müsste ja eigentlich genau anders herum vorgehen?

Was ist die Motivation für Google, dieses Verfahren auszurollen?

Technischer Hintergrund

Klickt ein Anwender auf ein Suchergebnis, so kann die aufgerufene Zielseite unter Auswertung des von Google mitgelieferten Referrers - der “Absprungadresse” - den ursprünglichen Such-Term herausfinden und in die eigene Web-Analytics-Statistik übernehmen. Diese Statistik bildet das Rückgrat für die SEO/SEM-Optimierung der Site und damit den wirtschaftlichen Interessen des Site-Betreibers.

Wird diese Information nun verschlüsselt, so fehlen die notwendigen statistischen Informationen zur Optimierung des eigenen Angebotes und der Aufwendungen für Suchmaschinenmarketing.

Da sehr viele Nutzer einen oder mehrere Dienste von Google benutzen (Google Mail, Blogs, Feed Reader, Picasa, Google+, …), ist die Anzahl der Benutzer, die sich meist auch noch automatisch einloggen lassen, entsprechend hoch und es wird eine signifikante und relevante Auswirkung auf die oben erwähnte Statistik erwartet.

Honi soit qui mal y pense

Welche wirtschaftlichen Auswirkungen ergeben sich bzw. könnten sich durch diese Änderungen ergeben?

Da ist zunächst mal Google Adwords. Durch eine Verschlüsselung der Suchbegriffe fällt es nicht mehr so leicht, Anzeigen im Hinblick auf Kosteneffizienz zu optimieren. Das könnte eine Steigerung des Umsatzes bei Adwords zur Folge haben. In der Tat bewerte ich diese aber eher als marginal und das Ganze auch als zu kurz gedacht, bietet Adwords selbst ja eine große Zahl an Tools zu genau dieser Optimierung an.

Was wären dann die Gründe? Man muss, wie immer bei Google, “über Bande” denken - durch den “Schutz” dieser Informationen stehen entsprechende Statistiken nicht mehr in den Web-Analytics-Tools der Sitebetreiber zur Verfügung. Die Frage, die es zu beantworten gilt: “Gilt diese Einschränkung in Zukunft auch für Google-Analytics (GA) oder liefert dieses wie bisher die “Klartext-Informationen?”. Die Vermutung liegt nahe, da - wie im Blogartikel geschrieben - die Webmaster-Tools ja bereits die Top-1.000 im Klartext enthalten. Wenn also auch GA eine Klartextliste bereithält, wäre dies ein Affront sowohl gegen die Datenschützer in Deutschland als auch eine Kampfansage an die anderen Web-Analytics-Hersteller. Die Sitebetreiber wären gezwungen Google Analytics einzusetzen oder gar gleich auf Google Analytics Premium zu wechseln, um diese Statistik zu erhalten.

Dies ist eine offene Frage, die es in den nächsten Wochen zu beobachten gilt.

Ab wann sind Auswirkungen zu erwarten?

Derzeit ist der Algorithmus zumindest auf Google Deutschland - http://www.google.de - noch nicht aktiv. Anders als im Artikel beschrieben ist ein Wechsel auf https://www.google.de wegen fehlerhafter Zertifikate und eines automatischen Rücksprungs auf http://www.google.de nicht möglich.

Auf https://www.google.com ist der neue Algorithmus aktiv und in der Tat fehlt im Referrer der ursprüngliche Such-Term.

Was tun?

Wie immer in solchen Fällen: Abwarten und Ruhe bewahren! ;-). Sobald der Algorithmus auch in Europa bzw. Deutschland aufgeschaltet wird, sollte man dies in den Suchwort-Statistiken sehen können, da nun die Suchanfragen ohne Suchwörter zunehmen müssten. Die abgeleitete Statistik “Bestelleingang je natürlichem Keyword” dürfte ab diesem Zeitraum keine belastbaren Ergebnisse mehr liefern. Aber auch nur diese eine Statistik. Inwieweit das kritisch ist oder werden kann, hängt vom Geschäftsmodell und von den gewählten KPI zur Analyse und Prognose ab.

Browser mit “Do not track” Funktionen - Auswirkungen auf die WA

In einem Artikel der dailytech vom 8. Dezember  “Mozilla Kills “Do Not Track” Tool, Microsoft Adds One to IE9″ wird darüber berichtet, dass Mozilla für die Firefox-Version 4 auf Druck der Werbeindustrie die sogenannte “do not track”-Funktion wieder ausbaut und gleichzeitig aber Microsoft eine “Tracking Protection”-Funktion in seiner neuen Version 9 des Internet-Explorers einführen wird.

Es wird weiterhin vermutet, das Microsofts Beweggründe darin zu suchen sind, eventuell verloren gegangenes Terrain bei der Browservorherrschaft wieder gut machen zu können.

Was ist denn eine “Do-not-Track” Funkton oder eine “Tracking Protection”?

Im IEBlog kann man dazu folgendes Lesen:

Heutige Websites beinhalten diverser Aufrufe, um weiteren Content, Bilder, Cookies, Zählpixel, HTML oder ausführbare Skripte aufzurufen. Diese Datenanfragen sollen mithilfe der Tracking Protection eingeschränkt werden und somit die Datensammlung und das Tracking ebenfalls zu limitieren. Hierzu muss im IE9 der Anwender eine Tracking Protection List (TPL) pflegen, welche zunächst leer ausgeliefert wird. In die TLP werden  Webadressen, wie z. B. BoeseSite.de eingetragen. Ruft man allerdings eine Webadresse direkt auf oder klickt auf einem Link, so wird sie auch ausgeführt. auch wenn diese Adresse in der TPL aufgeführt wird. Neben dieser Liste der “bösen” Webadressen soll es auch die Möglichkeit geben Ausnahmen zu deklarieren, unter welchen Restriktionen die “böse” Adresse doch aufgerufen werden kann.

Mit Hilfe des neuen IE-Mechanismus können Anwender aktiv darauf Einfluss nehmen, was von Ihnen gemessen werden darf und was nicht. Anders ausgedrückt: Hiermit kann sich jeder Anwender seine persönliche “black” und “white” Liste an Webadressen erstellen. Einige dieser Funktionen werden bereits von IE8 im InPrivate Mode unterstützt. Neu hierbei ist das Format der Black und White Lists, diese werden für den IE nämlich als RSS-Feeds bereitgestellt. Somit kann beispielsweise der Systemverwalter im Unternehmen zentral viele der vermeintlich “bösen” Webadressen pflegen und als Anwender abonniere ich lediglich diesen Service und brauche mir um die angebliche “Sicherheit” keine Sorge mehr machen.

Neu sind diese Funktionen aber nicht, werden sie doch als Add-On z. B für den Firefox seit längerem angeboten - Adblock Plus.

“Die Erweiterung wird von über vierzig Filterabonnements für Dutzende Sprachen unterstützt, mit denen sie automatisch für verschiedene Einsatzzwecke konfiguriert wird, angefangen beim Blockieren von Werbung bis hin zum Blockieren bekannter bösartiger Webseiten.Mit Adblock Plus können Sie auch eigene Filter erstellen, unterstützt durch viele hilfreiche Features, z.B. ein Kontextmenü-Eintrag für Bilder, ein Tab zum Blockieren von Flash und Java, und die Liste blockierbarer Elemente zum Entfernen von Skripten.”

Nehmen wir einmal an, alle Browser würden über eine “Do-not-Track”-Funktion verfügen und sie wären permanent eingeschaltet: Was wären die Auswirkungen auf die Web Analytics und den Werbemarkt?

1. Domains von Web Analytics Anbietern oder Adservern sowie Scripte wären gezielt blockbar.
2. Die Web Analytics wird komplizierter, weil man permanent darauf achten muss, nicht in den TLPs zu landen.
3. Für Anwender, die gezielt das Zählpixel blocken, müssen alternative Messmethoden (z. B. serverseitiges Messen, Logfiles) aktiviert werden.
4. Werbung wird komplizierter, da die Adserver und Affiliates wie mit einem Adblocker einfach ausgelistet werden könnten. Somit könnten auch einige aktuellen Geschäftsmodelle Ihre Daseinsberechtigung verlieren. Die Werbewirtschaft insgesamt würde deutlich an Umsatz einbüßen.

Die Auswirkungen auf die Werbewirtschaft und den gesamten Online Markt sind nur schwer abzuschätzen. Der Online Markt lebt davon Werbung messbar und zielorientiert auszusenden. Genau das unterscheidet den Online Markt von anderen Werbemärkten. Viele Webangebote sind werbe-finanziert und können nur aufgrund der Werbeeinnahmen kostenlos angeboten werden. Websitebetreiber werden dazu übergehen müssen die Werbung auf ihre Site einzubinden und über Ihre Domains auszusenden.

Könnte man die IE9 Tracking Protection technisch umgehen?

Das Umgehen der Tracking Protection und ähnlicher, auf URLs basierender Mechanismen ist temporär möglich. Da hier lediglich auf Domainnamen oder URL’s abgeprüft wird, kann man durch tracken über die Primäradresse der Website und Reverse-Proxy-Methoden relativ simpel diesen “Schutzmechanismus” aushebeln. Allerdings muss davon ausgegangen werden, dass dies relativ schnell erkannt wird und die TLPs angepasst werden.

Letztendlich werden alle “Do-not-Track”-Funktionen und ähnliche Maßnahmen dazu führen, das beide Seiten aufrüsten. Hier wäre mehr Aufklärung und Offenheit sinnvoller. In den meisten Fällen wird das Nutzungsverhalten von anonymen Webbesuchern getrackt und analysiert mit dem Ziel den Content, die Navigation und Konversion zu optimieren,m was letztendlich auch dem Besucher zu gute kommt.

Aber vielleicht führen diese “Do-not-Track”-Diskussionen auch dazu mehr Augenmerk darauf zu legen, aus den anonymen Besucher gute Bekannte zu machen und mit dessen ausdrücklichen Genehmigung zu tracken.

Vorteile durch Web Tracking für Websitebesucher?

1. Der Websitebetreiber oder Werbetreibende bekommt Informationen was beim anonymen Anwender funktioniert und was nicht? Dadurch könnte sich die Website und die Werbung positiv verbessern - in der Funktion, Aufmachung und Content.
2. Durch Targeting-Lösungen bekommt der Anwender sicherlich einen höheren Anteil an “guter” Werbung, der ihn interessiert als ohne Targeting?

Wo ist eigentlich die Tracking Protection, wenn wieder einmal die Marktforscher das Einkaufsverhalten in Supermärkten analysieren und anschließend die Ware umgeräumt wird und Laufwege geändert werden, so dass man nichts wieder findet.

Die Lösung

Oder liegt vielleicht die Lösung in den bewährten Kundenkartenmodellen - Web Tracking findet nur noch dann statt, wenn wir über Bonuspunkte dem Anwender Vorteile beim Einkauf verschaffen - ab 5.000 Trackingpunkte gibt es einen 5€ Einkaufs-Gutschein.

Redirects: Wer sie kennt, der mag sie nicht,…

... wer sie mag, der hat sie nicht,…

…wer sie hat, der kennt sie nicht?

Redirects sind nicht auszurotten. Warum auch. Sie leiten Nutzer direkt von einer auf eine andere Adresse weiter, ohne Anwender mit Details zu behelligen. Sie erleichtern die Domainpflege, verhindern Irritationen bei 404-Fehlern oder dienen Zählsystemen als Trigger. [Und wenn es sich um Ad-Server handelt, ist es nicht zwangsläufig die schlechteste Alternative deren Klicks zu zählen.]

Über die Technische Implementierungsmöglicheiten von Redirects ist schon mehrfach sinnvoll geschrieben worden. Auch von uns. Ich greife hier daher nur die Quintessenz und Erste Goldene Regel zur Implementierung von Redirects im Umfeld gemessener Seiten auf:

“Jeder Redirect muss so realisiert werden, dass der Originalreferer erhalten bleibt”

[Zur Umsetzung dieser Regel lesen Sie bitte das Handbuch Ihres Webanalytics-Tools oder fragen Sie Ihren Dienstleister]

Diese Regel ist gut, denn sie ist kurz, prägnant, einfach zu merken und ausnahmslos formuliert. Solche Regeln geben uns Halt in der wechselhaften Welt. Da ist es egal, dass sie hin und wieder falsch ist. Das Wichtigste steht eh immer in den Fußnoten.

Fußnote 1: Den Einwand “Für meine tausend Banner-Klicks will ich nicht 500 verschieden Referer sehen, sondern einen Ad-Server” will ich nicht gelten lassen. Gerade weil die Kampagnen weit gestreut sind, müssen die Referer erfasst werden. Oder soll ich mich bei der Optimierung der Aussteuerung schutzlos einem Computerprogramm oder (s)einem Dienstleister ausliefern?

Fußnote 2: “Was ist, wenn der Originalreferer systembedingt bereits LEER ist? ”

E-Mails werden bei vielen Zielgruppen vorwiegend nicht mit einem normalen Browser sondern mit einem E-Mail-Client geöffnet. Egal, ob die Nutzerin ihre Mails mit Thunderbird öffnet, oder ob der Nutzer mit Outlook arbeiten muss, wenn ein Link in der Mail geklickt wird, wird mit dem Öffnen des Webbrowsers in nahezu 100% der Fälle kein Referrer übergeben. Weswegen insbesondere im B2B-Bereich für Newsletter keine Referer gemessen werden. Stattdessen gilt der E-Mail-Klick als Direkteingabe und verdirbt uns somit so manche lustige Spekulation über die Stärke unserer Domain als Brand.

Wenn also die Newsletter, Benachrichtigungs-, Registrierungs-, Validierungs- oder sonstige System-Mails eh mit einem eigenen System verschickt werden, und wenn dieses System eh selbst Öffungs- und Klick -statistiken erhebt, und wenn die Klicks eh per Redirect gemessen werden [wie sonst?], und wenn diese Mails zu Ihren Top-20-Trafficquellen zählen - warum sollte dann nicht lieber der E-Mailserver zwischen den natürlichen Referern stehen?

Das Universal Tag (Teil 2): Vorschläge für die Darstellung und den Transport

Im meinem Beitrag “Das Universal Tag (Teil 1): Ein erster Schritt zur Standardisierung in der Web Analytics” berichtete ich über die meiner Meinung nach inhaltlich unbedingt nötigen Fähigkeiten eines standardisierten Tags wie Seiteneigenschaften, Benutzer- oder Produktattribute sowie die frei definierbaren Metriken. Nichts von alldem ist neu - doch was fehlt, ist eine komplette Auflistung. Denn das eine Universal Tag muss alles unterstützen, was die heutigen, herstellerspezifischen Tags in Summe abbilden.

In diesem Beitrag möchte ich mich mit den Möglichkeiten auseinandersetzen, diese inhaltlichen Anforderungen in eine technische Darstellung zu überführen und die gesammelten Daten an einen Data Collection Server zu übertragen.

Was eignet sich zur Darstellung? XML, JSON und Javascript Arrays sind technisch geeignet, die inhaltlichen Anforderungen abzubilden. Heutzutage ist fast ausnahmslos Javascript im Einsatz, mit einem kunterbunten Mix aus Arrays, Objekten und globalen Variablen.

Ich würde XML für die Darstellung einsetzen. Denn XML hat die Vorteile, dass

• es ein weit verbreitetes Format ist,
• es relativ gut menschenlesbar genannt werden kann,
• es auch ausserhalb der Website viele Tools und Prozesse gibt, die mit diesen Daten etwas anfangen können,
• XML erlaubt, alle Informationen in eine einzige Variable bzw. Datei zu schreiben, die einfache, hierarchisch und listenartige Daten nebeneinander und im Verhältnis zueinander abbilden kann.

Die per Javascript ermittelbaren Daten (Browser, Betriebssystem, Plugins, Bildschirm etc.) können dort genauso einen Platz finden wie die serverseitigen, zum Beispiel aus dem CMS erzeugten Informationen zu Seiten, Gruppen von Seiten, Server und so weiter. Shop-spezifische Informationen, in der Hauptsache Warenkörbe, sind meist Listen mit Beschreibungen aus Artikelnummern, Größen, Farben, Preisen, Stückzahlen und Informationen über den Bereich, aus dem sie stammen. Auch das lässt sich hervorragend mit XML abbilden.

Daten zu Besuchern, wie die ID des benutzten Werbemittels, die Postleitzahl oder Altersgruppe können im gleichen Datensatz abgelegt werden. Die Befüllung der XML-Struktur kann teils serverseitig mit Java, Php, CMS und teils clientseitig per Javascript erfolgen.

Kurzum: Mit XML wären wir auf der sicheren Seite.

Wie steht es um die Transportmöglichkeiten eines Universal Tag? Grundsätzlich beherrschen unsere Browser zwei unterschiedliche Verfahren, Dateien aus dem Internet anzufordern und dabei zusätzliche Informationen zu übermitteln: GET und POST.

Beim GET sendet der Browser an den Server die Adresse, die hinter einem Fragezeichen eine Reihe von Name-Wert-Paaren enthält. Diese werden üblicherweise mit einem “&” voneinander getrennt, zum Beispiel: http://www.server.domain/pfad/datei.php?seite=home&user=frank&start=0

Firefox, Safari und Opera unterstützen solche Adressen mit mindestens 80.000 Zeichen Gesamtlänge, Microsofts Internet Explorer in den Versionen 5.x bis 8.x leider nur mit maximal 2.083 Zeichen. Dies führt regelmäßig zu Problemen.

Beim alternativen POST sendet der Browser die Daten im Protokoll-Header mit, sie werden nicht Bestandteil der URLs. Dieses Verfahren wird beispielsweise benutzt, um Bilder oder andere Dateien auf Server hochzuladen. Auch Formulare werden oft so übertragen. Sie erkennen diese Technik leicht daran, dass Ihr Browser bei der anschliessenden Benutzung des “Back”-Buttons fragt, ob er die Daten erneut senden soll.

Die beiden Verfahren sind grundsätzlich geeignet, Web-Analytics-Daten zu transportieren. Dennoch wird derzeit nur GET standardmäßig von den großen Herstellern angeboten.

In Frage kommen:

1. Klassisches Javascript Tag, beschränkt im Microsoft Internet Explorer auf 2083 Byte lange URLs. Längere werden nicht übermittelt.
2. Noscript Tag (mit der gleichen Beschränkung)
3. Ajax + serverseitige Messung, ergänzt um Javascript-Automatismen zur Vergabe oder Ermittlung der Visitor ID. Diese ist in der Datenmenge praktisch nicht beschränkt, die einzigen Grenzen liegen bei den Servern, die diese Daten empfangen und verarbeiten müssen. Aber: Bei Ausfall der Infrastruktur wie der Verbindung zum Data Collection Server führt dieses Vorgehen schnell zum Stillstand der eigentlichen Applikation. Wenn man das vermeiden will, muss man sehr aufwändig entkoppeln, Pufferspeicher einbauen etc.
4. Ein direktes POST zum Data Collection Server: Um das “2083-Byte-Problem” des IE zu umgehen, wäre das in der Implementierung aus meiner Sicht sinnvoll und weniger aufwändig als die serverseitige Messung. Das ist relativ einfach zu erreichen:

• Anstelle des klassischen Image Tags wird ein FORM verwendet.
• In einem IFRAME befindet sich ein Formular mit action=”POST”, alle Variableninhalte sind INPUT TYPE=”hidden”.

Die Anforderung an den Data Collection Server ist allerdings, dass er POST-Daten empfangen kann. Omniture kann das beispielsweise nicht an der klassischen IMG-Schnittstelle, aber sehr wohl an der Schnittstelle, die für Data Insertion API ausgelegt ist. Der Schritt weg von der klassischen Image-Request-Methode zu einer ausgefeilteren Technik, die das URL-Längenproblem umgeht, ist sicher nicht für jeden notwendig.

Was jedoch passiert, wenn man nur den Markt analysiert und nach dem aktuellen Bedarf handelt, sehen wir an vielen heutigen Tools: Es entsteht eine Situation, in der die Hersteller nur das Nötige tun, um die Masse ihrer Kunden im kaufmännischen Sinne gut zu bedienen. Wirklicher Fortschritt scheint mir dabei eher eine untergeordnete Rolle zu spielen. Die (Noch-)Einzelfälle, in denen die Grenzen heutiger Implementierungen überschritten werden, nehmen in meinem Tätigkeitsbereich zu und die Workarounds sind jedesmal wieder teuer.

Ist das auch bei Ihnen der Fall? Wir sollten gemeinsam mit dem Aufräumen beginnen, um diese Kosten in Zukunft zu vermeiden.

Darum lösche ich keine Cookies

Aus Datenschutzgründen wird Internet-Nutzern immer wieder geraten, sie sollten doch die “gefährlichen Cookies” in ihren Browsern löschen, diese auf keinen Fall akzeptieren und überhaupt alles Erdenkliche anstellen, um diese von der Festplatte zu radieren. Das ist bestimmt gut gemeint und im Sinne einer Anonymisierung und des Schutzes der Privatsphäre auch superkorrekt!

Aber ich bekenne: Ich gehöre zu den Verweigerern dieser Ratschläge - ich lösche keine Cookies. Aktuell habe ich rund 500 Cookies auf meinem PC. Und es ist mir egal, von wem und warum die dort sind. Ich lösche sie nicht und lasse sie, wo sie sind. Im Gegenteil: Ich habe sogar meinem Virenscanner und meinem CCleaner beigebracht, Cookies nicht zu löschen.

Der Grund ist ein ganz einfacher: Ich mag es, wenn man mich auf einer Website wiedererkennt - genauso, wie ich es mag, wenn mich die  Bäckereifachverkäuferin morgens begrüßt. Ich würde nicht auf die Idee kommen, solche Läden mit Verkleidung zu betreten, jeden Morgen mit einer anderen, damit ich um Gottes willen nicht wiedererkannt werde. Kurzum: Ein bisschen Eitelkeit darf sein, deshalb lösche ich meine Cookies nicht.

Zugegeben, das klingt etwas pathetisch, aber es ist einfach an der Zeit, mal etwas Gutes über Cookies zu sagen. Es sind kleine Helfer, die viele Dinge im Internet einfacher und bequemer machen:

• Man wird automatisch auf Websites eingeloggt.
• Websites speichern individuelle Einstellungen in Cookies und ich muss nicht jedesmal neu konfigurieren.
• Shops wissen, was ich mag und bieten mir interessante Dinge an.
• Ich genieße Einkaufsvorteile, weil ich einen Cookie besitze und der Shop mich als Stammkunden wiedererkennt.
• Websites tauschen untereinander Daten aus und Social-Media-Applikationen “sprechen” untereinander, weil ich deren Cookies akzeptiere.

Cookies wurden weder von der CIA, noch von der NSA und schon gar nicht vom BND erfunden, sondern von Site-Betreibern und Webserver-Programmierern, die einfach wissen wollen, wer da virtuell vor ihnen steht. Diese erfahren auch nichts “von mir”, sondern lediglich über mein Internet-Benutzungsverhalten, also einen recht schmalen und einseitigen Ausschnitt meiner “Persönlichkeit”.

Für wesentlich “gefährlicher” halte ich Rabattkartensysteme, weil sie in der Lage sind, mein gesamtes Offline-Verhalten lückenlos nachzuvollziehen. Damit habe ich tatsächlich ein Problem, und darum besitze ich keine einzige dieser Karten.

Also, liebe Rabattkarten-Besitzer: Macht bitte nicht so viel Getöse um die angebliche Schädlichkeit von Cookies, diese haben aus meiner Sicht einen berechtigten Daseinszweck.

Im Übrigen kennt die oben erwähnte Bäckereifachverkäuferin die Größe meiner Familie, deren Essgewohnheiten, die Anzahl Autos und deren Marken sowie die Zahl unserer Fahrräder. Und sie weiß, wie viele Kreditkarten ich besitze. Sie weiß auch, dass ich selten Kekse kaufe. Und das alles ganz ohne Browser-Cookies.

Das Universal Tag (Teil 1): Ein erster Schritt zur Standardisierung in der Web Analytics

Eine traumhafte Vorstellung: Dass ein einziger universeller “Universal Tag” ausreicht, um alle  Web-Analytics-Tools einheitlich bedienen zu können. Dass man nur ein einziges Mal einen Code erstellen muss und mit diesem beliebig den Hersteller wechseln kann, ohne alle Seiten erneut anfassen zu müssen.

Für die Anwender von Web-Analytics-Tools wäre das perfekt. Die Realität sieht jedoch anders aus: Wenn man erst einmal fachlich geklärt hat, was man messen möchte, dann implementiert man häufig mit hohem Aufwand.  Wenn dann ein Wechsel des Tools ansteht, wie es für einige Sites beispielsweise beim Verschwinden von HBX notwendig war - oder weil sich herausstellt, dass das bisherige Tool neue Anforderungen nicht abdeckt -, dann hat man diese Kosten und die Mühen erneut.

Das Problem: Die heutige Lösungen sind sehr herstellerspezifisch. Und die Anbieter von Web-Analytics-Systemen scheinen Interesse daran zu haben, dass alles so bleibt wie es ist. (Siehe auch unseren Blogbeitrag “One Tag to Rule Them All oder das Über-Tag”)

Das Entwickeln eines “Universal Tag” - hat ein solches Vorhaben überhaupt eine Chance? Gegenfrage: Warum nicht? Wenn…

• Plugins dazu führen können, dass Browserhersteller deren Funktionalität komplett übernehmen,
• es Javascript Libraries gibt, deren Funktionen ein Browser bereitstellen wird,
• sich CD, DVD und Blu ray herstellerübergreifend normieren liessen,

… dann sollte doch wohl die Normierung eines “Universal Tag” machbar sein. In einem ersten Schritt reicht es, eine Normierung zu bestimmen und festzulegen: Sobald sich dann zwei Hersteller fänden, die diese teilweise erfüllten, hätten deren Kunden einen kleinen Vorteil. Denn sie hätten eine alternative Lösung, die - mit etwas geringerem Aufwand - implementierbar wäre. Wenn ein Toolwechsel ansteht, könnte dies den Ausschlag für oder gegen eine Kaufentscheidung geben.

Nur: Irgendwer muss anfangen, sonst wird es nie Realität (wie es Ian Thomas “Whence the Universal Tag?” treffend beschreibt). Deshalb möchte ich erste Vorschläge machen, wie eine allgemeingültige, Tool unabhängige Implementierung aussehen könnte:

Die folgende Liste soll ein Superset darstellen, also die Vereinigungsmenge der bisherigen Inhalte. Sie ist unvollständig und sollte selbstverständlich und gerne diskutiert und erweitert werden. Jedes Web-Analytics-Tool unterstützt Teile folgender Spezifikation:

A. DIMENSIONEN

1. Die Websites

• Diese sollen nach verschiedensten Gesichtspunkten gruppiert und untersucht werden können (zum Beispiel Seitennamen, Navigationsbereiche, Partnerintegrationen etc.).
• Da man diese nicht von vorneherein festlegen kann, braucht man eine erweiterbare Liste von Seiteneigenschaften (Dabei ist es gleich, ob man sich für die Farben der Seiten, Templatenamen oder den Vornamen des Programmierers der Seite interessiert).
• Ob diese nun bisher Documentgroup, Channel oder prop42 hiessen, spielt keine Rolle.

2. Visitors

• Besucher haben Eigenschaften, nach denen segmentiert werden sollte. Ein Ziel kann sein, dass man herausfinden will, bei welchen Kunden man gut ankommt, bei welchen weniger.
• Auch hier gilt: Man muss jederzeit neue Eigenschaften der Besucher erfassen können. Die Eigenschaften umfassen unter anderem alle technischen Ausstattungsdetails wie Browser, Betriebssystem, Java-, Flash- etc. -Ausstattung (aber auch typischerweise abgefragte Informationen aus Formularen wie Postleitzahl, Alter, Geschlecht). Da man Visitors nicht browserübergreifend identifizieren kann, ist der Browser für mich eine Visitoreigenschaft.
• Eine wichtige Benutzereigenschaft ist das Werbemittel, das ein Besucher benutzt hat, um auf die Website zu gelangen.

3. Visits

• Ein Visit braucht keine eigenen Daten im Tag selbst.
• Visit-Start und -Ende werden nicht im Tag, sondern im Backend markiert.
• Damit werden die Visitdaten auch aus den Besucher- und Seitendaten geholt.
• Eigene Tag-Bestandteile sind nicht nötig.

4. Produkte

Dazu gehören der Inhalt eines Warenkorbs, angesehene und gekaufte Artikel für Cross-Selling-Analysen etc.

• Eigenschaften dieser Artikel wie Farben, Größen und das Sortiment, zu dem es in meinem Shop gehört.
• Diese Eigenschaften sind wie die Besucher- und die Seiteneigenschaften nicht statisch, sondern müssen flexibel erweiterbar sein.
• Vielleicht will ich ja morgen einen Partner in meinen Shop integrieren und brauche dann eine Partner-ID am Produkt? Das Geschäft kann dann nicht auf die Web-Analytics-Lösung warten.

B) METRIKEN

• Alles, was ich irgendwie zahlenmäßig erfassen will, benötigt einen Zähler.
• Auch hier gilt: Beliebig erweiterbare Arrays mit Namen und Werten erscheinen geeignet.
• Informationen über die numerischen Datentypen und deren einzelnen Felder sollten im Backend hinterlegt sein und gehören nicht in ein Tag.

Grundsätzlich sollte man zwei Gruppen von Metriken unterscheiden:

1. Besuchermetriken: Wenn der Besucher zählbare Dinge tut, die nicht direkt mit Warenkorbinhalten zu tun haben, zum Beispiel Newsletterregistrierungen oder Klicks auf bestimmte Links, die zählenswert erscheinen. Sogar eine PageImpression oder ein Werbemittel-Clickthrough kann dazu gehören. Aber auch die Eindringtiefe in Conversion Funnels und Szenario-Analysen beliebiger Art sind damit möglich. Die Einstellungen zu den Szenarios gehört meines Erachtens ins Backend. Der Klarheit halber sollten sie im Visitor-Array mit untergebracht werden.

2. Produktmetriken: Hier werden Bestellungen, Stückzahlen, Preise einzelner Produkte im Warenkorb zugeordnet. Selbstverständlich scheint mir, dass sie an den entsprechenden Warenkorb-Positionen hängen sollten.

Fazit: Das eine Tag muss alles unterstützen, was die heutigen, herstellerspezifischen Tags in Summe abbilden. Ich bitte um eifrige Beteiligung, um die Liste abzurunden.

In einem weiteren Artikel werde ich mich mit den Themen Darstellung und Transport eines Universal Tags beschäftigen.

Regelmäßiges Vertster Webinar - Mehr Erfolg durch Marketingeffizienz

Wer Online-Erfolgskontrolle heute professionell betreibt, kommt um das Thema Testen nicht mehr herum. Als exklusiver Partner von Vertster in D/A/CH möchten wir Sie einladen, die Vorteile von Vertster kennen zu lernen.

Erster Termin: Webinar 1: Donnerstag, 3. Dezember 2009, 16:00 bis 16:45 Uhr

Regelmässiges Vertster Webinar - jeweils letzter Donnerstag im Monat ab 16:00 Uhr:

• Webinar 1: Was ist Vertster, was sind A/B Tests - Beispiel A/B Test
• Webinar 2: Was ist Vertster, Auswertung eines A/B Tests
• Webinar 3: Was ist Vertster, was sind MV-Tests, Beispiel MV-Test
• Webinar 4: Was ist Vertster, Auswertung eines MV Tests mit Vertster

Nächstes Webinar: Donnerstag, 28. Januar 2010; 16:00 bis 16:45 Uhr

Zugangsdaten zum Webinar:

Laden Sie sich die Präsentationssoftware von nachfolgendem Link herunter, speichern sie diese und starten sie den Präsentations-Client

Geben Sie dann im Eingangsdialog die folgenden Zugangsdaten ein:

Sitzungsnummer:   761830

Sitzungspasswort: vertster

An der parallel stattfindenden Telefonkonferenz nehmen Sie teil, indem sie eine der nachfolgenden Nummern anwählen

Deutschland: 01805-007644 (14 ct/min)

Österreich: 0820-40001578 (12 ct/min)

Schweiz: 0848-560198 (12 Rp./min)

contentmetrics - Service und Software aus einer Hand

Nutzen Sie die Vorteile der Testing-Software Vertster und unsere Erfahrung: einfache Handhabung - flexible Vertragslaufzeiten - einfaches Abrechnungsmodell nach Testteilnehmer sowie die Unterstützung durch das contentmetrics-Team, erhöhen Ihren Erfolg im Marketing nachweislich!

Wir freuen uns auf Sie!

Einfache A/B und multivariate Tests - contentmetrics übernimmt exklusive Vermarktung von Vertster

Ab sofort ist contentmetrics exklusiver Vermarkter von Vertster, einem Tool für A/B und multivariate Tests des US-Unternehmens U-Pro, in Deutschland, Österreich und der Schweiz. Zudem unterstützt contentmetrics die Anwender des Produkts im D/A/CH-Gebiet durch Consulting und Support-Dienstleistungen.

Wir sind sehr stolz auf die Zusammenarbeit mit U-Pro, denn Vertster ist eine extrem leistungsstarke SaaS-Lösung (Software As A Service, ASP), mit der Websites optimiert und die Marketingeffizienz erhöht werden kann. Daher stellen wir Vertster in diesem Blogbeitrag näher vor:

Vertster bietet standardmäßig folgende Testvarianten an:

• Baseline Testing
• URL Split-Testing
• A/B Split-Testing
• Multivariates Testing mit und ohne Taguchi Methodik

Vertster lässt sich ohne kompliziertes Programmieren leicht in Websites integrieren. Somit können Online-Marketing und Product-Management selbstständig - also unabhängig von IT-Ressourcen und Website-Deployments - Kampagnen steuern und beliebige Website-Inhalte und Rezepte austauschen.

Vertster ist mandantenfähig und eignet sich daher für Agenturen, die im Auftrag ihrer Kunden mehr Effizienz im Marketing erreichen wollen. Zudem können Agenturen das User Interface von Vertster ihrem Corporate Design anpassen.

Die Abrechnung erfolgt auf Basis der Testteilnehmer (Unique Visitors) - und nicht wie bei vergleichbaren Produkten nach Anzahl der ausgelieferten Rezeptseiten (Pageviews) und Werbemittel. Anwender, Betreiber und Marketiers können dadurch im voraus wesentlich genauer kalkulieren.

Für alle Interessenten, die Vertster kennenlernen möchten, bietet contentmetrics Leistungspakete für kurze Zeiträume und kleine Volumina in kalkulierbaren Modellen an. Erste Produktinformationen sind verfügbar über www.vertster.eu oder treten Sie direkt mit uns in Kontakt.

Übrigens: Der Name “Vertster” setzt sich zusammen aus den Begriffen “conVERT und teSTER“.