Neukunden- und Bestandskunden-Conversions getrennt tracken via GTM

Bessere Kampagnen Evaluation dank Kunden-Typisierung

In den letzten Jahren hat sich ein spannender Trend im Performance Marketing herauskristalisiert: Marketer tracken nicht nur Conversions, sondern unterscheiden auch in Neu- und Bestandskunden-Conversions bei der Beurteilung von Kampagnen-Performance. Welche Implikationen das für das Performane-Marketing-Reporting hat, erfährst du im Abschnitt über Performance Marketing-Implikationen weiter unten im Artikel.

Dieser Umstand hat sogar dazu geführt, dass einige SaaS Tools die getrennte Ausweisung von Neu- und Bestandskunden-Conversions als neues „Paid Mega Feature“ in ihren Werbematerialien listen. Etwas aufgeblasen, wie wir von THE BIG C Agency finden. Der folgende Artikel zeigt, wie diese Art des Trackings auch mit Bordmitteln funktioniert.

Wir fokussieren hierbei auf eine generelle Umsetzung via Server Side GTM für Systeme wie GA4 und Ad Networks (Meta, TikTok) auf Basis verschiedener Shopsysteme (Shopify, Shopware, etc.).

Inhalt

• Technische Voraussetzungen: Frontend, GTM, Shop
• Google Tag Manager Event Neu- und Bestandskunden Purchase Triggers
• Abholung der Kundentypisierung im Shop-Backend
• Kompatibilität mit Werbenetzwerken und Shopsystemen
• Fallen und Disclaimer für die Implementierung
• Performance Marketing Auswirkungen von Neu- und Bestandskunden-Conversion-Tracking

Technische Voraussetzungen für die Erhebung von Neu- und Bestandskunden Conversions

Stellt euch das Szenario wie folgt vor: Ein Kunde bestellt in eurem Shop und landet auf der Bestellbestätigungsseite. In der klassischen E-Commerce-Tracking-Welt wird ein Purchase-Conversion-Event mit den Bestelldaten an GA4 und Werbenetzwerke gesendet. So weit, so bekannt. Diesen Vorgang wollen wir auch gar nicht beeinflussen, weil er die Basis für gutes Reporting darstellt – Kauf bleibt Kauf. Dieses Main-Event heißt meistens: purchase.
Nun gehen wir aber einen Schritt weiter und wollen im Nachgang noch mindestens ein weiteres Conversion-Event senden: Entweder purchase_new_customer oder purchase_existing_customer – je nachdem ob ein Kunde vor dieser Bestellung bereits mindestens einmal bestellt hat oder nicht.

Das Ziel: In unseren GA4- und Advertising-Reports wollen wir am Ende die Anzahl der purchase-Events, purchase_new_customer- und purchase_existing_customer-Events in unserem Kanal- und Kampagnen-Split ausweisen können.

Die technische Herausforderung in diesem Szenario: Häufig wird zum Zeitpunkt des Kaufs die Information ob es sich um unseren Neu- oder Bestandskunden handelt, noch nicht für die Tracking-Software bereitgestellt. Diese Information lagert meist gut gehütet in den Datenbanken des Shopsystems. Entsprechend versuchen wir diese Information mithilfe des Google Tag Managers aus dem Backend zu erhalten, ehe wir sie für ein weiteres Tracking-Event verwenden.

Damit diese zusätzlichen Events ausgewiesen werden können, sollte das initiale Purchase Event im Shop-Frontend eine der folgenden Infos bereistellen:

• Customer ID: Best Case Szenario. Anhand der Customer ID kann man im Backend schnell ermitteln, wie viele Bestellungen für diese ID vorliegen.
• Transaction ID: Muss eigentlich für jedes Purchase Event vorliegen. Von der Bestellnummer kann man dann auf die Customer ID und dann auf die Anzahl der Bestellungen schließen.
• E-Mail-Adresse: Gute Identifier für die Zuordnung von Bestellanzahlen, aber: Dieser Identifier sollte bei der Implementierung mit Vorsicht behandelt werden, da er Datenschutz-Implikationen hat und nicht an jedes System gesendet werden sollte.

