Server-Side-Tracking: Wann es sinnvoll ist, und wann nicht

Server-Side-Tracking kann eine sinnvolle Weiterentwicklung der Webanalyse sein. Vor allem dann, wenn es konkrete Gründe gibt, eine zusätzliche Verarbeitungsebene zwischen der Website und den verwendeten Tracking-Diensten einzuführen.

Das können beispielsweise bessere Kontrolle über die übertragenen Daten, eine zuverlässigere Verarbeitung von E-Commerce-Ereignissen, die Integration von CRM-Daten oder eine geringere Belastung des Browsers durch zahlreiche Tracking-Skripte sein. Allerdings ist Server-Side-Tracking kein Wundermittel.

Es stellt nicht plötzlich sämtliche fehlenden Conversions wieder her, macht Consent Management nicht überflüssig und repariert auch kein schlecht durchdachtes Tracking-Konzept. Wenn vor der Umstellung unklar ist, welche Ereignisse erfasst werden sollen und wie diese definiert sind, wird das durch Server-Side-Tracking nicht automatisch besser. Im Gegenteil: Wer eine fehlerhafte Tracking-Implementierung auf eine komplexere technische Infrastruktur verlagert, macht unter Umständen nur die Fehlersuche schwieriger.

Was sich durch Server-Side-Tracking verändert

Bei einer klassischen clientseitigen Tracking-Implementierung sendet der Browser Messdaten direkt an Dienste wie Google Analytics, Google Ads, Meta oder andere Analyse- und Werbeplattformen.

Bei Server-Side-Tracking wird eine zusätzliche Verarbeitungsebene eingeführt. Der Browser kann seine Messdaten beispielsweise zunächst an einen eigenen Tracking-Endpunkt senden. Dieser nimmt die Ereignisse entgegen, verarbeitet sie und entscheidet anschließend, welche Informationen an welche Plattform weitergeleitet werden. Alternativ können bestimmte Ereignisse auch direkt aus Backend-Systemen stammen, etwa aus einem Shopsystem oder CRM.

Ein vereinfachter Vergleich:

Klassisches Browser-Tracking:

Besucher
   ↓
Website im Browser
   ├── Google Analytics
   ├── Google Ads
   ├── Meta
   └── Weitere Tracking-Dienste

Server-Side-Tracking:

Besucher
   ↓
Website im Browser
   ↓
Eigener Tracking-Endpunkt
   ↓
Serverseitige Verarbeitung
   ├── Google Analytics
   ├── Google Ads
   ├── Meta
   └── Weitere Tracking-Dienste

Mit dem serverseitigen Google Tag Manager lässt sich eine solche Architektur umsetzen. Google beschreibt den Server-Container als zusätzliche Verarbeitungsebene, die mehr Kontrolle darüber ermöglicht, welche Daten an die jeweiligen Dienste übertragen werden.

Damit lassen sich beispielsweise:

• Datenfelder vor der Weiterleitung entfernen oder verändern;
• Ereignisse in einem einheitlichen Format an mehrere Plattformen senden;
• bestimmte Tracking-Funktionen aus dem Browser auf den Server verlagern;
• Tracking-Anfragen über eine eigene First-Party-Domain abwickeln;
• Browser-Ereignisse mit Informationen aus Backend-Systemen kombinieren.

Darüber hinaus kann Server-Side-Tracking die Menge an Tracking-Code reduzieren, die direkt im Browser ausgeführt werden muss. Das kann sich positiv auf die Ladezeit und die Performance einer Website auswirken.

Allerdings entsteht gleichzeitig zusätzliche Infrastruktur. Der Tracking-Endpunkt muss gehostet, konfiguriert, abgesichert, überwacht und gewartet werden. Genau dieser zusätzliche Aufwand macht die Entscheidung weniger eindeutig, als es manche Anbieter von Server-Side-Tracking-Lösungen darstellen.

Der Browser bleibt weiterhin wichtig

Ein weitverbreitetes Missverständnis ist die Vorstellung, dass Server-Side-Tracking vollständig ohne den Browser auskommt. Für die meisten Webanalyse-Implementierungen stimmt das nicht.

Ein Server weiß nicht automatisch, ob ein Besucher auf einen Button geklickt, ein Formular abgeschickt oder den dritten Schritt eines Bestellprozesses erreicht hat. Diese Interaktionen finden zunächst im Browser statt. Dort müssen sie erkannt und anschließend an einen geeigneten Endpunkt übertragen werden.

