Skip to content

Digital Analytics Blog

von Marcus Stade

Menu
Menu
TMS_ca1_gtm

Tag Management Platform: Commanders Act Platform X – DataCollection (Teil 2)

Posted on 18. Juli 202218. Juli 2022 by mstade

Dieser Artikel ist Teil der Serie “Tag Management Platform”. Zur Übersicht der Serie

Der französische Anbieter Commanders Act ist mit dem Tag Management System TagCommander im Vergleich zum Google Tag Manager oder Adobe Data Collection nicht gerade bekannt. Neben dem TagCommander ergänzte CommandersAct seine Produktpalette um weitere Tools wie TrustCommander(CMP), MixCommander (Attribution), DataCommander (DMP) und FuseCommander (UserID Lösung). Unter dem Namen Platform X fließt wird nun vielen zu einer Lösung zusammengefasst, die Tag Management Platform Gedanken mit integrierter CDP und CMP abbildet. Im ersten Teil zu Commanders Act steht das Thema DataCollection, also das Sammeln von Daten in Web und App im Mittelpunkt. 

Data Collection Implementierung

Platform X ist noch recht neu. So sind einige Source Connectoren aktuell noch in Beta oder Closed Alpha. Die für den Data Collection Part aus meiner Sicht wichtigen Connectoren für Web, App und HTTP API sind dies nicht. Für Web stehen verschiedene Connectoren zur Verfügung. Neben dem clientseitigen Tag Manager, der jetzt nur Web Container genannt, ist ebenfalls ein Connector für den Google Tag Manager vorhanden. Beide Optionen sind spannend. 

Source Menu (Ausschnitt):

TMS_ca1_gtm

WebContainer Interface (die „alten“ TagCommander Container wurden übernommen):

TMS_ca1_webcontainer

Für die serverseitige Implementierung des Google Tag Managers ist nur eine Benennung und die Auswahl der Entwicklungsumgebung (Dev, Stage, Prod) erforderlich. Wie bei vielen Systemen können somit unterschiedlichen Versionen auf den verschiedenen Environments existieren, was das Testen vereinfacht.

TMS_ca1_gtm_setting

Jede Data Source erhält einen eindeutigen sourceKey, der im Request mitgesendet werden sollte. Falls dies geschieht, können eingehende Requests im Tab DataQuality evaluiert werden. Unter dem Menüpunkt Health gibt es das Feature auch Data Source übergreifend:

Data Collection Implementierung Web – Google Tag Manager

Eine weitere serverseitige Konfiguration ist nicht erforderlich, so das nun der Google Tag Manager die Daten an den Server senden kann. Commanders Act stellt hierfür ein Tag in der Template Gallery zur Verfügung. Mit dem Tag kann der bestehende dataLayer einfach gemapped werden. 

TMS_ca1_gtmtemplate

CommandersAct arbeitet dabei neben Custom Events mit vordefinierten Events, die stark an GA4 erinnern:

TMS_ca1_gtmevents

Die SiteID definiert dabei die eindeutige ID für die Instanz. Das Tag besteht aus vier weiteren Teilen, die die Daten die entlang des Events gesendet werden, definieren. Event-Parameter, wie den Wert des Event, Produktdaten, die unter Angabe des Keys direkt aus dem angegeben Produkt Object extrahiert werden, User Daten, wie UserID, E-Mail, Name, etc. sowie ein Consent Array, mit dem Consent Informationen übermittelt werden können.

TMS_ca1_gtmtemplate2

Die Events im datalayer müssen nur auf das passende Event im Tag sowie die dazugehörigen Informationen gemapped werden. Am Beispiel des Produtaufruf Events “View Item” auf Basis der dataLayer Implementierung für Enhanced E-Commerce:

TMS_ca1_gtmtemplate_pdp

In der Section für Event Parameter wird der Wert des Events übergeben. Für Produktaufrufe ist ein Wert für mich hier nicht gegeben, daher ist dieser mit 0 definiert. In der Productsection wird das Product Array aus dem eCommerce Object referenziert. Nun müssen die Keys innerhalb des Array in die Felder für id, name, etc. eingetragen werden. Daraus baut das Tag folgenden Request:

TMS_ca1_gtmtemplate_request

Da die Tag Management Plattformen darauf basieren, das erst am Server entschieden wird, wie die Informationen weiterverarbeitet werden, befinden sich relativ viele Informationen darin, beispielsweise alle Cookie-Werte, falls Conversion Pixel genutzt werden müssen. Ebenso generiert das Tag gleich eine unique Event Id, die beispielsweise für die Facebook Conversion API benötigt wird. Auch die Produktdaten werden korrekt gemapped.

Auf Serverseite kann die Qualität der Daten überwacht werden. Im Health Menü wird der eingehende Request als valide betrachtet und verarbeitet.

Allerdings wird dieser der Source “default collection” zugeordnet, nicht der eingerichteten Source Google Tag Manager. Entsprechend findet sich der Request nicht im Menüpunkt “Data Quality”. 

TMS_ca1_gtmtemplate_request_server2

Quick Fix für das „Problem“:

Um das zu beheben, kann im Tag-Template ein Feld token eingerichtet werden, in dem der sourceKey erwartet wird:

TMS_ca1_gtmtemplate_token

In der Konfiguration des Tags kann nun der SourceKey übergeben werden, allerdings muss die Verwendung auch im Template definiert werden:

TMS_ca1_gtmtemplate_token2

Damit erscheint der Tag nun auch im Tab Data Quality der Data Source:

TMS_ca1_gtmtemplate_request_server3

und wird im Health Monitor nun auch der richtigen Data Source zugeordnet.

Allerdings sollte der Fix nicht produktiv angewendet, da durch die Änderung das Tag Template von Updates in der Gallery entkoppelt wird und nicht mehr automatisch upgedatet wird. Vielleicht ist die Möglichkeit den sourceKey zu ergänzen in einer der nachfolgenden Versionen vorhanden. 

Data Collection Implementierung Web – Web Container

Web Container, so der neuen Name des Commanders Act clientside Tag Managers, ist natürlich passend integriert. Bisher wurden im Tag Commander einzelne Tags für die Commanders Act Produkte ausgelöst. Mit dem Web Container wurde das Commanders Act OneTag eingeführt, das den Hit auf Basis des TagCommanders dataLayer aufbaut. Das Mapping entspricht dem Mapping, das bereits aus dem Tag für den Google Tag Manager bekannt ist, lediglich die Keys müssen nicht definiert werden, da diese nach dem Tag Commander Standard bekannt sind:

TMS_ca1_webcontainer1

Obwohl die Tags sehr ähnlich sind, so ist die Entscheidung zwischen Google Tag Manager und Web Container nicht trivial, es sei denn, es eines der Systeme ist bereits im Einsatz. Der Commanders Act Webcontainer verfolgt eine im Details andere Philosophie als der Google Tag Manager. Ein Beispiel:

Beim Commanders Act WebContainer ist Teil des Konzepts, einen oder auch mehrere asynchrone und falls nötig synchrone Container in die Seite einzubinden. Synchrone Container werden beispielsweise benötigt, damit A/B Testing Tools kein Flicker erzeugen bzw. alle notwendigen Informationen ebenso wie Consent auf der Seite zur korrekten Ausspielung vorhanden sind. Im Gegensatz zum Google Tag Manager nutzt  Commanders Act keinen Event-DataLayer so das immer nur der aktuelle Stand des dataLayers im Object tc_vars vorhanden ist.

Data Collection Implementierung Android App

Obwohl App ein immer wichtigerer Touchpoint wird , so ist (traurigerweise) das App-Tracking immer noch ein wenig exotisch. Nicht das die Tracking Features von Firebase etc. nicht in App integriert werden, aber leider fehlt häufig ein gemeinsamer Ansatz von Datenerhebung und Implementierung. Meiner Meinung nach ist das vor allem ein Mangel an Verständnis von der Implementierung auf Seiten des Tracking Departments und auf der anderen Seite ein Mangel an Verständnis für Anforderungen aus Tracking Sicht. Grund genug, das App SDK von Commanders Act in eine App zu integrieren. Serverside erfolgt die Einrichtung wie die des Web-Tags:

TMS_ca1_app1

Um nun das SDK in die App zu integrieren, müssen nur die Module “Core” und “Serverside” eingebunden werden:

implementation 'com.tagcommander.lib:core:5.1.0'
implementation 'com.tagcommander.lib:ServerSide:5.1.0'

sowie der App die Berechtigung für den Zugriff auf das Internet gegeben werden:

TMS_ca1_app3

Nun kann das SDK beim Starten der App initialisiert werden:

Um fürs Testing den Debugging Modus zu nutzen, kann folgende Code genutzt werden:

TCDebug.setDebugLevel(Log.VERBOSE)

Nun kann die Initialisierung unter Angabe der SiteID, dem sourceKey und dem App Context angegeben werden:

val TCS = TCServerSide(4989, "cacde622-b9b0-41d6-acc1-ff0d2e0ac9f2", this.getApplicationContext())

Danach können einfach Events geloggt, mit Event Parametern erweitert und gesendet werden:

val event = TCCustomEvent("AppStart")
event.addAdditionalParameter("source", "direct")
TCS.execute(event)

Ausgehende Request in LogCat:

TMS_ca1_app5

Auf Serverseite wird der Request ebenfalls validiert und weiterverarbeitet:

TMS_ca1_app6

Wird ein Request (unabhängig von der Platform) nicht verarbeitet oder wird verarbeitet aber weißt Anomalien auf, wird dies im Event angezeigt.

Data Collection Implementierung HTTP-API

Gibt es für ein Quellsystem keine vordefinierte Source ist eine HTTP API immer wichtig. Die HTTP API CommandersAct Platform X ist ebenfalls unter Sources zu finden und basiert auf dem sourceKey:

TMS_ca1_api1

Über Postman simulieren wir den API Call. Der Request mit den content-type: application/json gesendet an den Endpoint enthält als Parameter die SiteID sowie den sourceKey als Bearer Token:

TMS_ca1_api2

und als Body das Object:

TMS_ca1_api3

Dabei müssen die für das Object die erforderlichen Werte vorhanden sein. Enthält beispielsweise ein purchase Event keinen Value, wird das Event nicht verarbeitet:

TMS_ca1_api4

Allerdings liefert die API einen Status Code 200 zurück. Der wird unabhängig von der Verarbeitung zurückgeliefert, es sei denn der Payload ist zu lang. Das heißt, clientseitig kann leider nicht aufgrund des Status Codes von einer erfolgreichen Verarbeitung ausgegangen werden.

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Keep in Touch

Supporter: InPignus GmbH

ImPignus

mohrstade

mohrstade.de

Analytics Pioneers

Schlagwörter

App+Web App-Tracking Basic Big Query Customer Data Platform DataQuality DataStudio Events Google Analytics für Firebase ITP Machine Learning Property PWA Quick-Tipp User-Journey Wordpress Überblick

Podcast Empfehlung:

beyond pageview

Neueste Beiträge

  • Tag Management Platform: Commanders Act Platform X – DataCollection (Teil 2)
  • Tag Management Platform: Übersicht (Teil 1)
  • IP und User Agent Identifier: Nachteile
  • GA4 Recipes: Machine Learning Features für Predictive Audiences in anderen Tools nutzen, am Beispiel von Tealium AudienceStream
  • Quick Tipp: GA4 Configuration Tag vs. Universal Analytics Setting Variable – Sequence matters

Kategorien

  • Allgemein
  • Cloud
  • Dashboard
  • Firebase Analytics
  • Google Analytics
  • Google Analytics 4 (App+Web)
  • Google Optimize
  • Google Tag Manager
  • Machine Learning
  • Matomo
  • Tag Management

Links

  • Datenschutzerklärung
  • Hear Me Speak
  • Impressum
  • Meet & Eat
  • Über den Blog
©2023 Digital Analytics Blog | Built using WordPress and Responsive Blogily theme by Superb