SiteCatalyst 15 – Latency

Von | 23. Februar 2012

Das Thema „Latency in SiteCatalyst 15“ ist zur Zeit sicher der am meisten diskutierte Aspekt der neuen Version. Die schiere Vielfalt der Gerüchte im Umlauf ist erstaunlich. Wir möchten uns daher heute an eine Erklärung wagen.

SiteCatalyst sammelt Daten, verarbeitet und aggregiert sie und stellt am Ende Reports zur Verfügung. Die Verarbeitung ist bei SiteCatalyst 14 anders gelöst als bei SiteCatalyst 15, was die neuen Features ermöglicht aber auch dazu führt, daß der Zeitraum zwischen Empfang eines Trackingevents und Sichtbarkeit sich ändert, also die sogenannte Latency.

„SiteCatalyst 14 ist real-time“

Richtig, teilweise.

Die Datenverarbeitung in SiteCatalyst 14 folgt der Maxime: Berechne sobald es möglich ist.

Als Beispiel: Wenn eine Webseite abgerufen wird und der Browser den Trackingrequest sendet, dann zählt das als ein Page View für diese Seite. Daran ändert sich auch nichts mehr, man kann also diesen Page View eigentlich sofort in Reports anzeigen. Ein Visit hingegen muß zunächst zuende gehen, bevor einige der Metriken oder Reports berechnet werden können.

Das führt dazu, daß bei SiteCatalyst 14 einige Reports praktisch in Echtzeit laufen, z.B. der Site Content > Pages Report. Andere Reports hängen hinterher, z.B. sind alle Visit-basierten Reports immer mindestens 30 Minuten in Verzug, weil ein Visit erst nach 30 Minuten Inaktivität geschlossen wird und dann erst die Datenverarbeitung beginnt.

„SiteCatalyst 15 hat 2 Stunden Latency“

Das stimmt so nicht.

Die Datenverarbeitung basiert auf Batches, d.h. Daten werden zunächst gesammelt und erst später im Block verarbeitet.

Die „Blockgröße“ ist in SiteCatalyst 60 Minuten. Ein Block startet zur vollen Stunde und endet am Ende dieser Stunde. Alle Trackingrequests die z.B. zwischen 11:00:00 und 11:59:59 eintreffen, gehören zum selben Block.

Um 12:00 beginnt dann der nächste Block und parallel dazu die Verarbeitung des eben gefüllten Blocks. Die Verarbeitung sollte bei SiteCatalyst 15 etwa eine halbe Stunde dauern.

Für die Latency, also die Zeitspanne zwischen Trackingrequest und Sichtbarkeit der Daten im Interface bedeutet das:

Ein Trackingrequest, der um 11:00:01 bei SiteCatalyst 15 eintrifft, wird Teil des „11 Uhr Blocks“. Dieser Block wird um 12 geschlossen und zur Verarbeitung weitergereicht. Nach etwa 30 Minuten sollten die Daten des Blocks dann zu sehen sein, also um 12:30 und damit 90 Minuten nachdem der Request ankam.

Ein Request um 11:59:59, auf der anderen Seite wird auch Teil des „11 Uhr Blocks“. Der Block wird um 12:00 geschlossen, also direkt nach Eintreffen des Requests. Die Verarbeitung dauert wieder bis 12:30, die Daten sind also schon nach etwa 30 Minuten zu sehen.

[Screenshot]

Abhängigkeit von Zeitpunkt des Hits und Verfügbarkeit der Daten

Das trifft auf alleMetriken zu, denn der Block wird komplett berechnet. Page Views, Visits, Visitors und alle Success Eventsstehen zum selben Zeitpunkt zur Verfügung.

Notizen

Das Diagram und die Erklärung oben gelten für SiteCatalyst! Das betrifft auch Module die auf SiteCatalyst aufsetzen wie die Reporting API, Excel Client, den Report Builder, Widgets, Dashboard Viewer. Für Data Warehouse und Discover ändert sich in diesem Zusammenhang nichts.

Manchmal braucht man Zahlen sehr schnell, schneller als nach 30 – 90 Minuten. Die Medienbranche fällt mir ein, aber auch Einzelfälle, in denen gerade gestartete Kampagnen sehr schnell analysiert werden sollen falls noch Korrekturen nötig sein sollten.

Wer zu dieser Gruppe gehört sollte vielleicht zur Zeit weiter SiteCatalyst 14 benutzen und noch nicht migrieren.

Ich denke es wird mittel- oder langfristig Möglichkeiten geben, wie auch diese Anforderungen abgedeckt werden. (Ich werde den Artikel entsprechend ergänzen, falls oder wenn es etwas zu ergänzen gibt).

4 Gedanken zu „SiteCatalyst 15 – Latency

  1. Pingback: Update – Latency in SiteCatalyst 15 « Webanalyse auf Deutsch

  2. Pingback: Latency in SiteCatalyst 15 | Digital Europe

  3. Pingback: Alles neu macht der Mai! | Webanalyse auf Deutsch

  4. Pingback: Warum stimmt die Summe nicht? | Webanalyse auf Deutsch

Kommentar verfassen

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