Bei einer serverseitigen Implementierung ist dieser Endpunkt möglicherweise nicht mehr direkt Google Analytics, sondern der eigene Tagging-Server. Das ändert jedoch nichts daran, dass die ursprünglichen Ereignisse korrekt erfasst werden müssen.

Wenn der Data Layer ein falsches Ereignis auslöst, erhält auch der Server ein falsches Ereignis. Wenn beim Abschluss einer Bestellung kein Purchase-Event ausgelöst wird, kann der Server dieses fehlende Browser-Ereignis nicht einfach rekonstruieren. Ein Backend könnte den Kauf allerdings unabhängig davon erfassen und als eigenes Ereignis übertragen. Und wenn innerhalb eines Unternehmens niemand eindeutig definiert hat, wann ein Lead als qualifiziert gilt, wird diese Definition auch durch einen Google-Cloud-Run-Container nicht plötzlich klarer.

Server-Side-Tracking kann eine gute Tracking-Implementierung besser kontrollierbar machen. Es ersetzt aber nicht die grundlegende Entscheidung, was überhaupt gemessen werden soll.

Wann Server-Side-Tracking sinnvoll wird

Ich würde Server-Side-Tracking insbesondere dann in Betracht ziehen, wenn mehrere der folgenden Voraussetzungen erfüllt sind.

1. Die Website verwendet zahlreiche Tracking-Dienste

Auf größeren Websites kommen häufig verschiedene Analyse-, Marketing- und Werbeplattformen gleichzeitig zum Einsatz. Neben Google Analytics und Google Ads können beispielsweise Meta, Affiliate-Netzwerke, Remarketing-Dienste und weitere Marketing-Technologien eingebunden sein.

Je nach Implementierung muss der Browser dafür zahlreiche Skripte laden und ausführen. Das kann die Performance beeinträchtigen. Wenn sich Teile der Verarbeitung auf den Server verlagern lassen, kann der clientseitige Aufwand reduziert werden. Allerdings sollte man den tatsächlichen Effekt vorher untersuchen.

Nicht jedes Tracking-Skript lässt sich vollständig ersetzen. Manche Dienste benötigen weiterhin eigenen JavaScript-Code im Browser, beispielsweise für bestimmte Interaktionen oder Funktionen. Außerdem ist eine langsame Website nicht automatisch ein Argument für serverseitiges Tracking. Häufig liegen die größeren Performance-Probleme an Bildern, schlecht optimierten Themes, JavaScript-Bibliotheken oder anderen Ressourcen.

Deshalb würde ich zunächst messen, welchen Anteil die Tracking-Implementierung tatsächlich an den Ladezeiten hat.

2. Es wird mehr Kontrolle über die übertragenen Daten benötigt

Das ist für mich eines der überzeugendsten Argumente. Ein Server-Container ermöglicht es, eingehende Ereignisse vor der Weiterleitung zu prüfen und zu verändern. So können beispielsweise unerwünschte Parameter entfernt, Datenformate vereinheitlicht oder bestimmte Informationen nur an ausgewählte Empfänger übertragen werden.

Angenommen, ein Onlineshop möchte einen abgeschlossenen Kauf an mehrere Systeme melden. Google Analytics benötigt bestimmte Informationen für seine E-Commerce-Berichte. Google Ads benötigt Informationen für die Conversion-Messung. Ein weiteres Werbenetzwerk erwartet möglicherweise ein anderes Datenformat.

Anstatt die gesamte Logik für jede Plattform einzeln im Browser zu implementieren, kann ein Teil der Verarbeitung zentral erfolgen. Das reduziert potenziell doppelte Implementierungen und erleichtert die Verwaltung. Voraussetzung ist natürlich, dass die Datenflüsse sauber definiert sind.

Ein Server-Container macht eine komplexe Integration nicht automatisch einfach. Er bietet lediglich einen zusätzlichen Ort, an dem sich diese Komplexität kontrollieren lässt.

3. Browser-Ereignisse sollen mit Backend-Daten kombiniert werden

Besonders interessant wird Server-Side-Tracking, wenn wichtige Geschäftsereignisse nicht ausschließlich im Browser stattfinden. Das betrifft sowohl Onlineshops als auch Unternehmen, die ihre Kundenanfragen über ein CRM-System verwalten.