Darüber hinaus sollten die folgenden Voraussetzungen erfüllt sein:

• Google Tag Manager Client-Side Implementierung im Frontend
• Funktionierende GA4-Implementierung im Frontend
• Passende DataLayer-Events im Frontend
• Laufende Server Side Google Tag Manager Instanz
• Shop-System mit API-Capabilities (sollte jedes gute Shopsystem haben)

Ziel: Neu- und Bestandskunden-Events Tags im Server Side GTM Container

Das Ziel, in dem wir rauskommen wollen ist simpel: Wir wollen entweder ein Neukunden-Purchase-Event (purchase_new_customer) oder ein Bestandskunden-Purchase-Event (purchase_existing_customer) feuern, nachdem das eigentliche Purchase Event (purchase) im Server Side GTM angekommen ist.

(In einer leanen Umsetzung kann das Ganze mithilfe von Lookups auch in einem Tag umgesetzt werden, für die Show und den Hype haben wir aber für diesen Artikel aber zwei neue Tags erstellt.)

Wichtig ist aber, dass die neuen Events das Purchase Event (Trigger) aus dem normalen Order Flow als Ausgangspunkt nehmen.

Der Vorteil bei einer Umsetzung über den Server Side GTM ist dabei, dass wir praktisch nur die Informationen aus dem initialen Kauf-Event recyclen. Es gibt keine zusätzlichen Tracking-Hits im Browser des Kunden und wir müssen nicht warten, dass der Kunde die Seite länger geöffnet lässt oder zusätzliche Handlungen durchführt.

Abholung der Kundentypisierung im Shop-Backend

Um nun aber Purchase-Event noch schlauer zu machen, nehmen wir eine Google Tag Manager Transformation zur Hilfe. Diese performt folgende Aktionen:

• Entgegennahme des Purchase Events
• Extraktion der Customer ID aus den Event Infos
• Abfrage der Anzahl der Bestellungen für die Customer ID im Shop-Backend (via HTTP API Request)
• Hinzufügen des Order Counts zum Purchase Event

	
// HTTP Response
{
  data: {
    ordersCount: {
      count: 0, 
      precision: "EXACT"
    }
  }
}

Mit diesen zusätzlichen Event-Informationen können wir nun einen smarteren Event-Trigger erstellen, der unsere neuen Tags auf Basis der Bestellanzahl reglementiert.

Dieser Prozess erfordert natürlich ein paar zusätzliche Voraussetzungen, die aber normalerweise relativ gut zu erfüllen sind:

• Vorliegen einer Shop-API URL
• Kenntnis über die Request-Struktur der Shop-API
• Eine API Authentifizierung, z.B. in Form eines API-Keys

Damit schickt unser Server Side GTM-Container nun immer mindestens 2 Events im Fall eines Kaufs über den Shop:

1. Ein generisches Purchase Conversion Event
2. Ein spezifisches Neu- oder Bestandskunden Purchase Event auf Basis der Anzahl der vorhandenen Bestellungen.

Kompatibilität mit Werbenetzwerken und Shopsystemen

Werbenetzwerk-Kompatibilität

Dieses Beispiel ist nun sehr GA4-lastig. Aber, auf Basis der zugrundeliegenden Mechanik können auch typische Werbenetzwerke (dort, wo das meiste Geld ausgegeben wird) mit zusätzlichen Conversion-Events bedient werden. Dazu zählen:

• Meta (facebook und instagram via CAPI)
• Google Ads (wenn nicht direkt Conversions aus GA4 importiert werden)
• TikTok
• LinkedIn
• etc.

Hinweis: Die wenigsten bzw. nahezu kein Werbenetzwerk bietet einen Standard-Conversion-Typ für Neu- und Bestandskunden-Conversions an. Hier musst du entweder Custom Events schicken und validieren oder kreativ werden und die Events als „Registration“ oder „Lead“ deklarieren (und dir vor allem merken, welches Event gemeint war).

Shopsystem-Kompatibilität

