Früher war es so schön einfach, ein neues Tag zu verbauen: Etwas JavaScript auf alle Seiten und fertig im schlimmsten, ein paar Schritte im Tag Manager und etwas Abstimmung im komplexesten Fall. Das ist freilich heute anders und wir reden über die Schritte, die heute zu einem Tag Deployment Prozess gehören (sollten). Knacking, unter 15 Minuten und mit einem sympathischen gaaaanz kleinen Schnittfehler am Ende vor dem Abspann.

Ding des Monats: Tag Deployment

Früher (Best Case):

  • Anforderung kommt rein. Normalerweise: Code zugesendet bekommen 😉
  • Umfang Seiten / Trigger klären
  • Einbau in Tag Manager:
    • Verwendung Template oder Custom HTML Tag
    • Bestückung mit allen Infos als Variablen o. Ä.
    • Test
    • Veröffentlichung
    • Rückmeldung Implementierung
  • Eintrag in interne Dokumentation, Taggingplan, Eventliste o. Ä.
  • QA im empfangenden System

Heute (wenn man Pech hat):

  • Anforderung wird gestellt, oft verschiedene Implementierungsvarianten
  • Klären, welche Daten fließen sollen und Klassifizieren nach potenziell persönlichen Daten
  • Abstimmung mit DSB, Legal
  • Bearbeitung Compliance-Checklisten oder weiterer Dokumente
  • Abschließen von AV oder anderer Verträge
  • Evtl. Auswirkungen auf Datenschutzhinweise auf der Website
  • Aktualisierung von Dokumentationen (Verfahrensverzeichnis, Datenfluss-Diagramme u. a.)
  • Consent Management:
    • Bestimmung der Zwecke, Verwendeten Cookies und besorgen der Infos für den Einbau
    • Implementierung Consent Tool (idealerweise auf Stage oder in Vorschau Version des Consent Tools)
  • Umfang Seiten / Trigger klären
  • Einbau in Tag Manager:
    • Verwendung Template oder Custom HTML Tag
    • Bestückung mit allen Infos als Variablen o. Ä.
    • Test
    • Veröffentlichung
  • Einbau Serverside:
    • Evtl. internes IT Projekt zur Anreicherung von Daten oder nativer API Implementierung erforderlich
    • Wenn interne Implementierung:
      • Toolset bestimmen
      • Implementierung, Tests intern
      • Go live gem. Releasezyklus
    • Wenn ssGTM:
      • Bestehendes Template nutzen oder selber bauen
      • Bestückung
      • Test, parallel mit Client
      • Veröffentlichung (ggf. auch erst später)
  • Rückmeldung Implementierung (ggf. mehrfach)
  • Eintrag in interne Dokumentation, Taggingplan, Eventliste o. Ä.
  • QA im empfangenden System
  • Wenn Serverside: Laufende Pflege und Anpassung bei API Updates

Kontakt