Ich habe ein Problem mit dem Kampagnen-Tracking bei PIWIK. (Genauer genommen sind es mehrere, ich glaube ich bin zu blöd das vernünftig einzusetzen.) Jedoch hier das “größte”:

Ich betreibe beruflich einen kleinen Shop. Der Shop ist auf anderen Websseiten mit Kampagnen verlinkt. Die Besuche werden den Kampagnen (meistens) vernünftig zugeordnet. Wenn nun einer der Besucher ein Ziel errreicht, wird zwar die Konversion gezählt, jedoch in einer zweiten, neuen Kampagne, die den gleichen Namen aber dafür 0 Besuche hat. Das sieht dann in etwa so aus:

PIWIK: Konversions nach Kampagnen mit Koversionen für 0 Kampagnen-Besuche.

PIWIK: Konversions nach Kampagnen mit Koversionen für 0 Kampagnen-Besuche.

Die Zuordnung von Konversionen zu Suchmaschinen, Suchbegriffen und Websites funktioniert jedoch einwandfrei.

Was mache ich falsch?

, , ,

Mit PIWIK kann man ebenso wie bei Google Analytics bestimmte Seiten als Ziel (“Goal“) definieren und somit sich einfach darstellen lassen, ob bestimmte Unternehmensziele erreicht werden, oder was z.B. SEM-Kampagnen für den Online-Umsatz tatsächlich eingebracht haben. Mit den Zielen kann man herausfinden, wie hoch die Wandlungsquote (“Conversion-Rate“) einer bestimmten Maßnahme in bestimmte Aktionen ist. Dabei muss es nicht immer um erfolgreich abgeschlossene Käufe gehen, sondern ein solches Wandlungsziel (“Conversion-Goal“) kann auch die Zahl der neu angemeldeten Nutzer für ein Forum o.ä. sein, die Anzahl der Downloads einer bestimmten Datei, usw.

Im Grunde ist das Verfahren recht simpel: Ich definiere eine Seite, deren Aufruf als Ziel gewertet werden soll. Das Analyse-Tool zählt dann wie gewohnt die Webseiten-Besuche, über welche Keywords und welche Referrer (Webseiten, Suchmaschinen, oder vorher definierte Kampagnen) die Besucher kommen, wie oft ein bestimmtes Ziel aufgerufen wurde und bringt dann diese Daten zusammen. Das sieht dann in der Auswertung bei PIWIK etwa so aus:

PIWIK Ziel-Conversion-Rate

PIWIK Ziel-Conversion-Rate

Nun fiel mir aber auf, dass die Berechnung nicht ganz stimmen kann. Wie man in dem Bild oben sieht, ist nämlich die Wandlungsquote bei weniger Besuchen und gleicher Zahl der Wandlungen niedriger – was ja nicht sein kann! Oder nach Marta Milchmädchen: Wenn von 20 Äpfeln 5 verfault sind, dann ist das ein Viertel. Wenn ich von diesen 20 Äpfeln 5 (noch gute) esse, die 5 verfaulten aber drin lasse, dann sind von der übrigen Menge bereits ein Drittel verfault.

Wenn von 621 Besuchen nun also 5 das Ziel erreichen, sind das rund 0,81% – und eben nicht 0,96%! Das mag zwar kleinkariert klingen, ist aber ein Fehler, der bei großen Zahlen ebenso große Auswirkungen haben kann. Eine Abweichung von immerhin 0,15%, die aber bei den anderen beiden Werten (5 auf 605 und 5 auf 597) etwa gleich ist.

Ich hab mir gedacht: das kann doch nicht sein, dass PIWIK da so einen riesigen Rechenfehler hat! Zur Sicherheit habe ich mir dann die komplette Tabelle heruntergeladen – denn ich weiß, dass hier gerne mehr Werte drin stehen, als in der Auswertung angezeigt werden.

Und siehe da! Ich habe doch die “richtige” Rechengröße gefunden. In der ganz letzten Spalte der zugehörigen Tabelle sind die “Unique Visitors” angegeben. Diese sind bei den drei Zugriffsquellen 523, 597 und 581. Und wenn ich anhand dieser eindeutigen Besucher die Wandlungsquote erneut berechne, was ja auch logisch betrachtet Sinn macht, komme ich auf die angegebene 0,96%, 0,66% und 0,68%.

