How to: Experimente pausieren in Google Optimize

Als Google Optimize neu am Markt war, gab es keine Möglichkeit, laufende Experiment im Optimize Interface zu pausieren. Man konnte lediglich ein Experiment beenden. Wollte man es wieder fortsetzen, musste eine Kopie erstellt werden und diese wurde neu gestartet.

Vor etwas mehr als einem Jahr führte Google eine neue Option ein: Anhalten und Bearbeiten. Leider ist diese nicht ganz so brauchbar, wie ich mir das gewünscht hätte: Zwar spart man sich das Neu-Anlegen des Experiments und man müllt sich das Experiment-Archiv nicht mit dutzenden Versionen zu, aber: alle bisher erhobenen Daten werden verworfen und die Messung beginnt von vorne. Bitter, wenn das Experiment schon einige Wochen lief.

Warum will man das überhaupt?

Dafür kann es mehrere Gründe geben. So könnte mit einer Personalisierung ein Produkt mittels Upselling beworben werden, das kurzfristig nicht verfügbar ist, oder die vorgeschlagene Anmeldung zum Newsletter funktioniert gerade nicht, weil es Wartungsarbeiten am Mailingtool gibt.

Ein Callcenter oder Support Mitarbeiter könnte sicherstellen wollen, dass sowohl er als auch der Gesprächspartner die selbe Version der Website sehen (“Klicken sie auf den grünen Button!” “Welcher grüne Button, alle Buttons hier sind Orange!”).

Der wichtigste Grund, meiner Erfahrung nach, ist aber das Debugging: Auf der Website wird ein Fehler entdeckt und die für die Website zuständige Person will sicher stellen, dass nicht das Optimize Experiment für den Fehler verantwortlich ist, bevor sie sich auf Fehlersuche in den Quellcode begibt.

Global oder Lokal?

Bevor wir uns ein paar Ansätzen widmen, wie man nun Experimente und Personalisierungen pausieren kann, ohne die gesammelten Daten zu verlieren, muss geklärt werden, ob das Experiment lokal oder global pausiert werden soll.

Global heißt hier, dass für alle Websitebesucher das Experiment gestoppt wird, lokal hingegen nur für sich selbst. Im Falle des defekten Newsletterformulars will man das natürlich global machen, bei der Fehlersuche auf der Website reicht es, wenn der Developer das Experiment für sich pausieren kann.

Global: GTM – Tag deaktivieren

Global gibt es nur eine Möglichkeit, das Experiment ohne Datenverlust zu pausieren: dazu muss Optimize kurzfristig deaktiviert werden. Ist Optimize, wie mittlerweile wieder empfohlen, über den GTM eingebunden, ist das leicht: der entsprechende Tag wird im GTM pausiert, der Container veröffentlicht. Fertig. Fällt der Grund für das Pausieren des Experiments oder der Personalisierung weg, wird der Tag wieder aktiviert und erneut veröffentlicht.

Der Nachteil dieser Vorgehensweise: Damit können nicht einzelne Experimente pausiert werden. Wenn andere Experimente oder Personalisierungen laufen, werden diese ebenfalls pausiert.

Und ohne GTM?

Ist der Optimize Tag mittels gtag oder älterem ga-require eingebaut, funktioniert es ähnlich, nur dass der Tag direkt im Quellcode entfernt oder auskommentiert wird, und dann die gesamte Website – oder das entsprechende Template-File auf den Webserver geladen wird. Das ist meist deutlich aufwändiger als die Variante mit dem Google Tag Manager, und wer an Sprints und Release-Zyklen gebunden ist, für den kann diese Option auch gänzlich wegfallen.

Lokal: Google Analytics blocken

Google Optimize ist ein Modul von Google Analytics und ein Experiment wird frühestens gestartet, wenn ein erster Request auf einer Seite an Google Analytics geschickt wird. Das können wir uns zu Nutze machen. Blockieren wir Google Analytics auf einer Seite, wird auch kein Experiment und keine Personalisierung geladen. Oder wir blockieren nur die Optimize-Abfragen selbst, beides führt zum gleichen Ergebnis.

Das Blockieren selbst kann direkt in den Entwicklertools (meist F12) des Browsers geschehen, komfortabler geht es aber mit Browserplugins wie Ghostery oder dem Google Tag Assistant, der ohnehin zur Pflichtausstattung jedes Onlinemarketers gehören sollte.

Wie bei dem Tag Manager Ansatz wird hier Optimize als Ganzes blockiert, nicht nur einzelne Experimente. Vergessen Sie auch nicht, den Block später auch wieder aufzuheben, sonst kann die Fehlersuche beim nächsten Experiment recht lange dauern!

Lokal: Pausieren einzelner Tests mit URL-Parameter

Was aber, wenn wirklich nur ein einzelnes Experiment pausiert werden soll? Auch das geht, aber man muss diese Möglichkeit schon beim Anlegen des Experiments berücksichtigen. Dazu wird bei jedem Experiment in der Sektion “Ausrichtung nach Zielgruppen” eine zusätzliche Auslöseregel definiert. Diese Regel ist vom Typ Suchparameter und besagt: Der Parameter debug ist nicht gleich einem frei gewählten Wert (z.B. der Testnummer in Ihrer Roadmap!). Wichtig ist, dass dieser Wert für jedes Experiment oder jede Personalisierung einzigartig ist. Der Parameter muss nicht debug heißen, Sie können einen beliebigen Namen dafür wählen.