Beispiel: Lead-Generierung

Ein Besucher füllt ein Kontaktformular aus. Im Browser wird ein Lead-Ereignis erfasst. Zu diesem Zeitpunkt ist allerdings noch unklar, ob die Anfrage überhaupt relevant ist. Erst später stellt sich im CRM heraus, dass es sich um einen qualifizierten Interessenten handelt. Für die Bewertung einer Google-Ads-Kampagne kann diese Information wesentlich wertvoller sein als die reine Anzahl abgeschickter Formulare.

Mit einer geeigneten serverseitigen Architektur können solche späteren Ereignisse in das Messkonzept einbezogen werden.

Beispiel: E-Commerce

Ein Kunde gibt eine Bestellung auf. Anschließend können weitere Ereignisse eintreten:

• Die Zahlung wird über einen externen Zahlungsanbieter bestätigt.
• Die Bestellung wird nachträglich storniert.
• Einzelne Artikel werden retourniert.
• Der tatsächliche Bestellwert verändert sich.

Solche Informationen liegen häufig zuverlässiger im Shopsystem als im Browser vor. Eine serverseitige Integration kann helfen, diese Daten für die Analyse und gegebenenfalls für Conversion-Importe bereitzustellen. Dabei muss berücksichtigt werden, welche Funktionen die jeweilige Zielplattform tatsächlich unterstützt und welche Ereignisse oder Korrekturen dort verarbeitet werden können.

Entscheidend sind außerdem geeignete Identifikatoren, damit zusammengehörige Ereignisse korrekt zugeordnet und doppelte Conversions vermieden werden.

4. Zuverlässige Messdaten haben einen hohen wirtschaftlichen Wert

Für mich ist das letztlich der wichtigste Maßstab. Wenn unzuverlässige Tracking-Daten direkte Auswirkungen auf Werbebudgets, Conversion-Optimierung oder geschäftliche Entscheidungen haben, kann zusätzliche Tracking-Infrastruktur wirtschaftlich gerechtfertigt sein.

Ein Onlineshop, der monatlich erhebliche Beträge in Google Ads investiert, hat andere Anforderungen als ein kleiner Handwerksbetrieb mit einer fünfseitigen Website. Bei einem größeren Shop können selbst vergleichsweise kleine Verbesserungen der Messqualität relevant sein. Bei einer einfachen Unternehmenswebsite mit Google Analytics, Google Ads und einem Kontaktformular lässt sich dagegen möglicherweise nahezu derselbe Nutzen mit einer sauber implementierten clientseitigen Lösung erzielen.

Die Frage ist nicht, ob Server-Side-Tracking technisch moderner ist. Die Frage ist, ob der zusätzliche Aufwand einen messbaren Nutzen bringt.

Datenschutz wird durch Kontrolle verbessert, nicht durch das Wort „serverseitig“

Server-Side-Tracking kann auch aus Datenschutzsicht Vorteile bieten. Eine zusätzliche Verarbeitungsebene ermöglicht es, genauer zu kontrollieren, welche Daten die eigene Infrastruktur verlassen.

Bestimmte Parameter können entfernt werden. Die Weitergabe an einzelne Dienste lässt sich beschränken. Unterschiedliche Einwilligungszustände können bei der Verarbeitung berücksichtigt werden. Das ist grundsätzlich sinnvoll.

Allerdings wird eine Tracking-Implementierung nicht automatisch DSGVO-konform, nur weil die Daten zunächst über einen eigenen Server laufen. Auch beim serverseitigen Google Tag Manager muss beispielsweise die Einwilligungsentscheidung des Besuchers korrekt berücksichtigt werden.

Bei der entsprechenden Consent-Mode-Implementierung wird der Einwilligungsstatus in der Regel zunächst durch die Consent-Lösung im Browser erfasst und anschließend an die serverseitige Infrastruktur übermittelt. Die dort verwendeten Tags müssen ihr Verhalten entsprechend anpassen.

Die grundlegenden Fragen bleiben deshalb unverändert:

• Welche Daten werden erhoben?
• Zu welchem Zweck erfolgt die Verarbeitung?
• Welche Rechtsgrundlage liegt vor?
• Welche Drittanbieter erhalten die Informationen?
• Was passiert, wenn ein Besucher seine Einwilligung verweigert oder widerruft?
• Welche Daten dürfen keinesfalls an bestimmte Empfänger übertragen werden?

