Adobe hat vor Kurzem bekannt gegeben, die bisherige Lösung für DTM (Dynamic Tag Management) auslaufen zu lassen, und zukünftig nur noch die von Grund auf neu entwickelte Lösung Launch weiter zu führen. 

Unser Analytics-Experte Patrick Psiuk hat alle Tipps und Best Practices für eine erfolgreiche Migration von DTM zu Launch zusammengetragen. 

Was ist (Adobe Experience Platform) Launch?

Launch, oder genauer Adobe Experience Platform (AEP) Launch ist ein von Grund auf neu entwickeltes System für Dynamic Tag Management.

Neu an der Lösung ist die Offenheit: neben «Tags» für die Adobe-Lösungen Analytics, Target und Experience Platform unterstützt Launch über sogenannte Extensions – ähnlich vorkonfigurierten Templates – problemlos auch Tools von Drittherstellern, unter anderem auch die Tools von Google. 

Wozu braucht man einen Tag Manager?

Tag-Management-Systeme wie Launch oder eben auch DTM werden benötigt, wenn Code Snippets wie Tracking-Codes oder Conversion Pixel in die Website eingebunden werden müssen.

Es muss nur einmal der Standard-Code des Tag-Management-Systems eingebunden werden, die gesamte Konfiguration erfolgt anschliessend im Tag-Management-System – so müssen für Tracking-Anpassungen keine neuen Scripts auf die Website integriert werden, was die IT freut (weil sie keinen Aufwand haben) und somit auch die Marketer (weil sie nicht an IT-Releases gebunden sind, um Anpassungen vornehmen zu können).

5 Schritte für eine erfolgreiche Migration

Adobe DTM ist unterdessen in die Jahre gekommen und soll durch das vor zwei Jahren eingeführte Launch abgelöst werden.

Um eine Migration erfolgreich – das heist ohne Datenverlust, ohne verloren gegangene Variabeln-Konfigurationen und Conversions durchzuführen, sollte man folgende einfachen Tipps befolgen – dann kann (fast) nichts schiefgehen. 

1 – Planen

Planung ist das halbe Leben, und dies nicht ohne Grund. Eine Migration von DTM nach Launch macht man nicht einfach so schnell an einem freien Freitagnachmittag in der Corona-Quarantäne, sonder die will wohl überlegt sein. 

Da mit einer Durchlaufzeit von etwa 6 Monaten zu rechnen ist, sollte das Unterfangen frühzeitig angegangen werden, insbesondere da Adobe ab ende Jahr keine Änderungen am DTM-Tracking-Code mehr zulässt. 

Von einer Migration sind nicht nur IT-Spezialisten – insbesondere Frontend-Engineers wegen der Anpassungen der JavaScripts – betroffen, sondern auch andere Rollen, die mit der Daten-Analyse zu tun haben: Data Analysts, Marketers, und so weiter. All diese Personen sind frühzeitig einzubinden und deren Verfügbarkeit abzuklären. 

2 – Dokumentieren

Dokumentation war nie ein Freund des Analysten (oder von sonst jemandem, wenn wir ehrlich sind). Gerade aber bei einer Migration ist die Dokumentation des Ist-Zustandes sowie jene des Soll-Zustandes nach der Migration absolut essentiell: wie soll sonst überprüft werden, dass bei der Migration nichts Wichtiges vergessen wurde?

Deshalb ist es absolut essentiell – und wir wiederholen es gerne so oft wie nötig – dass vor Beginn der Migration auch der aktuelle Zustand neben dem gewünschten Endzustand penibel dokumentiert wird. 

Wie die Dokumentation auszusehen hat, ist eine Frage des persönlichen Geschmacks. Grundsätzlich genügt ein Excel, das alle wesentlichen Definitionen enthält: Daten-Elemente, Variablen-Deklarationen, Regeln sowie Seiten, die speziell getrackt werden müssen, sowie zusätzlich Pain Points mit DTM, bzw. was man im neuen System gerne besser gelöst hätte. Das wäre sozusagen das Minimum, auf dem aufgebaut werden kann, als Basis zur Weiterführung der Dokumentation in Systemen wie Confluence oder Ähnlichem. 

Dieser Aufwand ist nicht vergeben – neben einer geglückten Migration kriegt man gewissermassen gratis eine aktuelle Dokumentation dazu!

3 – Data Layer überarbeiten

