Erinnert ihr euch an den billigsten A/B-Test-Meiner-Karriere Blogartikel? Nunja, dieser wird jetzt doch keine Ergebnisse liefern.
Faktisch geht es um diesen Test bzw. diesen Blogbeitrag: Der billigste Startseiten-Test meiner Karriere – Setup. Ich wollte damit das Discovery Verhalten meiner Leser, die über die Startseite kommen, verbessern bzw. analysieren. Ich habe den Test, der über Google Optimize im Tag Manager implementiert war, aber nach ein paar Tagen beendet, weil er nicht anständig gelaufen ist, hier der Post-Mortem.
Was hat an dem A/B Test nicht funktioniert?
Die Verteilung im Experiment Setup hat hat nicht korrekt funktioniert. Bereits früh konnte ich erkennen, dass
a) die Verteilung unter den beiden Varianten unpassend war.
b) der Anteil der Sessions, die überhaupt an dem Experiment teilgenommen haben, viel zu gering war. D.h. der Traffic auf der Startseite war deutlich mehr als in den zwei Wochen im Experiment aufgetaucht sind.
Insgesamt lief der Test knapp 1,5 Monate. Im gleichen Zeitraum wurde die Startseite ca. 170 mal aufgerufen. Da sind 52 Experiment Sessions ein zu kleiner Bruchteil – für meinen Geschmack.
Des Weiteren ist mir aufgefallen, dass ich die Challenger Variante nahezu gar nicht reproduzieren konnte, wenn ich meine eigene Seite über ein anonymes Fenster wiederholt versucht habe aufzurufen. Ich konnte die Ursache über dieses Vorgehen irgendwann darauf zurück führen, dass das hinterlegte Szenario ausschließlich für navigierte Sessions, aber nicht für Aufrufe mit der Startseite als Landingpage ausgespielt wurde. Und da liegt am Ende auch die Ursache des Problems.
Warum hat es mit Google Optimize nicht funktioniert?
Die Ursache für das Problem liegt holistisch im Cookie Consent Prozess bzw. darin wie dieser bei mir implementiert ist:
- Zum Zeitpunkt des Ladens der Startseite als Landingpage gibt es meistens noch keine Consent-Entscheidung.
- Das Consent Banner lädt also auf der Default Variante der Landingpage.
- Das Optimize Script ist zu diesem Zeitpunkt noch nicht geladen (weil noch kein Consent dafür vorliegt).
- Gibt der Nutzer sein Consent für das Tool oder dessen Kategorie, lädt das Optimize Script.
- Aber: Bei mir triggered der Consent Abschluss kein Page-Reload. D.h. das Google Optimize Script hat keine Gelegenheit die Challenger Variante mit einem DOM-Reload darzustellen. Entsprechend sieht auch keiner den Challenger.
Dumm gelaufen. Im Endeffekt ist das zusammenspiel der Toolchain hier nicht optimal gelöst (von meiner Seite):
- Google Optimize
- Google Tag Manager
- Borlabs Cookie Consent WordPress Plugin
Liegt eine Consent-Entscheidung vor und navigiere ich z.B. aus einem Artikel auf die Startseite zurück, kann das Optimize Script seine Arbeit wie gewollt verrichten. Diese Session gehen also in das Experiment ein. Leider hilft das nicht, wenn 2/3 der Startseiten Session als erster Seitenaufruf stattfinden.
Way forward: Gibt es einen Fix für das Google Optimize Problem?
Die Frage, ob man das Problem beheben könnte, würde ich mit „Ja“ beantworten. In meinem Kopf sind drei Wege, wie ich das Thema fixen könnte:
- Ich könnte Google Optimize als „funktionales“ bzw. essenzielles Tool im Cookie Consent listen. Damit könnte ich es permanent vor jeder Consent-Entscheidung laden lassen.
- Ich könnte mein Consent Overlay so konfigurieren, dass es einen Page Reload nach der Consent Entscheidung triggered.
- Ich könnte versuchen, Google Optimize über den Consent Mode im Google Tag Manager einzubauen, und mein Consent Plugin entsprechend anpassen, um die Google Variablen darin zu bedienen.
Aber: Ich werde keinen der drei Implementierungswege wählen, weil sich Aufwand, Nutzen und Risiken für mich einfach nicht lohnen. Im Szenario 1 ist mir das rechtliche Risiko zu groß hier zu offensiv mit der Auslegung von „funktional“ zu argumentieren. Szenario 2 und 3 würden bedeuten, dass ich meine Consent-Infrastruktur im Google Tag Manager einmal komplett umstellen müsste. Also: Gar kein Bock.
Das war es. Zur Abwechslung konnte ich mal von einem Fail berichten. Eine Interessante Erfahrung.