Der Proof of Concept aus diesem Artikel wurde anhand eines Shopify-Shops erstellt. Shopify hat eine gut dokumentierte API und performante Endpunkte. Allerdings wäre es für ein Shopify-System auch nicht zwangsläufig notwendig diesen Lösungsweg zu gehen, weil Shopify bereits per default Attribute wie is_first_order zum Zeitpunkt des Kaufs im Frontend bereitstellen kann.

Allerdings kann die Lösung auf so ziemlich alle gängigen Shopsysteme übertragen werden. Dazu zählen:

• WordPress + Woocommerce
• Shopware
• Magento
• PrestaShop
• BigCommerce

Für manche Enterprise-Systeme sind ggf. spezifische Lizenzen erforderlich.

Solltest du ein Custom Shop-System nutzen: Erstmal Sorry. In 2026 ist das wahrscheinlich anstrengend. Aber: Du müsstest einmal die API Capabiliites deines Shopsystems evaluieren. Meistens haben aber auch Custom Shopsysteme API Fähigkeiten, da sie an irgendeinem Punkt Daten mit anderen Systemen austauschen müssen.

Kosten für das Conversion Tracking Setup

Je nach Größe (Trafficvolumen) des Shops ist das beschriebene Setup extrem günstig. Kleine Shops mit Standard-Shopsystem und einem einfachen Server Side GTM Container bezahlen wahrscheinlich nur zwischen 0€ und 20€ pro Monat für die Lösung. Für größere Shops ist der determinierende Kosten-Faktor der Server Side GTM Container bzw. die zugrundeliegenden Cloud-Kosten. Aber selbst mit hohem Request-Load sollten diese Kosten 50€ im Monat nicht übersteigen. Des Weiteren sollte es ohnehin ein Server Side Infrastruktur für die „normalen“ Tracking-Hits geben, sodass die Kosten nicht „extra“ für das Bestandskunden-Tracking entstehen.

Die Bepreisung von API Calls durch Shopsysteme ist im Markt unüblich und beeinflusst die Kosten entsprechend nicht.

Dabei muss die Kostenbetrachtung immer mit den zu erwartenden Einsparungen im Performance-Marketing-Apparat abgewogen werden. Die Kostenschätzungen enthalten lediglich Infrastruktur-Kosten und keine möglichen Implementierungskosten.

Disclaimer & Gotchas für die Implementierung der neuen Conversion-Events

Bei der Implementierung sollten folgende Dinge beachtet werden:

Wie bereits erwähnt, werden die Neu- und Bestandskunden Purchase Events normalerweise in Werbenetzwerken nicht als Standard-Events supportet (d.h. es gibt keinen 1:1 Counterpart in deren Event-Model). Darum müssen die neuen Events entweder als Custom gesendet werden oder auf Standard-Events wie „Sign-Up“ oder „Lead“ oder „Add To Basket“ gemappt werden.

Bei der Übersendung der Conversions als Custom Events kann es sein, dass es zu Einschränkungen bei der Kampagnen-Aussteuerung kommt. Nicht alle Netzwerke unterstützen automatisierte Kampagnen-Steuerung auf Basis von Custom Events.

Bei der Übersendung der neuen Conversionevents als „Fake“ Standard-Events (z.B. „Sign-Up“) kann es zu Problemen mit der automatisierten Kampagnen-Aussteuerung kommen, weil die Algorithmen der Networks nicht passend auf die Nutzung dieser trainiert wurden.

Bei der Nutzung der E-Mail-Adresse als Identifier (nicht empfohlen) muss extra vorsichtig gearbeitet werden. So sollte ausgeschlossen werden dass dieses Attribut überhaupt vom server side GTM an ein Drittsystem (GA4, Meta, o.ä.) gesendet wird. Dies wird über Parameter-Übergabe-Ausschlüsse und Transformation geregelt, muss aber für alle Tags geregelt sein.
Zwar nehmen diese Drittsysteme auch E-Mail Adressen für Enhanced Conversion entgegen, allerdings werden diese in der Regel vorher gehasht. Für einen Customer Lookup muss die E-Mail-Adresse aber Klartext vorliegen.

