Tech Tip: Fehlersuche

Wie debugt man eigentlich SiteCatalyst?

Manchmal sieht man sich einen Report an und denkt: „Da stimmt doch was nicht…“ Oft ist das der Beginn einer tieferen Analyse, an deren Ende man seine Visitors besser versteht und mehr über seine Website gelernt hat.

Manchmal bleibt aber auch dieses ungute Gefühl, man vertraut den Daten nicht und man kann sich einfach nicht erklären, was da passiert.

In solchen Fällen ist es an der Zeit, SiteCatalyst zu debuggen.

Nun ist SiteCatalyst ja eine Plattform, also gehostet. Man hat auf das Backend als Kunde keinen direkten Zugriff. Wie kann man da debuggen?

Mir fallen zwei Möglichkeiten ein: Beim Senden der Daten und Testtraffic. Darüberhinaus gibt es für Kunden die Data Warehouse haben noch die Möglichkeit, über Data Feeds an die Rohdaten zu kommen, bzw. ein Kollege bei Adobe kann sich Debuglogs ansehen.

Datenversand Debuggen

In den allermeisten Fällen trackt SiteCatalyst mittels Javascript direkt vom Browser des Besuchers aus. Das ist gut, denn es bedeutet, daß man mit dem eigenen Browser und ein paar Zusatzools genau verfolgen kann, was getrackt wird.

Es gibt eine ganze Reihe frei verfügbarer und bezahlter Tools, die beim Debuggen wertvolle Dienste leisten.

Am Anfang der Liste steht der Digital Pulse Debugger, den man im Browser einfach als Bookmark installiert. Knowledge Base Artikel 534 beschreibt wie das geht und wie man ihn benutzt.

Der große Vorteil: Der Debugger „versteht“ den gesendeten HTTP Request und dekodiert ihn, sodaß man nicht überlegen muß, was die einzelnen Komponenten wohl bedeuten mögen.

Für gelegentliches Debuggen ist der Digital Pulse Debugger mein Mittel der Wahl.

Wer sich für das Web als Technologie interessiert, wird sicher schon einmal mit Firebug, Chrome Developer Tools, Opera Dragonfly oder der IE Developer toolbar geabeitet haben.

Allen diesen Tools ist gemein, daß sie den Trackingrequest anzeigen, also die URL die der Browser per HTTP GET zum Trackingserver sendet. Unterschiede gibt es bei der Analyse der Parameter in der URL.

Ich persönlich mag Firebug am liebsten, da er die Parameter einzeln auflistet, Cookies auflistet, und weil man über das Plugin „omnibug“ (ein Plugin für ein Plugin…) die Anzeige noch weiter vereinfachen kann.

Wer Klicktracking debuggen will oder über mehrere Seiten hinweg, der wird mit den Bordmitteln der Browser nicht glücklich werden. Für diese Fälle sind eher Proxies geeignet, z.B. fiddler oder Charles.

Ich persönlich benutze letzteren, was sicher auch damit zusammenhängt, daß früher Omniture und jetzt Adobe eine Lizenz dafür haben.

Mit Charles kann ich den Traffic aufzeichnen und später nach Belieben untersuchen. Ich kann filtern und so gezielt nach den Trackingrequests suchen (Tip: nach „b/ss“ filtern, siehe Screenshot). Ich kann mir die Requests in der Reihenfolge ansehen, in der sie gesendet wurden.

Der Clou: Ich kann die Requests manipulieren!

Charles bietet als Proxy zwei unschätzbar wertvolle Tools:

1. Die Möglichkeit, Requests zu editieren und zu wiederholen, interaktiv.
2. Einen Weg, dem Browser veränderte Dateien unterzuschieben, ohne daß er es merkt.

Insbesondere das zweite Feature, „Map Local“ genannt, ist eine wahre Goldgrube für jeden Web Analysten oder Implementierer: Man kann Teile einer Website lokal ändern und dem Browser dann die geänderten Varianten ausliefern. Das ist während der Entwicklung und bei der Fehlersuche Gold wert.

