smartmetrics

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“.

contentmetrics führt REQB-System für methodisches Anforderungsmanagement ein

Website-Betreiber sind ständig gefordert: Ununterbrochen müssen sie ihre Online-Angebote den geänderten Bedingungen des Marktes und dem Verhalten der Besucher und Nutzer anpassen. Das Gleiche gilt für Web-Analytics-Lösungen - auch diese müssen jederzeit den neuen Anforderungen und Veränderungen entsprechen. Die dazu nötige Wachsamkeit ist eine sehr anspruchsvolle Aufgabe, die viele Unternehmen allein nicht meistern können.

Um unsere Kunden dabei zu unterstützen, haben wir nun das Anforderungs- und Change-Management-System “Contour” eingeführt - ein System zur software-gestützten Erfassung und Speicherung von betriebswirtschaftlichen, technischen und nicht-funktionalen Anforderungen. Hierbei setzt contentmetrics REQB-Methoden (des “Requirements Engineering Qualifications Board”) ein. Diese gewährleisten hohe Qualität bei gleichzeitiger Transparenz und Nachverfolgbarkeit - insbesondere diese ist in Web-Analytics-Projekten von entscheidender Bedeutung. Unsere Berater wurden dazu in methodischem Requirements Engineering und Management geschult und zertifiziert (REQB® Certfied Requierements Engineer).

Die Vorteile des REQB-Verfahrens und “Contour”:

• Langfristig garantiert diese methoden- und toolgestützte Vorgehensweise über einen langen Zeitraum den Support der von uns entworfenen Lösungen sowie das Change Management .

• Durch den direkten Web-Zugang wird eine direkte Kollaboration aller Projektbeteiligten in einem zentralen Repository auch von unterschiedlichen Standorten aus möglich. Eine Systemprotokollierung und reversible Versionierung aller Elemente sorgt für eine lückenlose Nachvollziehbarkeit.

• Neben einer Erhöhung der Effizienz aller Projektbeteiligten wird bei der Erarbeitung der Anforderung und der Erstellung der notwendigen Konzepte eine qualitative Verbesserung der Projektergebnisse erreicht.

• Ein Problem der Web Analytics - die langfristige Nachvollziehbarkeit von Änderungen und Anpassungen - kann direkt gelöst werden. So ist es nicht erforderlich, dass Kunden über eigene Excel-Listen ihre betriebswirtschaftlichen und technischen Anforderungen aktuell halten. Stattdessen werden die Anforderungen und deren Änderungen - auch losgelöst von uns - direkt ins Repository eingepflegt und können in austauschbaren Formaten (MS Office, PDF) kommuniziert werden.

Unsere Kunden könnten sich direkt auf unserer Website anmelden. Wer noch keinen Zugang hat oder das Passwort vergessen hat, kann sich gerne direkt an seinen Projektleiter bei contentmetrics wenden.