Gerade bei Websites, die sich an Nutzer in Deutschland richten, müssen neben der DSGVO auch die Anforderungen des § 25 TDDDG berücksichtigt werden. Das betrifft insbesondere den Zugriff auf Informationen in Endeinrichtungen beziehungsweise deren Speicherung, soweit keine gesetzliche Ausnahme greift. Ob eine Tracking-Anfrage anschließend über analytics.example.de oder direkt an Google übertragen wird, ändert an diesen grundlegenden Anforderungen nichts.

Auch die Vorgaben der jeweiligen Plattformen müssen eingehalten werden. Google Analytics untersagt beispielsweise grundsätzlich die Übermittlung unmittelbar personenbezogener Informationen wie E-Mail-Adressen oder Telefonnummern, sofern dafür keine ausdrücklich unterstützte Funktion mit entsprechenden Bedingungen verwendet wird.

Dass ein serverseitiger Prozess technisch auf solche Daten zugreifen könnte, bedeutet nicht, dass sie auch an Google Analytics gesendet werden dürfen.

Mehr technische Kontrolle bedeutet gleichzeitig mehr Verantwortung dafür, diese Kontrolle richtig einzusetzen.

Verbessert Server-Side-Tracking die Datenqualität?

Häufig wird Server-Side-Tracking mit dem Versprechen beworben, verlorene Tracking-Daten wiederherzustellen. Dahinter steckt ein nachvollziehbarer technischer Gedanke.

Wenn Tracking-Anfragen nicht mehr ausschließlich direkt an bekannte Drittanbieter-Domains gesendet werden, können bestimmte Blockierungsmechanismen weniger häufig greifen. Ein First-Party-Endpunkt kann deshalb dazu beitragen, dass zulässige Messdaten zuverlässiger übertragen werden. Auch Google empfiehlt für serverseitiges Tagging die Verwendung einer eigenen First-Party-Domain.

Allerdings sollte man daraus keine falschen Erwartungen ableiten. Server-Side-Tracking sorgt nicht automatisch dafür, dass sämtliche Adblocker umgangen werden. Es stellt auch keine Daten wieder her, die nie erfasst wurden. Und es darf selbstverständlich nicht dazu verwendet werden, eine verweigerte Einwilligung zu umgehen. Wenn ein Besucher bestimmte Tracking-Kategorien abgelehnt hat, muss diese Entscheidung auch in einer serverseitigen Architektur respektiert werden.

Die eigentliche Stärke liegt deshalb weniger in der vermeintlichen Umgehung sämtlicher Tracking-Beschränkungen. Sie liegt darin, zulässig erfasste Daten kontrollierter und unter geeigneten Bedingungen zuverlässiger zu verarbeiten.

Die zusätzliche Infrastruktur gehört zur Gesamtrechnung

Ein serverseitiger Google Tag Manager ist nicht einfach nur ein weiterer GTM-Workspace. Der Server-Container benötigt eine Laufzeitumgebung.

Google bietet dafür eine Einrichtung über Google Cloud Run an. Alternativ sind auch andere geeignete Hosting-Umgebungen möglich. Für produktive Umgebungen mit entsprechendem Traffic empfiehlt Google eine ausreichend dimensionierte Infrastruktur mit mehreren Instanzen, statt sich auf eine minimale Testkonfiguration zu verlassen.

Damit entstehen zusätzliche technische und organisatorische Fragen:

• Wem gehört das Cloud-Konto?
• Über welche Domain ist der Tracking-Endpunkt erreichbar?
• Wer darf Änderungen bereitstellen?
• Wie werden Verfügbarkeit und Fehler überwacht?
• Welche Informationen werden protokolliert?
• Wie lange werden Logdaten aufbewahrt?
• Was passiert bei einem Ausfall?
• Wer wird bei Problemen benachrichtigt?
• Welche laufenden Kosten entstehen?

Auch die Absicherung der Infrastruktur darf nicht vergessen werden. Ein Tracking-Endpunkt sollte nicht unbegrenzt beliebige Anfragen entgegennehmen oder unkontrolliert an externe Systeme weiterleiten. Zugriffsrechte, erlaubte Datenflüsse, Protokollierung und der Umgang mit fehlerhaften Anfragen müssen bewusst konfiguriert werden.

