Zurück zur Übersicht

Server-seitigen Google Tag Manager unter Debian einrichten

Header image for "Server-seitigen Google Tag Manager unter Debian einrichten"
5 Min. Lesezeit
sGTMServerseitiges TrackingInfraServer

An anderer Stelle habe ich bereits beschrieben, welche Vorteile der neue serverseitige Google Tag Manager gegenüber dem bisherigen Web-Container durch einen besseren Datenschutz und eine höhere Kontrolle über die erfassten Daten hat. In diesem Beitrag soll es darum gehen, wie ein eigener Server-Container auf einem Debian-System mit Docker eingerichtet werden kann.

Einleitung

Folgt man der Empfehlung von Google bei der Implementierung eines serverseitigen Google Tag Managers, ist dafür ein App-Engine-Hosting in der Google Cloud erforderlich. Dadurch entstehen je nach Performanz Fixkosten zwischen 40 und 100 Euro, die für kleinere Seiten nicht vertretbar sind. Mit dieser Anleitung soll eine Alternative aufgezeigt werden, wie ein eigener serverseitiger Google Tag Manager ohne zusätzliche Kosten installiert werden kann. Eine hervorragende Anleitung für die Einrichtung des GTMs in der Google Cloud kann auf Simo Ahavs Blog gefunden werden.

Bisher war es nur über Umwege möglich, das Image für die serverseitigen Container auf einem eigenen Server zum Laufen zu bringen. Seit kurzem gibt es eine offizielle Dokumentation inklusive des entsprechenden Docker-Images für die manuelle Installation des serverseitigen Google Tag Managers.

Systemvoraussetzungen

Voraussetzung dafür ist ein virtueller oder dedizierter Linux-Server mit Debian als Betriebssystem. Die Docker-Installation wird während dieser Anleitung durchgeführt. In Googles Setup der App-Engine-Instanzen wird als Performance-Voraussetzungen 1 vCPU, 0,5 GB RAM und 10 GB Festplattenspeicher angegeben. Offensichtlich geht es hier also weniger um die Systemperformance als um die Anzahl der Instanzen. Google empfiehlt, mindestes drei Instanzen parallel laufen zu lassen, um Traffic-Peaks und Serverausfälle abzufangen.

In diesem Setup wird der serverseitige Google Tag Manager auf dem gleichen Webserver installiert, auf dem auch dieser Blog läuft. Es dient daher nur dem Ziel, ein Möglichkeit für eine kostengünstige Installation zu veranschaulichen. Für hochperformante und traffic-intensive Websites ist es daher ungeeignet.

Docker-Installation

Docker ist eine Softwareumgebung, die es erlaubt, Anwendungen schnell und einfach auf einem System zu installieren, indem alle benötigten Abhängigkeiten selbständig mitgeladen werden. Es wird sozusagen ein kleines virtuelles Subsystem angelegt, das autark funktioniert.

Für die Installation auf Debian ist diese Anleitung empfehlenswert. Es werden nur wenige Schritte benötigt. Zunächst weden die entsprechenden Abhängigkeiten sowie der Docker GPG Schlüssel installiert:

sudo apt-get update

sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg \
    lsb-release
    
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Anschließend erfolgt die Installation der apt-packages:

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io

Nach einigen Minuten ist dieser Vorgang abgeschlossen und die Funktionalität der Docker-Umgebung kann getestet werden:

sudo docker run hello-world

Schließt dieses Kommando ohne Fehler ab, sind wir bereit für den nächsten Schritt.

Subdomain für Preview- und Tracking-Server anlegen

Bevor die Docker-Container für den serverseitigen Google Tag Manager geladen und ausgeführt werden, müssen zunächst zwei Subdomains angelegt werden. Über die erste wird der Preview-Server erreichbar sein, der für den Vorschaumodus des GTMs gebraucht wird. Die zweite Domain wird die "offizielle" Tracking-Domain, an die alle Requests von der Seite weitergeleitet werden.

Weil wir den gleichen Server für sowohl den Preview-Modus als auch den Live-Modus verwenden, passen wir den Port für den Preview-Server von 8080 auf 8079 an, so dass er sich nicht mit dem Live-Server überschneidet. Zudem richten wir eine Weiterleitung auf den SSL-verschlüsselten Port ein.

Beispielhaft für einen Apache-Webserver wird das hier verdeutlicht:

<VirtualHost *:80>
    ServerName preview.example.com
    
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

<VirtualHost :443>
    ServerName preview.example.com
   
    ProxyPreserveHost On
    ProxyRequests Off

    ProxyPass / https://localhost:8079/
    ProxyPassReverse / https://localhost:8079/

    SSLEngine On
    SSLCertificateFile    <path to your crt file>
    SSLCertificateKeyFile   <path to your private key file>

