Entwickeln & verbinden
Automatisieren
GA4 & Server-Side Tracking
Wir prüfen Ihr bestehendes Tracking, richten GA4 und serverseitige Messung ein und setzen die Einwilligungen für Ihre Marketing-Tools sauber auf.
Wir richten Ihr Tracking so ein, dass Sie in einer Übersicht genau den Umsatz sehen, der auch in Ihrer Bestelldatenbank steht. Wenn Sie über Ihr Werbebudget entscheiden, stützen Sie sich damit auf verlässliche Zahlen.
Überblick
Wir gleichen Ihre Statistiken mit der Bestelldatenbank ab, damit Ihr Werbebudget auf verlässlichen Zahlen beruht.
Häufig zeigt das Shop-Backend eine Bestellzahl, GA4 eine zweite und die Werbeplattform eine dritte. Wenn drei Zahlen nebeneinanderstehen, ist kaum zu entscheiden, welche als Referenz gilt, und Budgetentscheidungen fallen aus dem Bauch heraus. Meist genügt es, die Erfassung und Übermittlung der Ereignisse neu zu ordnen, damit alle drei Werte wieder übereinstimmen.
Wir bauen das Tracking als Teil Ihres Systems auf, sodass die Daten direkt aus der Bestelldatenbank stammen. Kaufereignisse senden wir auf zwei Wegen – aus dem Browser und vom Server – mit einer gemeinsamen Event-ID, damit derselbe Kauf nur einmal gezählt wird. Personenbezogene Daten sichern wir vor dem Versand per Hashing, also durch Umwandlung in einen nicht umkehrbaren Hashwert, und das gesamte Tracking folgt den Einwilligungen, die der Nutzer erteilt hat.
Das Ergebnis ist eine Zahl, die Sie direkt neben den Verkaufsbericht legen können, weil beide übereinstimmen. So stützen sich Gespräche über die Rentabilität Ihrer Kampagnen und darüber, welcher Kanal tatsächlich Bestellungen bringt, auf Daten, denen Sie vertrauen.
Anzahl und Wert der Bestellungen im Bericht stimmen mit Ihrem System überein.
Das Ereignis entsteht, sobald die Bestellung in der Datenbank gespeichert wird – so zählt jeder Kauf.
Eine gemeinsame Event-ID sorgt dafür, dass derselbe Kauf genau einmal gezählt wird.
Das Tracking richtet sich nach der Einwilligung, die der Nutzer erteilt hat.
Von der Bestandsaufnahme über serverseitiges Tracking bis zu Berichten, die Ihre Budgetentscheidungen tatsächlich unterstützen.
Wir prüfen, welche Tags (also Codeschnipsel, die Daten erfassen) tatsächlich funktionieren, welche Ereignisse doppelt ausgelöst werden und welche fehlen. Anzahl und Wert der Bestellungen in Ihren Analysetools vergleichen wir mit den Daten in der Datenbank und benennen die Ursache jeder Abweichung, damit Sie wissen, welchen Zahlen Sie vertrauen können.
Wir bilden den vollständigen Kaufprozess im Tracking ab – von der Produktansicht über „In den Warenkorb“ und den Start des Checkouts bis zum Kaufabschluss – mit korrekten Produkt-IDs, Varianten, Währung und dem Wert nach Rabatten. Die Konfiguration halten wir über alle Märkte und Sprachversionen hinweg einheitlich, damit sich die Daten der einzelnen Märkte direkt vergleichen lassen.
Wir messen parallel aus dem Browser und vom Server – über die Conversions API gehen Kaufdaten direkt aus Ihrem Backend an die Werbeplattform – und verbinden beide Wege über eine gemeinsame Event-ID, damit derselbe Kauf einmal zählt. Personenbezogene Daten sichern wir vor dem Versand ab, Retouren und Korrekturen übertragen wir mit, und das Tracking funktioniert auch dann, wenn im Browser des Kunden Blocker aktiv sind.
Den Einwilligungsstatus übergeben wir an die Tracking-Tools und berücksichtigen ihn auch serverseitig, damit das Tracking der Entscheidung des Nutzers folgt. Dazu kommen eine Möglichkeit direkt auf der Website, die Einwilligung zu ändern, und eine echte Cookie-Tabelle für Ihre Datenschutzerklärung, damit die Angaben dort mit dem tatsächlichen Tracking übereinstimmen.
Wir erstellen Produktfeeds (also Ihre Produktliste in einem Format, das Werbesysteme lesen) für Google Merchant Center und Marketing-Automation-Tools: Wir gruppieren Varianten, ergänzen Pflichtattribute und prüfen den Feed vor der Veröffentlichung. Abgelehnte Artikel landen mit dem konkreten Grund in einem Bericht, sodass Ihr Sortiment vollständig in den Anzeigen erscheint.
Wir richten regelmäßige Berichte direkt aus der Datenbank und den Analysetools ein, per E-Mail oder im Dashboard, damit Sie ein einheitliches Bild Ihrer Umsätze haben. Zusätzlich überwachen wir laufend den Eingang der Ereignisse: Wenn das Tracking ausfällt, wissen Sie es noch am selben Tag, und die Lücke in Ihren Daten bleibt kurz.
Grundlagen
Diese eine Unterscheidung erklärt die meisten Abweichungen in Ihren Statistiken. Es lohnt sich, sie zu kennen, bevor Sie über ein weiteres Tool entscheiden, weil sie meist direkt zur Lösung führt.
Klassisches Tracking ist ein Skript, das im Browser des Kunden läuft. Damit ein Kauf gezählt wird, muss die gesamte Kette funktionieren: Das Skript muss laden, der Kunde muss von der Zahlungsseite auf die Danke-Seite zurückkehren und lange genug dort bleiben, bis die Daten gesendet sind. Wenn ein Glied ausfällt – eine Erweiterung, die Skripte blockiert, ein geschlossener Tab, eine abgebrochene Mobilfunkverbindung –, bleibt die Bestellung in der Datenbank, kann aber in den Statistiken fehlen.
Serverseitiges Tracking schließt diese Lücke. Das Ereignis entsteht in dem Moment, in dem die Bestellung in der Datenbank gespeichert wird oder ihr Status auf „bezahlt“ wechselt, sodass die Daten direkt aus der Quelle Ihrer Umsätze stammen. Das ist besonders wichtig bei Zahlungen, die das Payment-Gateway per Benachrichtigung bestätigt (also mit einem automatischen Signal des Zahlungsanbieters an Ihren Shop), weil eine Bestellung mitunter erst lange nach dem Verlassen des Shops als bezahlt gilt.
Browser-Tracking behält dabei seinen Platz, weil es Kontext liefert, den der Server allein nicht hat: woher der Traffic kommt und was sich der Nutzer vor dem Kauf angesehen hat. Ein sauber eingerichtetes Setup verbindet beide Quellen und sorgt dafür, dass derselbe Kauf nur einmal zählt – so haben Sie vollständige Daten und ein einziges Ergebnis.
| Situation | Browser-Tracking | Serverseitiges Tracking |
|---|---|---|
| Browser-Erweiterung blockiert Skripte | Das Ereignis wird gar nicht erzeugt | Entsteht unabhängig vom Browser des Kunden |
| Kunde schließt den Tab direkt nach der Zahlung | Daten verlassen den Browser womöglich nicht mehr rechtzeitig | Versand, sobald die Bestellung in der Datenbank gespeichert ist |
| Zahlung wird per Benachrichtigung des Gateways bestätigt | Beim Seitenaufruf ist der Status noch unbekannt | Ereignis nach geprüfter Benachrichtigung, mit echtem Status |
| Bestellwert mit Rabatt | Oft aus Katalogpreisen im Template berechnet | Aus dem in der Bestellung gespeicherten Betrag übernommen |
| Daten für den Conversion-Abgleich | Im Klartext gesendet oder weggelassen | Vor dem Versand serverseitig gehasht |
| Begrenzte Laufzeit von Kennungen | Vom Browser verkürzt, die Customer Journey reißt ab | Kennung wird von der Anwendung gesteuert |
| Retoure oder Stornierung einer Bestellung | Umsatz wird mitunter zu hoch ausgewiesen | Korrektur wird nach dem Statuswechsel gesendet |
Webanalyse misst genau so viel, wie ihre Konfiguration zulässt. Solange die Standardeinstellungen aktiv sind, erfasst sie weniger, als möglich wäre – diese Lücke schließen wir, damit Ihre Daten vollständig sind.
Erkenntnis aus den Tracking-Audits, mit denen wir jedes Projekt beginnen
Audit
Diese Muster finden wir in den meisten Setups, die wir übernehmen – deshalb wissen wir, wo wir suchen, und sorgen zügig für saubere Daten.
Im Detail
Event-Deduplizierung
Wird ein Kauf parallel aus dem Browser und vom Server gesendet, ist das Tracking robust gegen Blocker, und eine gemeinsame Event-ID sorgt dafür, dass dieselbe Bestellung nur einmal zählt. Wir vergeben die ID beim Anlegen der Bestellung, speichern sie mit der Bestellung und nutzen sie auf beiden Wegen. So führt die Werbeplattform beide Signale zusammen und behält einen Kauf – und Sie sehen im Bericht eine Zahl, die mit der Datenbank übereinstimmt.
Genauso sorgfältig behandeln wir die Daten, mit denen sich ein Kauf einem Nutzer zuordnen lässt. E-Mail-Adresse oder Telefonnummer wandeln wir vor dem Versand per Hashing in einen nicht umkehrbaren Wert um, damit der Abgleich funktioniert und für Menschen lesbare Daten in Ihrem System bleiben. Wenn die Marketing-Einwilligung fehlt, sendet weder der Browser noch der Server das Ereignis – so bleibt das Tracking DSGVO-konform.
Außerdem sorgen wir für saubere Daten: Eine wiederholte Benachrichtigung des Payment-Gateways erzeugt keinen zweiten Kauf, eine Retoure führt zu einer Wertkorrektur, und die Produkt-IDs sind in Shop, Feed und Ereignissen einheitlich. So bleiben Ihre Zahlen auch nach Retouren und doppelten Benachrichtigungen dauerhaft verlässlich.
Performance
Die Ladezeit wirkt sich doppelt auf Ihre Ergebnisse aus: Wenn Inhalte langsam laden, springt ein Teil der Nutzer früher ab, und die Tracking-Skripte haben weniger Zeit, Ereignisse zu senden. Deshalb führen wir das Tracking-Audit zusammen mit einem Performance-Audit durch – wir messen die Core Web Vitals, also die von Google erhobenen Kennzahlen für Geschwindigkeit und Stabilität einer Seite, auf echten Geräten und bei realer Bandbreite, damit die schnellere Seite zu mehr abgeschlossenen Käufen und vollständigeren Daten führt.
Wir prüfen, wie viele externe Skripte wirklich geladen werden müssen und in welcher Reihenfolge, ob Bilder die passenden Formate und Abmessungen haben und ob bei jedem Seitenaufruf mehr Daten als nötig abgerufen werden. Außerdem testen wir die Darstellung in Chrome, Safari und Chromium, die dasselbe Layout unterschiedlich rendern können, und auf schmalen Bildschirmen ab 320 px Breite, damit der Shop auf jedem Smartphone gleich aussieht.
Sie erhalten eine Liste, priorisiert nach Wirkung und Aufwand: was zuerst verbessert werden sollte, was warten kann und was Änderungen im Backend erfordert – so wissen Sie, womit Sie anfangen, um den Unterschied am schnellsten zu sehen.
So arbeiten wir
Wir erfassen alle aktiven Tags und Ereignisse und stellen die Daten aus den Analysetools der Anzahl und dem Wert der Bestellungen in der Datenbank gegenüber. Zu jeder Abweichung nennen wir die Ursache, damit Sie wissen, woher sie kommt und wie sie sich beheben lässt.
Wir legen die Liste der Ereignisse, ihre Parameter und eine verlässliche Quelle für jeden Wert fest, damit die Herkunft jeder Zahl klar ist. Wir dokumentieren, was aus dem Browser kommt und was vom Server, wie wir sicherstellen, dass ein Kauf einmal zählt, und welche Ereignisse von der Marketing-Einwilligung abhängen.
Die Tracking-Schicht bauen wir auf einer separaten Kopie Ihres Shops (Staging), auf der wir Änderungen ohne Risiko für den laufenden Verkauf testen: Ereignisse in der Anwendung, Versand vom Server, Consent-Handling, Absicherung der Daten und Statuskorrekturen. Im Live-Shop schalten wir alles schrittweise frei, mit der Möglichkeit, jede Änderung zurückzunehmen, damit der Rollout sicher verläuft.
Über einen vereinbarten Zeitraum vergleichen wir die Ereignisse Kanal für Kanal mit den Bestellungen in der Datenbank und beheben Abweichungen, bis die Zahlen übereinstimmen. Zum Abschluss richten wir eine laufende Überwachung des Ereigniseingangs und Alerts ein, damit Sie sofort Bescheid wissen, falls die Zahlen wieder auseinanderlaufen.
Jeder dieser drei Fälle kommt in vielen Shops vor. Darunter sehen Sie jeweils, wie wir die Zahlen wieder in Einklang bringen – so erhalten Sie Daten, auf die Sie sich bei der Budgetplanung verlassen können.
Serverseitiges Tracking
Das Bestellsystem zeigt mehr Käufe als GA4 und der Werbeanzeigenmanager. Die Abweichung wächst bei bezahlten Kampagnen und schrumpft beim direkten Traffic.
Das Kaufereignis sendet der Browser von der Danke-Seite. Wenn das Skript blockiert ist, der Tab geschlossen wird oder die Zahlung erst nach dem Verlassen des Shops bestätigt wird, entsteht das Ereignis womöglich gar nicht.
Wir verlagern die Kaufmessung auf den Server und koppeln sie an den Statuswechsel der Bestellung in der Datenbank, damit jeder Kauf zählt. Das Browser-Tracking bleibt für den Kontext aktiv, und eine gemeinsame Event-ID sorgt dafür, dass der Kauf einmal gezählt wird. Personenbezogene Daten werden gehasht, und Marketing-Ereignisse folgen der Einwilligung.
Tracking-Audit
Der Bericht weist Umsatz aus, der in der Buchhaltung nicht auftaucht. Einzelne Tags abzuschalten fällt schwer, solange unklar ist, welche Messung dadurch zusätzlich wegfällt.
Das Kaufereignis ist oft an drei Stellen gleichzeitig eingebunden: im Template, im Tag-Manager und in einem Plugin. Jede weitere Implementierung bringt eine eigene Quelle mit, und die vorherige bleibt aktiv. Außerdem zählt jedes Neuladen der Danke-Seite denselben Kauf erneut.
Wir erfassen jede Ereignisquelle und gleichen sie Tag für Tag mit den Bestellnummern aus der Datenbank ab. Die Quellen schalten wir einzeln ab und messen die Wirkung jedes Schritts, damit nichts Benötigtes verschwindet. Der Kauf erhält einen Schlüssel mit der Bestellnummer, sodass Wiederholungen nicht mehr mitzählen.
Einwilligungen
Von einem Tag auf den anderen sinkt die Zahl der Ereignisse um eine Größenordnung. Der Umsatz im Shop bleibt auf demselben Niveau, also liegt die Abweichung beim Tracking.
Die Tracking-Skripte warten auf ein Signal, dass über die Einwilligung entschieden ist. Bei einem Teil der Nutzerentscheidungen kommt dieses Signal nie an, sodass die Tools auch dann stumm bleiben, wenn die Einwilligung erteilt wurde.
Wir setzen den Einwilligungsstatus, bevor die Tools laden, und aktualisieren ihn nach jeder Änderung, auch im Versand vom Server, damit das Tracking der Entscheidung des Nutzers folgt. Ereignisse, die vor der Entscheidung entstehen, stellen wir in eine Warteschlange. Die laufende Überwachung des Ereigniseingangs erkennt einen weiteren solchen Einbruch noch am selben Tag.
FAQ
Nein. Die Einwilligung bezieht sich auf den Zweck der Datenverarbeitung und gilt deshalb für Browser und Server gleichermaßen: Wenn ein Nutzer die Marketing-Einwilligung ablehnt, sendet auch der Server kein Ereignis. Serverseitiges Tracking löst eine andere Aufgabe: Es erfasst Fälle, in denen die Einwilligung vorliegt, das Ereignis aber trotzdem verloren ginge, weil der Browser es blockiert oder der Kunde den Tab vor dem Senden schließt. So erhalten Sie vollständige Daten, und jede Entscheidung im Consent-Banner bleibt gewahrt.
Ein Audit zeigt, ob Ihr eingerichtetes GA4 auch korrekte Daten liefert. Wir vergleichen Anzahl und Wert der Bestellungen in den Analysetools mit dem Stand in der Datenbank und prüfen die häufigsten Ursachen für Abweichungen: fehlende Ereignisse im Kaufprozess, Werte vor Rabatt, doppelte Tags aus früheren Implementierungen und interner Traffic, der in den Umsatz einfließt. Sie erhalten eine Liste der Abweichungen mit Ursache und Lösungsvorschlag und wissen so, welchen Zahlen Sie vertrauen können.
Auf die einzelne Bestellung genau lässt sich das seriös nicht zusagen. Analysetools haben eigene Attributionsmodelle, Zeitfenster und Regeln für die Zählung von Sitzungen, deshalb sind kleine Abweichungen normal. Unser Ziel ist eine Abweichung, die klein, stabil und nachvollziehbar ist – dann lässt sich der Bericht von Monat zu Monat vergleichen und als verlässliche Grundlage für Budgetentscheidungen nutzen.
In der Regel bleibt Ihr Shop unverändert. Wir binden die Tracking-Schicht an die bestehende Anwendung an, ob MedusaJS, Shopify, WooCommerce, WordPress oder ein eigenes Backend in Node.js, PHP oder Python, und der Shop läuft ohne Umbau weiter. Dafür brauchen wir Zugriff auf die Stelle, an der eine Bestellung entsteht oder ihren Status ändert, sowie auf die Benachrichtigungen des Payment-Gateways. Wenn solche Anknüpfungspunkte fehlen, ergänzen wir sie im selben Zug, damit der laufende Verkauf während der Umsetzung ungestört bleibt.
An einem Alert. Wir überwachen laufend den Eingang der wichtigsten Ereignisse und vergleichen ihn mit der Zahl der Bestellungen in der Datenbank. Wenn der Datenstrom abreißt oder die Abweichung einen vereinbarten Schwellenwert überschreitet, senden wir eine Benachrichtigung per E-Mail oder in den Kanal Ihres Teams, sodass Sie noch am selben Tag reagieren. Das ist wichtig, weil Tracking-Lücken meist beim Release einer neuen Shop-Version entstehen und sich mit laufender Überwachung sofort schließen lassen, solange die fehlende Datenmenge noch klein ist.
Um die technische Seite, ja. Für Ihre Datenschutzerklärung liefern wir eine echte Tabelle der eingesetzten Cookies, eine Liste der Datenempfänger und Angaben zur Übermittlung in Länder außerhalb des EWR, und auf der Website richten wir eine jederzeit erreichbare Möglichkeit ein, Einwilligungen zu ändern. Die Angaben im Dokument gleichen wir mit dem ab, was der Code tatsächlich tut, und listen Abweichungen mit dem Namen des Skripts auf, damit Sie sicher sein können, dass Erklärung und Funktion übereinstimmen. Die rechtliche Bewertung und die endgültige Fassung übernimmt Ihre Rechtsberatung, und wir liefern die technische Dokumentation, auf die sie sich stützen kann.
Schreiben Sie uns, womit Sie heute messen und wo Sie Abweichungen in den Zahlen sehen – gern auf Deutsch oder Englisch. Wir antworten innerhalb eines Werktags. Am Anfang steht ein Audit, das zeigt, woher die Abweichung kommt und was ihre Behebung kostet, damit Sie Budgetentscheidungen auf verlässliche Daten stützen.