Was kostet Server-Side-Tracking?

Die laufenden Kosten hängen stark von der gewählten Infrastruktur, dem Traffic und der Konfiguration ab. Bei einer selbst betriebenen Lösung müssen insbesondere Hosting, Netzwerkverkehr, Protokollierung und Wartung berücksichtigt werden.

Bei Cloud Run können beispielsweise Kosten für die bereitgestellten Ressourcen, die Anzahl und Dauer der Anfragen sowie zusätzliche Google-Cloud-Dienste entstehen. Google nennt für bestimmte Referenzkonfigurationen eine Größenordnung von rund 45 US-Dollar monatlich pro Cloud-Run-Server. Das ist allerdings keine allgemeingültige Preisangabe und muss für die konkrete Konfiguration überprüft werden. Hinzu kommen gegebenenfalls Kosten für weitere Instanzen, zusätzliche Dienste und die technische Betreuung.

Für einen umsatzstarken Onlineshop können diese Kosten kaum ins Gewicht fallen. Für eine kleine Unternehmenswebsite, auf der lediglich drei Ereignisse gemessen werden, kann dieselbe Infrastruktur unverhältnismäßig aufwendig sein. Und unabhängig von den Hosting-Kosten muss die Lösung eingerichtet, getestet und dauerhaft gewartet werden. Auch das gehört zur wirtschaftlichen Bewertung.

Wie ich entscheiden würde, ob Server-Side-Tracking sinnvoll ist

Bevor ich einem Unternehmen die Einführung von Server-Side-Tracking empfehle, würde ich zunächst die bestehende Implementierung untersuchen. Dabei bietet sich ein schrittweises Vorgehen an.

1. Die bestehende Messung überprüfen

Welche Tracking-Dienste sind aktuell eingebunden? Welche Ereignisse werden erfasst? Gibt es doppelte Conversions, fehlende Ereignisse oder widersprüchliche Daten? Funktioniert das Consent Management korrekt? Sind die wichtigsten Nutzerinteraktionen überhaupt zuverlässig messbar?

Solange diese Fragen nicht geklärt sind, sollte die technische Architektur nicht unnötig verändert werden.

2. Festlegen, was tatsächlich gemessen werden soll

Nicht jedes Klickereignis ist für ein Unternehmen relevant. Entscheidend sind die Informationen, die für Marketing, Vertrieb und Unternehmenssteuerung tatsächlich benötigt werden. Dazu können beispielsweise Käufe, qualifizierte Kontaktanfragen, Registrierungen oder bestimmte Schritte innerhalb eines Bestellprozesses gehören. Für jedes wichtige Ereignis sollte feststehen, wann es ausgelöst wird und welche Informationen dazugehören.

Diese Definitionen sind unabhängig davon notwendig, ob das Tracking im Browser oder auf einem Server verarbeitet wird.

3. Die Empfänger der Daten bestimmen

Nicht jedes System benötigt dieselben Informationen. Google Analytics, Google Ads, ein CRM und ein internes Reporting-System erfüllen unterschiedliche Aufgaben. Deshalb sollte dokumentiert werden, welche Ereignisse an welche Plattform übertragen werden und welche Parameter dafür tatsächlich erforderlich sind.

Ein serverseitiger Tag Manager kann diese Verteilung zentral steuern. Aber nur, wenn vorher klar ist, wie sie aussehen soll.

4. Einwilligung und Datenschutz berücksichtigen

Vor der Implementierung muss feststehen, wie sich die verschiedenen Ereignisse bei unterschiedlichen Einwilligungszuständen verhalten sollen. Welche Daten dürfen verarbeitet werden? Welche Empfänger sind zulässig? Welche Informationen müssen entfernt werden? Wie wird sichergestellt, dass eine verweigerte oder widerrufene Einwilligung berücksichtigt wird? Diese Fragen sollten Bestandteil der technischen Planung sein und nicht erst nachträglich geklärt werden.

5. Prüfen, ob die zusätzliche Infrastruktur ein konkretes Problem löst

Erst jetzt würde ich entscheiden, ob Server-Side-Tracking tatsächlich die beste Lösung ist. Vielleicht lässt sich das eigentliche Problem bereits durch eine bessere Data-Layer-Implementierung beheben. Vielleicht fehlen lediglich einzelne Conversion-Ereignisse. Oder das vorhandene Consent Management ist falsch konfiguriert.