Einiges möchte man vielleicht zukünftig anders, eleganter lösen, als es die bisherige Lösung ermöglicht. Deshalb ist eine Migration ein vernünftiger Zeitpunkt, eine (sanfte) Renovation des Data Layers durchzuführen. Sie verwenden noch keinen Data Layer? Dann ist es höchste Zeit, einen einzuführen! Data Layer ist veraltet? Dann können wir ihn gleich auf den aktuellsten Stand bringen. 

Der Data Layer ist das Kernstück des Analyse-Stacks, da er definiert, welche Daten überhaupt gesammelt werden können, und wie sie zusammengetragen werden. Deshalb ist er vor, während und nach der Migration genau im Auge zu behalten.

4 – Migrieren

Nun kann – endlich! – die eigentliche Migration erfolgen. Es gibt zwei Arten der Migration, eine von Adobe bereits pfannenfertig vorbereitete, sowie eine manuelle Variante: 

Lift & Shift: die automatische Migration beschränkt sich darauf, einen Button zu klicken, und der Rest geht wie von Zauberhand. Das ist praktisch und hilfreich, man hat aber keine Kontrolle darüber, was passiert und noch blöder: Wozu hat man sich all die Pain Points aufgeschrieben, die man verbessert haben möchte? Langer Rede kurzer Sinn: die automatische Migration eignet sich nur für jene, die mit ihrem bisherigen Setup komplett zufrieden sind. 

Die manuelle Migration – ein eigentlicher Neubeginn – ist in den meisten Fällen Lift & Shift vorzuziehen. So kann man die «Leichen im Keller» günstig entsorgen, und kann so Altlasten loswerden, die man nicht mitmigrieren möchte. 

Funktionen können neu und anders – besser – aufgebaut werden: was unter der alten Lösung vielleicht im Nachhinein mehr schlecht als recht implementiert werden musste, kann nun elegant nach neuen Vorgaben gelöst werden. 

Erinnert sich noch jemand an die Dokumentation? Die kann nämlich während dem Aufbau der Lösung parallel mitgeführt und aktualisiert werden. Wird etwas nicht 1:1 übernommen, sondern überdacht und verbessrt, lässt es sich auch einfacher dokumentieren. 

Launch verwendet Extensions, die ähnlcih funktionieren wie Apps oder Templates, die einzelnen Funktionen bündeln und bereits zur Verfügung stellen.  Wir empfehlen die Verwendung existierender Apps anstelle eines Eigenbaus (was es schon in guter Qualität gibt muss nicht nochmals erfunden werden) – doch dies ist Stoff für ein anderes Mal.

5 – Testen, testen, testen

Wohl die meiste Zeit für die ganze Migration ist für das Testing einzuplanen. Bei einem Neuaufbau mit Launch fällt das Testing relativ einfach, da die Anwendung leicht zu überschauen ist. Dennoch sollten mindestens folgende Dinge ausführlich getestet werden: 

• Conversions sind der eigentliche Grund, weshalb Analyse und Optimierung von Websites durchgeführt werden – wäre schade, wenn genau dies nicht mehr funktionieren würde. 
• Die Top-Seiten oder Top-Produkte – also die wichtigsten Seiten/Produkte, auf die man nicht verzichten kann – sind ausführlich zu testen: Funktioniert alles sowohl für den Nutzer wie auch für den Analysten wie gewohnt?
• Die Daten sind auch von der Analytics-Seite her zu betrachten: Ergeben die Zahlen einen Sinn? Sinnvollerweise wird hierfür ein Test-Dashboard aufgesetzt. 
• Der Data Layer sollte ausführlichst geprüft und angeschaut werden. Stimmen die rapportierten Werte? Fehlen Werte oder Definitionen? Wird gar zu viel gemessen, und kann vereinfacht werden?

Beachtet man diese Tipps und geht gründlich vor, kann eigentlich fast nichts schiefgehen. 

Was hat Adobe sich dabei gedacht?

Natürlich ist es mühsam und mit Kosten verbunden, wenn einem der Wechsel von einem Produkt zum nächsten quasi aufgezwungen wird. In diesem Fall lohnt sich der Wechsel aber auf jeden Fall: Der Sprung von DTM zu Launch ist immens, und mit Launch bietet Adobe ein Tool, das seinesgleichen sucht. 

Deshalb ist eine nicht überhastete, durchdachte Migration wie obenstehend aufgezeigt eine gute Sache, und kombiniert mit einem «Ausmisten» des Data Layers und der Einbindung neuer Funktionen einen Schritt in die richtige Richtung. 

Haben wir schon erwähnt, dass dieser auch dokumentiert werden sollte? 😉

Michael Grob

Senior Consultant Digital Marketing