Wer seinen Online Shop basierend auf den Standardtemplates des Collmex-Shops betreibt, kann den Weg der Besucher zwischen Warenkorb und Bestellabschluss nicht nachvollziehen. Auch die Rückverfolgung eines Kaufs zur Quelle ist in Google Analytics in diesem Fall i. d. R. nicht ohne Mühen möglich. Beide Lücken können geschlossen werden, wenn dazu eine "Brücke" zur Messung auf dem eigenen Server verwendet wird.

Der "geliehene" Checkout und seine Folgen für die Webanalyse

Die Ursache ist die technische Basis des Collmex-Shops: Er besteht auf der einen Seite aus auf dem eigenen Server abgelegten Dateien, die alle Seiten, Kategorieübersichten und Produktdetailseiten bilden. Aber nach einem Klick auf "Bestellen" verlässt der Besucher den durch die Standardimplementierung von Analytics in den Seitentemplates abgedeckten Bereich. Erst wieder auf der Bestellabschluss-Seite - und das nur bei Aktivierung des Transaktionstrackings im Template - wird ein weiterer Hit in Analytics ausgelöst: Die dann vom Collmex-Server ausgelöste Transaktion. Dazwischen klafft eine Lücke im Tracking.

Der Inhalt der Abschluss-Seite Seite stammt - wie alle Schritte des Checkouts und der Warenkorb selbst - aus einem iFrame, dessen dynamische Inhalte vollständig vom Collmex-Server ausgespielt und über die Templates in eine Rahmenseite inkl. Navigation etc. eingebunden sind. Die Shop-Templates erlauben zwar eine Gestaltung dieser Inhalte, aber für das Tracking ergeben sich durch diese Aufteilung auf zwei Server mehrere Probleme:

1. Wer die Inhalte der Frames messen will, kann zwar mit einem Trackingcode in den jeweiligen Seiten Daten an Analytics senden und mit genug Mühe auch die Sitzung beim Wechsel erhalten, bekommt auf diese Weise aber reichlich kryptische URLs in den Seitenbericht.
2. Auch fängt man sich auf diese Weise Doubletten ein, die entsprechende Sonderbehandlung erfordern.
3. Alles was im iFrame passiert, passiert auf einem anderen Host. Viele Filter, die z. B. zu Spamschutzzwecken genutzt werden, lassen Daten ohne Anpassung nicht bis in die Datenansicht durch.
4. Damit die Transaktion eine Chance hat, der ursprünglichen Trafficquelle zugeordnet zu werden, muss collmex.de unbedingt in die Verweis-Ausschlussliste in den Einstellungen der Property.
5. Durch das Fehlen der Schritte im Checkout ist eine Beobachtung und gezielte Optimierung schwierig. Trichter können nicht eingerichtet werden... und auch die Gestaltung von Zielen ist ohne einen entsprechenden Seitenaufruf ein Problem.

Die iFrame-im-iFrame-Lösung

Um ein durchgängiges Tracking vom eigenen Server ohne Cross-Domain-Tracking oder andere Mittel umzusetzen, müssen die Seitenaufrufe im Collmex-iFrame separat messbar gemacht werden. Hierzu wird eine Seite auf dem Server des Shops genutzt, welche mit entsprechenden Parametern aus den jeweiligen Inhalten des iFrames aufgerufen wird. Das kann als Verweis auf eine Ressource wie ein Bild geschehen... oder einfach als "leerer" Bereich innerhalb eines weiteren iFrames. Stellt man sich einen iFrame wie ein Fenster in einer Website vor, in dem man auf eine andere Webseite sehen kann, dann hat man mit dieser Methode eine Seite auf dem eigenen Server, die in einem Fenster den Inhalt der Collmex-Shopserverseite zeigt, in der ein weiteres Fenster ist, durch das man wieder die den eigenen Server sieht. Verwirrend? Dann hilft das hier sicher:

Der dunkelblaue Bereich außen ist die statische Seite (hier: die Warebkorbseite), die auf dem eigenen Shopserver liegt. Dynamischer Inhalt wie z. B. der Warenkorb kommen aber vom Collmex-Server (hellblau) und kann nicht gemessen werden. In diesen Bereich wird über einen weiteren iFrame die Trackingseite aufgerufen, die wieder (dunkelblau) auf dem eigenen Shopserver liegt und die Messung erlaubt.

Parameter übergeben dabei die "Wunsch-URL" der jeweiligen Seite. Im Fall eines Kaufabschlusses werden auf die gleiche Weise alle Informationen zur Transaktion an die Trackingseite übergeben, so dass alle Messungen vom eigenen Server stammen.

Exemplarische Trackingseiten zum Download

Sowohl für die Nutzung von direkt implementiertem Tracking als auch für die Verwendung mit dem Google Tag Manager haben wir entsprechende Vorlagen für die Trackingseite auf Github bereitgestellt. Die Trackingseiten senden - passend angesteuert - Seitenaufrufe im Checkout-Prozess... und am Ende des Bestellprozesses auch die Transaktion inkl. der bestellten Produkte.

Einbinden der Trackingseiten in das Template

Im Collmex-Standardtemplate shopframe_template.txt werden alle Inhalte des Checkouts inkl. des Warenkorbs und der Abschluss-Seite über "Felder" definiert. Es handelt sich dabei um die folgenden Bereiche:

• Cart []
• CartEmpty []
• CartBillToAddress []
• CartShipToAddress []
• CartOrder []
• CartOrderConfirmation []

Vor allem die fett markierten Schritte Warenkorb, Rechnungsadresse, Bestellübersicht und am Ende die Bestellbestätigung als Schritte eines Trichters und Ende eines Zielprozesses sollten mit einem Trackingcode angereichert werden. Dazu ergänzt man im HTML-Inhalt der jeweiligen Bereiche zwischen den eckigen Klammern; idealerweise am Ende vor dem schließenden </body>-Tag.

Das kann z. B. im Fall des Warenkorbs so aussehen:

<iframe height="10" frameborder="0" width="10" src="https://www.mein-beispielshop.de/track-checkout.html?step=Warenkorb"></iframe>

Auf diese Weise können auch alle anderen Schritte mit "Messframes" versehen werden. Der Parameter step=xxx enthält dabei die gewünschte Bezeichnung des Schritts, der als Seite /Checkout/xxxx (also im obigen Beispiel /Checkout/Warenkorb) an Analytics gesendet wird.

Der Bestellabschluss

Im Fall der Abschluss-Seite sind neben dem Namen des Schritts ein paar Dinge mehr zu übergeben: Die Transaktionsnummer, der Betrag und auch der Inhalt des Warenkorbs müssen ebenfalls von A nach B. Vor allem die Produkte im Warenkorb inkl. Preis und Anzahl erfordern ein wenig Vorbereitung, um diese in eine Zeichenkette zu verwandeln, die als Parameter an die Trackingseite übergeben werden kann. Dort wird die Zeichenkette wieder in "Warenkorbzeilen" umgewandelt, welche als Positionen der Transaktion an Analytics gesendet werden.

Damit der Warenkorbinhalt aufbereitet werden kann, werden die beiden Felder GoogleAnalyticsEcommerceTracking [] und ConversionTrackingItem[] verwendet. Folgende Definition "verpackt" die Produkte in eine Zeichenkette gmsItemString, die dann auf der Abschluss-Seite als Parameter genutzt werden kann:

Um im Bestellabschluss neben dem Seitenaufruf auch die Transaktionsdaten zu übertragen, wird der iFrame diesmal per Script "zusammengebaut" und bekommt mit id für die Transaktionsnummer, am für die Bestellsumme und items für die vorher zusammengepackten Produkte ein paar Parameter mehr als in den anderen Schritten. Das kann dann im Feld CartOrderConfirmation [] so aussehen:

Hinweis zur ersten Zeile des Scripts: Diese dient dazu, ggf. in den Produktbezeichnungen enthaltenen "?" oder "&" zu eliminieren, da ansonsten die Übertragung als Parameter scheitert. Wenn dieser Block in ein Template kopiert wird, ist es erforderlich, die schließende eckige Klammer "]" zu verdoppeln, da ansonsten vorzeitig die Definition der Templatevariable beendet wird. Aus "]" muss also "]]" werden.

Sind diese Anpassungen im Shopframe-Template vorgenommen, muss noch die für die eigenen Bedürfnisse passende Trackingseite track-checkout.html konfiguriert (Property-Id eintragen; siehe Kommentare zum Script auf GitHub) und auf dem eigenen Server abgelegt werden. Wird der Shop dann hochgeladen - es genügt der Upload einer einzelnen Seite oder eines Produkts über die Collmex-Oberfläche -, landen künftig alle erreichten Schritte eines angefangenen Einkaufs in Analytics und können dort entsprechend ausgewertet werden.

Auch ein passender Zieltrichter kann nun eingerichtet und ausgewertet werden. Wichtig ist allerdings, wie oben beschrieben collmex.de in die Verweisausschlussliste zu nehmen, um erreichte Ziele und Transaktionen dem richtigen Kanal zuzuordnen.

Nutzung der Tag Manager Fassung

Wer statt des direkten Trackings die "GTM-Fassung" der Trackingseite nutzt, kann über die beiden Datenschichtvariablen vPageTitle und vPageURL die gewünschten Angaben eines Seitenaufrufs einlesen und in einem Pageview-Tag übertragen. Für einen Trigger löst die Trackingseite das Event updVirtualPageView aus.

Im Fall einer Transaktion kommen zu den Daten des Seitenaufrufs noch die für eine E-Commerce-Transaktion erforderlichen Angaben. Das Event heißt hier orderSuccess, das demnach als Auslöser für ein Transaktions-Tag und für den virtuellen Seitenaufruf der Abschluss-Seite genutzt werden sollte.

Ist das alles?

Nein, natürlich nicht. Die Beispiel-Trackingseiten können beliebig ausgebaut werden und z. B. auch Events beim Ausfüllen der Formulare; Verwenden eines Gutscheins oder beliebiger anderer Gelegenheiten genutzt werden. Auch der Einbau erweiterten E-Commerce-Trackings ist denkbar, so dass auch ausgewertet werden kann, welche Produkte ggf. noch vor dem Auflösen des Warenkorbs daraus verschwinden. Das Prinzip bleibt aber immer das Gleiche: Die Messpunkte werden an die Trackingseite übergeben und von dort aus "direkt" (statt über den Collmex-Server) an Analytics gesendet. Alle Lücken im Tracking sind damit bei Bedarf zu schließen.