PIWIK zeigt also in der Standard Ziel-Auswertung die Besuche an und nicht die Besucher, berechnet aber anhand der eindeutigen Besucherzahl die Wandlungsquote eines Ziels. An und für sich betrachtet, ist es korrekt, die Conversion-Rate anhand der eindeutigen Beuscher zu berechnen – In der normalen Auswertungsansicht diese Zahl aber vorzuenthalten und statt dess die Visits anzuzeigen, ist irgendwie … unsinnig!

, , , ,

… tolle Wolle! Jetzt kann ich nicht mehr auf meine Webseiten-Statistiken zugreifen und Einstellungen ändern. Denn ich wollte meine Google-Analytics-Konten mit dem Google AdPlanner verknüpfen – und das schlug, so wie ich mir das dachte, fehl!

Um meine Besucherzahlen im Google AdPlanner freizugeben, müssen die beiden Services bei Google verknüpft sein. Das ist ja nun nicht neues, das ist ja auch das schöne an Google: das alles aus einer Hand laufen kann. Nun wollte der AdPlanner aber partout auf meine Daten mit der Login-Adresse @gmail.com zugreifen und meinte “hier gibt’s keinen Analytics-Account. Bitte schalten Sie doch den Account frei.”. Ja, und bei Google bin ich ja für alles mit der Login-Adresse @googlemail.com angemeldet.

Also habe ich kurzerhand für mein Analytics-Profil meine eigene Email-Adresse mit eben der anderen Domain freischalten wollen. Habe aber in einem Anflug von Schwachsinnigkeit und Unaufmerksamkeit diese Adresse nur als Nutzer mit Ansichts-Rechten (eben nicht als Administrator) angegeben. Und noch bevor ich das für das zweite Blog hinzufügen konnte, wurde ich zurück in die Übersichtsmaske geleitet, wo ich für die Blogs nichts mehr “Bearbeiten” kann. Verdammte Axt!

Ich bin mal gespannt, was der GA-Support sagt. Habe direkt das Mail-Formular ausgefüllt.

Das ärgert mich, dass Google seinen eigenen Kontoscheiss nicht richtig auf die Reihe kriegt!

, ,

Vor kurzem hatte ich erwähnt, dass dass Tracken der Downloads nach dem anonymisieren der IP-Adressen nicht mehr funktionierte. Das Problem scheint nun gelöst zu sein.

Schuld daran war nicht, dass die IP-Adressen abgeschnitten wurden, sondern der Tracking-Code auf den asynchronen umgestellt wurde. Denn statt des onClick-Befehls javascript: pageTracker._trackPageView wird jetzt ein anderer Code dem Anchor-Tag hinzugefügt:
<a href="#" onClick="_gaq.push(['_trackEvent', 'category', 'action', 'label', 'value']);">Linktext</a>
Denn leider ist nach wie vor nur mit Hilfe des onClick-Aufrufs das Zählen von Dateiaufrufen möglich, die den Tracking-Code nicht originär enthalten (im Grunde alles, was keine HTML-Seite ist). Aber wie auch mit dem alten Tracking-Code kann man nach wie vor ausgehenden Traffic tracken (alle Links zu externen Seiten, die den eigenen Tracking-Code logischerweise nicht enthalten).

Die Syntax kurz erläutert

  • _gaq.push – ruft das JavaScript auf
  • _trackEvent – der Befehl, der ausgeführt wird
  • category – Die Kategorie, die dem Klick zugewiesen werden soll. Sie ist frei definierbar und wird als solche später im Auswertungsmenü angezeigt. Die kategorie zu besetzen ist Pflicht (sonst wird’s nicht gezählt).
  • action – Die Aktion, die aufgezeichnet werden soll. Sie ist auch frei definierbar und wird separat angezeigt. Auch die Aktion ist sozusagen ein “Pflichtfeld”.
  • label – besteht aus ein oder mehreren Schlagworten, um die Aktion näher einzugrenzen. Auch hier kann man frei definieren. Leider kann man nicht mehrer verschiedene Labels einem Event zuordnen. Dieses Feld ist optional.
  • value – Man kann diesem Klick einen Wert zuweisen. Denkbar ist ein Klickwert analog zum CPC, oder sonst irgendwas (man kann mit einer weiteren Ergänzung z.B. die Downloadzeit hier tracken).

Google hat auf seiner Code-Dokumentation ausführlich erklärt, worin sich die einzelnen Werte unterscheiden. Ich finde es jedoch viel schneller einleuchtend, das mal visuell in Google Analytics zu sehen. Über “Content -> Ereignistracking” landet man in der Übersicht, die darstellt, was hier getrackt wurde.