Aber was bedeuten die ganzen Parameter in der URL?

Die Dokumentation zum Digital Pulse Debugger enthält eine Liste der URL Parameter. Wichtig sind eigentlich hauptsächlich die Parameter namens cXX, vXX, g und r.

• g – s.pageName oder der Name der getrackten Seite.
• r – der HTTP Referer (sic!) Header, falls es einen Referrer gab.
• cXX – entspricht propXX. c2 ist z.B. s.prop2.
• v0 – s.campaign oder der Tracking Code für Kampagnentracking.
• vXX – ist eVarXX. v23 wäre s.eVar23.

Damit haben wir die Tools und das Wissen zu überprüfen, ob auf den Seiten unserer Website die richtigen Daten gesendet werden. Meist reicht das schon aus, man findet einen oder mehrere Fehler nach der Reparatur sehen die Daten schon plausibel aus.

Testtraffic

Manchmal jedoch werden die Daten anscheinend fehlerfrei zu Sitecatalyst gesendet, die Reports sehen aber dennoch nicht glaubwürdig aus. Dann muß man einen Ende-zu-Ende Test machen.

Das erfordert mindestens vier Schritte:

1. Neue Report Suite für den Test kreieren.
2. Testplan erstellen.
3. Test ausführen, Tracking dabei in die neue Report Suite leiten.
4. Daten in SiteCatalyst mit erwarteten Daten vergleichen.

Ich empfehle unbedingt für Tests eine neue Report Suite zu erstellen!

Wer Tests wie diese macht wird meist ein Problem mit der Integrität der Daten in SiteCatalyst haben. Auf dieser Grundlage hat es keinen Sinn, in eine schon für die Website oder Entwicklung benutzte Report Suite zu testen, man braucht eine 100% saubere Report Suite mit Einstellungen, die der Produktionsumgebung entsprechen.

Anlegen kann man eine solche Kopie über den Account Manager oder ClientCare. Die Kopierfunktion in der Admin Console kopiert nicht alle Einstellungen!

Als nächstes erstellt man einen Testplan. Der muß mindestens zwei Aspekte abdecken: Die exakte Abfolge der Aktionen auf der Website und das exakte Ergebnis, das man in SiteCatalyst erwartet.

Letzteres ist wichtig, denn man neigt dazu, sich im Nachhinein Ergebnisse entweder zurecht zu argumentieren oder sie nicht zu akzeptieren, wenn man nicht vorher schon darüber nachgedacht und festgehalten hat, was man erwartet.

Den Test selber kann man übrigens problemlos mit der Produktionswebsite machen. Es reicht vollkommen aus, wenn man das Tracking in die neue Report Suite umleitet. Das kann man mit Charles, „Map Local“ und einer s_code.js Datei mit angepaßter s_accounts Variable erledigen.

Im letzten Schritt sieht man sich dann in SiteCatalyst die Reports an und vergleicht mit den Prognosen aus Schritt 2.

Wenn etwas nicht stimmt, wendet man sich an ClientCare oder den AM.

Data Feeds und Debuglogs

Ich erlebe oft, daß die Daten in der Transaktionsdatenbank nicht mit denen aus SiteCatalyst übereinstimmen. Weil Daten in der Webanalyse schon aus technischen Gründen nie ganz sauber sein können, ist das bei weniger als 5% Abweichung eigentlich kein Grund zur Sorge, über 10% Abweichung würde ich aber nicht mehr normal nennen.

Data Feeds und Debuglogs gibt es für Report Suites, wenn Data Warehouse zur Verfügung steht. Beide ermöglichen einen Download der „rohen“ Daten. Das geschieht immer für einen Tag, weswegen man meist einen Tag als Beispiel nimmt und dann die Daten aus dem Backend mit Data Feed oder Debuglog vergleicht.

In den allermeisten Fällen stellt sich dabei heraus, daß irgendwo ein technisches Problem das Tracking verhindert, ein Debuglog ist also meist nur der Anfang der Fehlersuche.