Das Resultat des API-Requests hängt stark davon ab, wie schnell Shopsystem und Datenbanken die neue Bestellung verarbeiten. Gehe also bei der Implementierung auch davon aus, dass Neukunden bei Abfragen Fehler und Null-Werte produzieren und konfiguriere deine Tags entsprechend mit Fallbacks für error- und undefined-Outputs (die meistens auf Neukunden Conversions hinweisen).

Warum brauche ich Neu- und Bestandskunden-Conversions im Marketing?

Hier noch der Abbinder zu verschiedenen Conversion-Typen im Performance-Marketing. Die Frage: Warum sollte ich entsprechende Anpassungen im Google Tag Manager Setup vornehmen, erklärt sich dabei relativ gut unter folgenden Anwendungsfällen:

Kampagnen sammeln zu viele Bestandskunden ein

Gehen wir mal von der Prämisse aus, dass viele Online-Marketing-Kampagnen dafür gemacht sind, um neue Kunden zu akquirieren. In dieser Welt sollten Bestandskunden im Idealfall über Direkteingaben in den Shop gehen oder per günstigen E-Mail-Newslettern zu weiteren Käufen animiert werden und teure Marketing-Kampagnen gar nicht zu sehen bekommen. So weit, so logisch – aber häufig auch unpraktikabel.

Setze ich nun also eine Neukunden-Kampagne mit hohem Budget + Gutschein-Code über Meta auf, wäre ich einigermaßen unzufrieden, wenn diese Kampagne nur Geld kostet und alle Purchases, die sie als Conversion ausweist, Käufe von Bestandskunden sind. Also Kunden, die mich ohnehin schon kennen sollten. Die Ausweisung von Bestandskunden-Conversions im Kampagnen-Reporting ist also essenziell für Performance-Beurteilung dieser Kampagne.

Segmentierung von Audiences über Events

Wenn ich über meine Performance-Evaluationsphase hinaus bin, kann ich die neuen Conversion-Events auch für Segmentierungszwecke nutzen. Habe ich zum Beispiel ein Produkt, das einen klaren Upsell-Pfad hat, kann ich ein Segment erstellen mit Usern, die das Event purchase_new_customer in einem gewissen Zeitraum ausgelöst haben. So weiß ich, dass ein initialer Kauf vorliegt und womöglich noch Bedarf für ein Up- oder Cross-Sell-Artikel vorliegt.

Entsprechend kann ich detaillierte Kampagnen in Google Ads oder Meta konfigurieren, die diese Information nutzen und Kunden identifizieren, die gerade noch in der Onboarding-Phase sind.

Bestandskunden-Retargeting

Der erweiterte Fall sind Kampagnen für eine Zielgruppe, die bereits ein purchase_existing_customer Event verursacht hat. Dies ist normalerweise eher unüblich, aber in Abhängigkeit vom Geschäftsmodell denkbar. Kampagnen, die als Dankeschön für loyale Kunden gedacht sind (z.B. mit hohen Gutscheindcodes), könnten so auch auf Kunden mit mehr einer Bestellung eingeschränkt werden.

Entsprechend wird auch hier eine passende Audience für das Segment eingerichtet.

Validierung von Demarkierungs-Mechanismen

Für die Kontroll-Freaks unter uns: Normalerweise sollten Kampagnen in Networks so konfiguriert sein, dass sie User ausschließen, die bereits etwas gekauft haben. D.h. es wird ein Ausschluss-Segment gebaut, dass Nutzer zeigt, die das purchase Event ausgelöst haben.

Kampagnen mit diesem Ausschluss sollten – im besten Fall – also keine Bestandskunden-Conversions verursachen. Das ist allerdings nur bedingt umsetzbar, weil Cookies und Identifizierungen auslaufen oder Nutzer gelegentlich Browser und Endgeräte wechseln. Eine zusätzliche Ausweisung der Bestandskunden-Conversions in solchen Kampagnen gibt eine gute Indikation darüber, wie effektiv die Ausschlüsse der Purchase-Segmente wirklich sind.