Eventtracking mit Google Analytics: Kategorien und Aktionen

Bereits auf der Übersichtsseite sieht man deutlich, wie sich die definierten Kategorien und Aktionen hierarchisch anordnen. Beide sind zwar nebeneinander auszuwerten, jedoch nicht bis in jede Detailtiefe.

Parameterhierarchie

Kurz und knapp: Es gibt zwei Möglichkeiten.

  1. Kategorie -> Ereignis-Aktion -> Ereignis-Label
  2. Ereignis-Aktion -> Ereignis-Label

Da die zweite hierarchische Anordnung vollkommen redundant ist, gehe ich davon aus, dass sie nur existiert um die zugewiesenen Ereigniswerte anders zusammen zu fassen. Denn der vorher zugewiesene Ereigniswert und der durchschnittliche Ereigniswert werden immer in der zugehörigen Tabelle mit ausgegeben und können somit nur sekundär ausgewertet (angezeigt) werden.

Taxonomie

Man kommt also nicht umhin, sich eine vernünftige Taxonomie auf zweieinhalb Ebenen auszudenken – so viel Gehirnschmalz verlangt Google einem leider ab. Jedoch hat mir die Frage: “Steckt in dem Eventtyp nicht auch ein wenig die Aktion und der Dateityp drin? weiter geholfen. Denn alle weiteren Schlagworte o.ä. fügt man eben als Label ein und muss dann Filtern. Aber vielleicht wird das ja mal weiter entwickelt, so dass man mehrere Tags nebeneinander vergeben und auswerten kann. Denn für meine Bedürfnisse ist es wichtig, die Antworten auf diese Fragen als Informationen in die Auswertung zu transportieren:

  • Download oder Link auf externe Seite?
  • Auf welche Seite führte der Link?
  • Von welcher Seite wurde der Link angeklickt?
  • Welchen Dateityp (=Dateiendung) hat die heruntergeladene Datei?
  • Welcher Inhaltskategorie ist die Datei zuzuordnen? Die Frage ist ein bischen wie “Aus welcher Seitenrubrik kam der Download?”: Pressetext, Produktbroschüre, Teilekatalog, etc. aber auch: Stellenanzeigen
  • Zu welchem Produktsegment gehört die Datei (z.B. Zubehörteile, Werkzeuge oder Materialien)?
  • Zu welchem Produktmarkenbereich/-segment gehört die Datei? (z.B. Consumer/B2B, VW, Audi oder Porsche?)
  • Zu welchem Produkt gehört die Datei? (Golf, Jetta, Passat oder A6, A4, A8)
  • Von welcher Sprachseite aus wurde die Datei heruntergeladen (deutsch, englisch, rumänisch, etc.)? Denn bei uns liegen die Dokumente nur in einer “Sprache” vor: technisch. %)

Für mich stellt sich bei diesem ganzen vertagge und ausgewerte vor allen Dingen eine Frage: Muss ich diese Unmengen an Dateien eigentlich zum Download anbieten? Der Rattenschwanz ist nämlich: regelmäßig aktualisieren mit Text, Inhalt, Bildern und Umbruch, auf den Server hochladen und ggf. neu verlinken. Denn die auszuwertenden Dateien sind überwiegend Broschüren und Listen mit Produktvariationen und -ergänzungen in Form von PDFs. An oberster Stelle also für mich wichtig: welche Inhaltstypen (“Seitenrubrik”) werden wie häufig runter geladen?

Ich habe mir also gedacht, als Kategorie die jeweiligen Seitenrubriken zu verwenden, von denen der Download getätigt wurde: Pressetext, Typenliste (Produktvariationen), Prospekte / Broschüren, Bildarchiv, Software. Einziger Ausreisser ist hier der “ausgehende Traffic”. Das ist aber nicht weiter schlimm, denn es ist eben der einzige.

Als Aktion verwende ich zum einen den Dateitypen (PDF, EXE), bei den Bildarchiv aber feiner unterschieden in “JPG – 300dpi”, “JPG- 72dpi” und “EPS”, oder die URL der Webseite des externen Links (www.domain.com).

Alle anderen Informationen packe ich ins Label. Dort stünde dann z.B. “Audi A6 Zubehör – Baujahr 2006-2008″ oder meinetwegen auch “Kettensägen – mit Elektromotor – STIHL”. Bei Pressetexten nehme ich einfach den Titel der Pressemitteilung, bei Bildern die Bildkategorie und den Titel.