</VirtualHost>

Für den Live-Server gilt entsprechend:

<VirtualHost *:80>
    ServerName data.example.com
    
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

<VirtualHost :443>
    ServerName data.example.com
   
    ProxyPreserveHost On
    ProxyRequests Off

    ProxyPass / https://localhost:8080/
    ProxyPassReverse / https://localhost:8080/

    SSLEngine On
    SSLCertificateFile    <path to your crt file>
    SSLCertificateKeyFile   <path to your private key file>

</VirtualHost>

Ist diese Konfiguration abgeschlossen, werden die Services sowie die Seiten noch aktiviert und der Webserver neu gestartet.

a2ensite gtm-preview
a2ensite gtm-live
sudo a2enmod proxy && sudo a2enmod proxy_http && sudo service apache2 restart

Einrichten der Docker-Container

Sind die vorgesehenen Endpunkte über die jeweiligen Ports zu https://localhost/ erreichbar, können jetzt die Docker-Container eingerichtet werden.

Dafür sind folgende Parameter nötig:

  • -d: Docker-Container im Hintergrund ausführen ("detached")
  • --name: Name des Docker-Containers
  • -p: Port, über den der Docker-Container erreichbar ist
  • CONTAINER_CONFIG: Container-ID, die beim Erstellen des Server-Containers auf https://tagmanager.google.com angegeben wird
  • RUN_AS_PREVIEW_SERVER: Der erste Docker-Container geht als Preview-Server live
  • PORT: Der gleiche Port wie oben

Daraus ergeben sich folgende Kommandos, um die beiden Container zu starten. Wichtig ist, den Preview-Container zuerst zu starten, da der Live-Container auf dessen URL verweist:

docker run -d\
    --name gtm-preview \
    -p 8079:8079 \
    -e CONTAINER_CONFIG='<container ID>' \
    -e RUN_AS_PREVIEW_SERVER=true \
    -e PORT=8079 \
    gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

docker run -d\
    --name gtm-live \
    -p 8080:8080 \
    -e CONTAINER_CONFIG='<container ID>' \
    -e PREVIEW_SERVER_URL='https://preview.domain.de' \
    -e PORT=8080 \
    gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

War dieser Vorgang erfolgreich, kann mit zunächst mit docker ps -a überprüft werden, ob die Container ausgeführt werden. Um zu kontrollieren, dass die beiden Endpunkte für den Preview- und Live-Server erreichbar sind, wird der Pfad /healthz mit den jeweiligen Domains verwendet.

Erfolgreich live-gestellter GTM-Server{.mx-auto .d-block .img-fluid .shadow}

Ein "OK" sagt mehr als tausend Zeichen

Wird links oben im Browser ein "ok" angezeigt, hat die Einrichtung der Docker-Container funktioniert und der eigene GTM-Server ist live!

Bei der Einrichtung der GTM-Server-Container gibt es einen wichtigen Hinweis von Google über Best Practices zu beachten:

Make sure to restart the servers periodically to ensure your servers have the latest code updates for SST. Failure to do so may result in incompatible functionality for new SST features. One way to know when the server needs to restart is to set up liveness checks, which is explained further below. Also, please note that any published updates to your server container will still be applied without a restart.

Um sicherzustellen, dass die Docker-Container regelmäßig neu gestartet werden, legen wir einen Cron-Job an. Dafür navigieren wir über die Konsole mit crontab -e in die Job-Datei und fügen folgende Zeile hinzu:

0 3 * * * docker restart gtm-preview gtm-live

Damit werden beide Docker-Container täglich um 3 Uhr morgens neu gestartet – eine Uhrzeit, in der eine minimal kurze Pause verkraftbar sein sollte.

Zusammenfassung

Mit dem serverseitigen Google Tag Manager hat Google eine attraktive Möglichkeit geschaffen, die Datenerfassung auf der eigenen Website stärker in die Hand zu nehmen und den Inhalt weitergesendeter Daten zu bestimmen. Als ein positiver Nebeneffekt führt diese Art der Datenerfassung derzeit dazu, dass das Tracking weniger Gefahr läuft, blockiert zu werden.

Doch nicht für jede Website lohnt sich ein Setup in der Google Cloud. Sind die Anfragen gering und hat der Server noch Kapazität, dann spricht erstmal nichts dagegen, den GTM-Server selbst zu hosten. Lasst mich gerne wissen, falls ich potentielle Einwände übersehe!

Um die Datenerfassung noch stärker zu kontrollieren bzw. an Google Analytics übermittelte Daten zu anonymisieren, gibt es weitere Konfigurationen, die wir im serverseitigen Google Tag Manager vornehmen können. Ich freue mich drauf, hier in Zukunft weitere Ansätze vorzustellen.

Alle Blog-Artikel anzeigen