Wenn Sie diese Methode das erste Mal verwenden, müssen Sie sich noch ein neues benutzerdefiniertes Makro für den Parameter erstellen:

Bei ihren weiteren Experimenten und Personalisierungen, steht Ihnen dieses Makro dann bereits zur Verfügung und muss nicht neu angelegt werden.

Rufen Sie nun eine Seite auf und hängen Sie den dafür vorgesehen Parameter daran., z.B.

e-dialog.group/blog?debug=203

Eventuell müssen Sie die Seite noch ein paar Mal neu laden, um Caching zu vermeiden, aber dann greift die Blocking-Regel und auf der so aufgerufenen Seite wird dieses spezifische Experiment nicht ausgespielt.

Variante: Cookie statt Parameter

Der Nachteil an dieser Methode ist, dass sie bei Experimenten oder Personalisierungen, die auf mehreren Seiten ausgeführt werden, den Parameter auf jeder Seite hinzufügen müssen. Gerade bei mehrstufigen Formularen oder Checkout-Prozessen kann das schwierig sein, wenn ein Reload der Seite zurück zum Beginn des Prozesses führt. Wenn Ihr Test in einem iFrame läuft, können Sie an der URL in der Adresszeile des Browsers Parameter anhängen, so viel Sie wollen.

Daher empfiehlt es sich, zumindest für Seiten, die in iframes geladen werden oder Experimente, die auf mehreren Seiten ausgespielt werden, Cookies statt Parameter zu nutzen. Die Vorgehensweise ist gleich wie beim Block-Parameter, nur wird eben eine Regel vom Typ Eigenes Cookie statt Suchparameter erstellt. Auch hier müssen Sie beim ersten Mal ein Makro definieren, indem der Name des Cookies festgelegt wird.

Wollen Sie nun ein bestimmtes Experiment blockieren, setzen Sie sich einfach selber das dafür vorgesehene Cookie. Am besten im Incognito-Modus, dann müssen Sie das Cookie nach Ihrer Analyse nicht wieder löschen. Um das Cookie zu setzen, nutzen Sie einschlägige Browserplugins wie EditThisCookie oder führen Sie in der Browserconsole (wiederum meist F12) folgenden JavaScript Code aus (angepasst an Ihren Parameternamen und die Test-ID):

document.cookie = "debug=203"

Befindet sich das Experiment in einem iFrame, achten Sie darauf, dass Sie das Cookie für die Domain der geframten Datei setzen. Das erreichen Sie etwa, wenn die geframte Datei direkt in Ihrem Browser aufrufen und dort obigen JavaScript Code ausführen.

Die Luxusvariante: global, einzelne Experimente pausieren

Die Prinzipen von Parameter/Cookie-Blocker führen wir nun im GTM weiter, um eine Möglichkeit zu bekommen, einzelne Experimente global zu pausieren. Dies ist allerdings etwas aufwändiger und Sie werden dabei nicht ganz um (einfachen) JavaScript Code herum kommen.

Die Grundlage dafür ist das benutzerdefinierte Aktivierungsereignis in den Experimenteinstellungen. Standardmäßig ist dies der Seitenaufruf. Hier stellen wir ein eigenes Event ein, ich nehme da mal das vorgeschlagene optimze.activate und hänge noch unsere Test-Kennung 203 dran.

Bei diesen benutzerdefinierten Aktivierungsereignissen handelt es sich um Events, die an den dataLayer des Tagmanagers geschickt werden. Dieses Event lösen wir nun mit dem GTM selber aus, mit einem Tag vom Typ Benutzerdefiniertes HTML:

Als Trigger für diesen Tag wird jenes Event genommen, das auch den Google Analytics Seitenaufruf auslöst. In vielen Fällen wird das der vordefinierte Trigger Alle Seiten sein. Bei vielen Consent Management-Lösungen auch ein eigenes Event, das anzeigt, dass die Zustimmung zum Tracking gegeben oder gelesen wurde.

Damit haben wir die Möglichkeit einzelne Experimente global zu pausieren, indem wir einfach den auslösenden Tag im Tag Manager pausieren.

Aber ganz frei von Nachteilen ist auch diese Variante nicht: zum einen erhöht es die Gefahr des Flackerns, also dass die Veränderungen auf der Webseite für den Besucher sichtbar erfolgen. Denn das Script, das den Bildschirm überlagert, bis Optimize seine Änderungen gemacht hat, greift hier nicht mehr. Daher ist diese Herangehensweise nicht optimal, wenn das Experiment größere Änderungen above the fold macht.

Der Aufwand für diese Methode ist auch deutlich größer als die anderen hier vorgestellten Wege. Damit das Ganze auch schnell und praktikabel angewandt werden kann, sollte der Experimentleiter auch Zugang zum Tag Manager haben und Änderungen veröffentlichen dürfen. Ansonsten besteht die Gefahr, dass die Wege beim Anlegen und Pausieren der Experimente lange werden.

Fazit

Eine optimale Lösung für den Wunsch, Experimente und Personalisierungen ohne Datenverlust, global pausieren zu können, gibt es leider nicht. Es gibt einige Workarounds, mit denen man die meisten Use Cases abfangen kann, diese stellen aber durchaus einen Mehraufwand beim Erstellen des Experiments dar. Insgesamt bleibt daher der Wunsch, dass Google selbst eine solche Möglichkeit im Interface von Optimize anbietet. Aber vielleicht werden unsere Wünsche erhört und in einem der nächsten Updates wird uns diese Funktion nachgereicht?