In solchen Fällen kann es sinnvoller sein, zunächst die bestehenden Fehler zu korrigieren. Server-Side-Tracking sollte nicht eingeführt werden, nur weil es technisch möglich ist.

6. Einen wichtigen Prozess vollständig testen

Wenn die Entscheidung für Server-Side-Tracking gefallen ist, würde ich nicht sofort sämtliche Tags migrieren. Sinnvoller ist es, zunächst einen wichtigen Prozess vollständig umzusetzen. Das könnte beispielsweise ein Kaufabschluss oder eine qualifizierte Kontaktanfrage sein.

Dabei sollte überprüft werden, ob das Ereignis im Browser korrekt ausgelöst, an den Server übertragen, dort verarbeitet und anschließend von den vorgesehenen Plattformen empfangen wird.

Ebenso wichtig sind Tests mit unterschiedlichen Einwilligungszuständen. Erst wenn dieser Ablauf zuverlässig funktioniert, würde ich die Implementierung auf weitere Ereignisse ausweiten. Das erleichtert die Fehlersuche erheblich und reduziert das Risiko, bestehende Messungen unbeabsichtigt zu beeinträchtigen.

Für welche Unternehmen würde ich Server-Side-Tracking empfehlen?

Bei einem größeren Onlineshop mit erheblichem Werbebudget, mehreren Marketingplattformen, Backend-Bestelldaten und komplexen Attributionsanforderungen kann Server-Side-Tracking eine sehr sinnvolle Lösung sein.

Hier können die bessere Kontrolle über Datenflüsse, die Integration von Backend-Ereignissen und eine konsistentere Verarbeitung echten Mehrwert schaffen. Bei einer klassischen Unternehmenswebsite mit Google Analytics, Google Ads und einem Kontaktformular würde ich dagegen zunächst auf eine saubere clientseitige Implementierung setzen.

Wenn diese zuverlässig funktioniert, die Einwilligungen korrekt berücksichtigt und alle geschäftlich relevanten Ereignisse erfasst werden, besteht möglicherweise überhaupt kein Bedarf für zusätzliche Server-Infrastruktur. Das ist keine Entscheidung gegen moderne Tracking-Technologien. Es ist eine Entscheidung für eine technische Lösung, deren Komplexität zum tatsächlichen Bedarf passt.

Fazit: Server-Side-Tracking ist kein Selbstzweck

Server-Side-Tracking bietet interessante Möglichkeiten. Es kann die Kontrolle über Tracking-Daten verbessern, die Verarbeitung von Ereignissen zentralisieren, Backend-Systeme besser einbinden und unter bestimmten Bedingungen die Zuverlässigkeit der Messung erhöhen.

Gleichzeitig verursacht es zusätzlichen Implementierungs-, Hosting- und Wartungsaufwand. Es löst keine grundlegenden Probleme mit falsch definierten Conversions, fehlerhaften Ereignissen oder unklaren Datenstrukturen. Und es macht eine Tracking-Implementierung weder automatisch datenschutzkonform noch vollständig unabhängig von Browserbeschränkungen.

Die entscheidende Frage lautet deshalb nicht: „Sollten wir Server-Side-Tracking einsetzen?“

Sondern:

„Welches konkrete Problem lösen wir damit, und rechtfertigt der Nutzen die zusätzliche Komplexität?“

Wenn Server-Side-Tracking zu zuverlässigeren Daten, besser kontrollierbaren Integrationen und fundierteren Geschäftsentscheidungen führt, kann sich der Aufwand lohnen. Wenn dieselben Ziele mit einer einfacheren clientseitigen Implementierung erreicht werden können, ist diese häufig die bessere technische Entscheidung.

Bei meinen Projekten im Bereich Webanalyse und Conversion-Tracking beschäftige ich mich sowohl mit klassischen browserseitigen Implementierungen als auch mit serverseitigen Tracking-Architekturen. Dazu gehören die Konzeption relevanter Ereignisse, die technische Integration, Consent Management und die erforderliche Infrastruktur.

Mein Ansatz ist dabei unabhängig von der gewählten Technologie: Tracking sollte nicht möglichst kompliziert sein, sondern zuverlässig die Daten liefern, die ein Unternehmen tatsächlich benötigt.