Das einzig müßige an dieser Geschichte ist, dass man den EventTracker in jedem Link manuell hinterlegen muss. Für WordPress gibt es mit dem GoogleAnalytics-Plugin zwar eine Option, das automatisch mit zu übernehmen (man kann hierbei die zu trackenden Dateinamenendungen mit angeben), aber für andere CMS … muss ich mal suchen ;-)

, ,

Ich habe vor kurzem dafür gesorgt, dass bei meinem Unternehmen, das auf seiner Webseite auch Google Analytics einsetzt, Datei-Downloads von z.B. PDF-Dateien mitgezählt werden. Diese werden nämlich von Google nicht standardmäßig erfasst, da in diesen Dateien der Tracking-Code naturgemäß nicht aufgerufen wird.

Zur Zeit nutzt die Seite PIWIK und Google Analytics parallel. Wir wollen erst einmal abwarten, wie sich das mit Google weiter entwickelt. Mittelfristig werden wir auf PIWIK allein umstellen, jedoch sammeln wir hierfür erst einmal Daten um später Vergleiche ziehen zu können. Denn Google Analytics und PIWIK zählen dann doch irgendwie unterschiedlich, womit die Daten miteinander nicht vergleichbar sind.

Hierzu ergänzt man im HTML den Link einfach um den JavaScript-Befehl pageTracker._trackPageview, was dann so aussieht:
<a href="http://www.yourdomain.de/yourfile.pdf" onclick="javascript: pageTracker._trackPageview('/name-unter-der-die-datei-in-GA-auftauchen-soll'); ">Linktext</a>

Das ist genau so eingebunden, wie die Google-Analytics-Hilfe mir das erzählt hat. Es hat zunächst auch ganz gut geklappt und Google hat fein brav die Downloads gezählt.

Nun kam auf anderer Seite hinzu, dass aufgrund der datenschutzrechtlichen Bedenken wir die IP-Adressen mit Hilfe der Tracking-Code-Funktion anonymizeIP abgeschnitten haben. Hierbei wird das letzte Oktett der IPs auf “0″ gesetzt, so dass diese im Zweifel mit 198.178.168.0 angezeigt werden. Das hat zwar zur Folge, dass man die Benutzerzugriffe auf die Seite nicht mehr allzu genau auf den Ort herunterbrechen kann – jedoch ist das selbst bei einer vollen IP-Adresse nicht immer 100%-ig korrekt, denn es wird lediglich der Standort des Einwahlknotens aufgeführt.

Eine genaue Anleitung, wie die IP-Adressen zu anonymisieren sind und was dies zur Folge für die Bestimmung des Zugriff-Ortes hat, gibt es im webalytics-blog. Wir verwenden für unsere Seite den entsprechend angepassten asynchronen Tracking-Code:
<script type="text/javascript">
 
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXXXX-X']);
_gaq.push(['_gat._anonymizeIp']);
_gaq.push(['_trackPageview']);
 
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
 
</script>

Seit dem die Anonymisierung der IP-Adressen in das Tracking-Code-Snippet mit eingebaut ist, werden jedoch die Downloads nicht mehr gezählt. Der Code befindet sich (derzeit noch) am Ende der Seite, dort wo früher der alte Tracking-Code stand. Der sollte immer unten stehen, damit nur Seitenaufrufe gezählt wurden, bei denen die Seite auch bis zum Ende geladen wurde.

Kennt jemand das “Problem”? Liegt es möglicherweise daran, dass der Code am Ende der Seite ist? Oder ist mit der Anonymisierung der IPs keine Download-Tracking mehr möglich? Das in meinen Augen keinen logischen Sinn macht (ausser dass Google sauer ist, weil man ihnen die IPs verheimlicht).

, , ,

Auf (h4)xx0r – wo übrigens auch noch mal eine tolle Erklärung des Alterntiv-Tools Piwik steht, die ich gestern schon mit erwähnen wollte aber den Link zwischendrin irgendwie verlegt hatte – las ich heute:

Wer am lautesten schreit…

… ist meistens selbst der Verursacher. So auch im Beispiel von Datenschützer Johannes Caspar. Der hat auf seiner Internet-Seite datenschutz-hamburg.de bis heute selbst noch einen Analytics-Tracking-Code, das hat ein Leser des Internet-Law-Blogs herausgefunden. Das IVW-Tracking-Tool ist ebenso Datenschutz-feindlich wie alles Andere auch. Das wurde aus einer Studie der Xamit bekannt. Außerdem gibt der Datenschützer keinen Hinweis auf der Homepage an, weshalb er sich sogut wie selbst mit Bußgeldern bestückt hat. Klasse, unserer Datenschützer aus Hamburg, ein Beispiel vor Allem voran.

Edit: Achso, Herr Caspar hat sich dazu auch noch mal geäußert. Demnach ist Hamburg.de ein eigenständiges Unternehmen und da die Homepage von ihm über Hamburg.de läuft, gibt es da keine Ausnahme, was den Code angeht. Soweit, so gut. Aber sollte man sich nicht fragen, warum dann Hamburg.de nicht mit gutem Beispiel als öffentliche Einrichtung voran geht?

via h4.xx0r.de

Das ist schon ein Stück weit selbstironisch, was Herr Caspar dort treibt bzw. treiben lässt. Ich glaube ja an das Gute im Menschen und denke mir, dass der arme Herr C. auch nur eine Marionette von Lobbyisten ist. Dennoch, auch für Datenschützer gilt: Erst mal vor der eigenen Haustür kehren!

Anzeige:

, ,

Der Herr Datenschutzbeauftragter-des-Bundeslandes-Hamburg Caspar macht sich wieder einmal wichtig. Er tritt gestern medial wirklsam in der Presse breit, dass der die Gespräche mit Google bezüglich deren Webseiten-Auswertungs-/Statistikdienst “Google Analytics” abgebrochen hat. Und Google antwortet natürlich (wie mittlerweile scheinbar üblich): “Davon wissen wir nichts“.

Herr Caspar möchte, dass Google bei der Sammlung der Daten die IP-Adressen nicht vollständig speichert und ausserdem den (End-)Benutzern – also den Webseitensurfen – die Möglichkeit gibt, der Erfassung grundsätzlich und generell zu widersprechen.

Grundsätzlich frage ich mich, warum überhaupt solche Leute wie Datenschützer sich so wichtig machen. Die wissen scheinbar schon, dass sie eigentlich überhautp nix zu sagen haben und die sowieso keiner hören will.

Aber was kann man gegen die vom machtbesessenen Herrn Caspar, der unebdingt zeigen will, wass er kann, angedrohten Klagen unternehmen? Wie das PC-Magazin WinFuture auf Berufung auf Google-Quellen schreibt, ist das gar nicht allzu schwer:

Auf Wunsch unserer deutschen Google Analytics-Nutzer haben wir mit der Deaktivierungs-Möglichkeit für Browser und der IP-Masken-Methode bereits Maßnahmen ergriffen, um diese Vorgaben zu erfüllen.

via winfuture.de

Scheinbar reicht das Herrn Caspar nicht, oder er weiss nicht so recht, was er da genau von Google fordert und wie diese Forderungen erfüllt werden. Merkwürdig an der ganzen Sache ist zudem, dass ausser Google Analytics aus Sicht der politisch Verantwortlichen scheinbar keine andere Webseiten-Auswertungssoftware betroffen ist. Diese Eigenart fand ich schon bei Google StreetView ziemlich suspekt! Denn hier gibt es definitiv andere Anbieter, die das gleiche machen.

Die Problematik um die IP-Adresse betrifft aber eine Reihe weiterer Tools. So kann Facebook mit seinem “Like”-Button alle Besucher einer Webseite tracken ähnliches gilt für Twitter, wenn dieses dynamisch eingebunden wird. Ein weiteres Problem ist Akismet, was viele Blogs – wir übrigens nicht – einsetzen. Hier werden zahlreiche Angaben beim Kommentieren an einen Server in den USA übertragen und dort gespeichert. Ähnliches gilt übrigens auch für das Plugin WordPress.com Stats was ebenfalls viele Blogger verwenden.

via googlewatchblog.de

Anzeige:

Statt dessen wirft die Androhung eines Rechtsreits – scheinbar besonders unter den Bloggern – die alternative Lösung Piwik auf den Plan. Hiervon hatte ich schon bei der ersten Datenschutzdiskussionrunde anno 2007 gehört. Piwik ist Open Source, kostenlos und mittlerweile wohl auch fast so gut wie Google Analytics. Ausserdem gibt es noch AWStats. AWStats ist aber so Standard-Webserver-Software und hat eine aboslute 90er-Jahre Anmutung.

Eine gute Erläuterung der Hintergründe der Datenschutz-Diskussion mit Google und eine kurze Erklärung zu Piwik gibt’s bei Pixelmechanics.

, ,