WordPress Server-side Tracking von Leads: So verfolgst du Formular-Conversions mit sGTM

Kurze Zusammenfassung: Beim Lead-Tracking in WordPress wird ein Klick auf „Absenden“ in der Regel bereits als Conversion gewertet, noch bevor die Validierung, die Spam-Prüfung und die Speicherung stattgefunden haben. Beim server-side Tracking wird der Auslöser in dein Backend verlagert: Zähle den Lead erst dann, wenn WordPress einen gültigen Eintrag akzeptiert und speichert, und sende dieses Event dann über den server-side Google Tag Manager an GA4, Google Ads und Meta. Die gespeicherte Eintrags-ID wird zum gemeinsamen Schlüssel, der einem Lead-Formular sonst fehlt.

Ein WooCommerce-Kauf bietet Tracking-Tools reichlich Datenmaterial. Es gibt eine Bestellung, eine Bestellnummer, einen Wert und einen eindeutigen Zeitpunkt, an dem die Transaktion tatsächlich zustande kommt.

Die Lead-Generierung mit WordPress ist etwas chaotischer.

Eine Agentur hat ein Kontaktformular und Calendly. Ein B2B-Unternehmen zählt vielleicht eine Demo-Anfrage und entscheidet erst Wochen später, ob es sich um einen qualifizierten Lead handelte. Diese Customer Journeys haben selten eine natürliche Transaktions-ID.

Beim Browser-Tracking wird ein Klick auf „Absenden“ oft als Conversion gewertet. Das Formular kann aber trotzdem die Validierung nicht bestehen, von reCAPTCHA blockiert oder als Spam markiert werden. GA4 erfasst dann einen Lead, den das Unternehmen nie erhalten hat.

Beim server-side Tracking in WordPress werden deine Lead-Events über den server-side Google Tag Manager (sGTM) von deinem eigenen Server aus an GA4, Google Ads und Meta gesendet, anstatt sie über den Browser des Besuchers auszulösen. Das funktioniert am besten, wenn du von einer einfachen Regel ausgehst: Zähle das Lead, sobald dein Backend einen gültigen Eintrag akzeptiert und speichert, und sende dieses Event dann über sGTM. Wenn dein Formular-Plugin keine Einträge speichert, füge einen dauerhaften Datensatz hinzu – eine gespeicherte Zeile, auf die du später verweisen kannst – oder erstelle an genau diesem Punkt des bestätigten Erfolgs eine stabile server-side Lead-ID.

Warum das Lead-Tracking bei WordPress schwieriger ist als das E-Commerce-Tracking

Ein E-Commerce-System verfügt über ein definiertes Transaktionsobjekt. Dieselbe „transaction_id“ kann vom Shop an GA4, Google Ads und Meta weitergeleitet werden. Wenn sowohl ein Browser-Tag als auch ein Server-Tag den Kauf melden, hilft diese ID den Plattformen dabei, eine einzige Transaktion zu erkennen und nicht zwei.

Ein Service-Formular hat in der Regel keine Entsprechung. Der Browser sieht Felder und eine Absenden-Schaltfläche, während das Formular-Plugin einen eigenen Eintrag in der WordPress-Datenbank erstellt. Das Tracking muss diese beiden Momente miteinander verknüpfen, ohne jedes Mal, wenn ein Tag ausgelöst wird, einen neuen Lead zu generieren.

Es gibt noch einen weiteren Unterschied. Ein Kauf ist bereits ein Geschäftsergebnis. Ein abgeschicktes Formular kann ein echter Interessent sein, ein Bot, ein bestehender Kunde, der um Unterstützung bittet, oder jemand, der einfach nur [email protected] eingibt. Wenn man alle Formularübermittlungen als Gebotssignale nutzt, kann das die Optimierung in Richtung Übermittlungsvolumen verzerren, ohne die Qualität der daraus resultierenden Leads zu unterscheiden.

Weitere Hintergrundinformationen zu den Daten, die zwischen einer Website und GTM ausgetauscht werden, findest du in diesem Leitfaden zur Google Tag Manager-Datenebene.

Warum gibt es in WordPress kein einziges „Formular gesendet“-Event?

WordPress hat kein allgemeingültiges „Lead gespeichert“-Event. Jedes Formular-Plugin handhabt Validierung, AJAX-Anfragen, Bestätigungen, Spam-Prüfungen und Datenbankeinträge auf seine eigene Weise. Contact Form 7 speichert Übermittlungen standardmäßig nicht, während Plugins wie Gravity Forms darauf ausgelegt sind, Einträge zu speichern.

Contact Form 7 stellt DOM-Events wie „wpcf7mailsent“, „wpcf7invalid“ und „wpcf7spam“ bereit. Gravity Forms verfügt über eigene Bestätigungsereignisse und PHP-Hooks. WPForms, Ninja Forms, Fluent Forms und Elementor Pro nutzen unterschiedliche JavaScript-Events oder Backend-Aktionen. Selbst zwei mit demselben Plugin erstellte Formulare können sich unterschiedlich verhalten, wenn das eine auf eine Dankesseite weiterleitet und das andere eine AJAX-Bestätigung anzeigt.

Diese Fragmentierung ist für das WordPress-Formular-Tracking in GA4 von Bedeutung. Ein generischer GTM-Trigger für Formularübermittlungen reagiert auf die Formularaktion des Browsers. Er belegt nicht, dass das Plugin die Eingabe akzeptiert hat.

Stell dir mal einen Besucher vor, der ein Pflichtfeld für die Telefonnummer auslässt. Der „Submit“-Listener könnte ausgelöst werden, bevor die Validierung abgeschlossen ist. Der Besucher korrigiert das Feld und versucht es erneut, sodass dieselbe Person zwei Browser-Events und einen gespeicherten Lead erzeugt. reCAPTCHA und Spam-Prüfungen führen zu derselben Diskrepanz.

Plugin-spezifische Erfolgs-Events sind besser als ein allgemeiner Listener. Bei Contact Form 7 unterscheidet sich „wpcf7mailsent“ von „wpcf7submit“, das nach jeder abgeschlossenen AJAX-Übermittlung ausgelöst wird, unabhängig davon, ob eine E-Mail gesendet wurde. Beachte, dass „wpcf7mailsent“ bestätigt, dass die E-Mail versendet wurde, nicht aber, dass ein Eintrag gespeichert wurde. So oder so hängt ein Browser-Erfolgsereignis immer noch davon ab, dass JavaScript läuft und die Seite lange genug geöffnet bleibt, um die Tracking-Anfrage zu senden.

Warum Auslöser wie Dankesseiten und Erfolgsmeldungen versagen

Manche GTM-Konfigurationen warten mithilfe eines „Element-Visibility“-Triggers auf eine „Danke“-Meldung. Das kann funktionieren, wenn kein richtiger Erfolgs-Callback verfügbar ist, bindet die Messung aber an den Seiteninhalt.

Ein Designer kann die Meldung ersetzen oder in einen anderen Wrapper verschieben. Ein Optimierungs-Plugin kann das Erscheinen der Meldung verzögern. Auf mehrsprachigen Websites können WPML oder Polylang für jede Sprache eine andere Zeichenfolge und manchmal auch unterschiedliches Markup ausgeben. Ein Trigger, der nach einem bestimmten englischen CSS-Selektor oder Textfragment sucht, übersieht dann gültige Leads.

Das gegenteilige Problem tritt ebenfalls auf. Eine zwischengespeicherte Bestätigung, ein wiederholtes Formular oder eine Meldung, die während der Browsernavigation wiederhergestellt wird, kann sichtbar werden, ohne dass ein neuer Eintrag erstellt wird.

Eine eigene Dankesseite lässt sich leichter überprüfen, ist aber dennoch nur ein Ersatz. Besucher können die URL neu laden oder erneut aufrufen. Es kann auch vorkommen, dass das Formular erfolgreich gespeichert wird, während die Weiterleitung fehlschlägt.

Wie erfasst server-side Tracking einen WordPress-Lead?

Einfach ausgedrückt sieht der Ablauf so aus:

1. Der Besucher sendet ein Formular ab und das Plugin überprüft es.
2. WordPress akzeptiert die nicht als Spam eingestufte Übermittlung, speichert den Eintrag und weist ihm eine Eintrags-ID zu. Falls noch kein Eintrag vorhanden ist, erstellt das Backend eine stabile Lead-ID.
3. Ein Backend-Hook authentifiziert die Anfrage und sendet einen Webhook an den sGTM-Endpunkt.
4. Die empfangende Konfiguration überprüft die Anfrage und die Nutzdaten, bevor der Server-Container das Event zuordnet und zulässige Daten weiterleitet.
5. Ein späterer CRM-Webhook kann anhand desselben Lead-Datensatzes einen qualifizierten Lead oder einen abgeschlossenen Deal melden.

Der stärkste Auslöser ist ein Backend-Hook – eine Stelle im Code des Plugins, an der du deine eigene Aktion einbinden kannst –, der bestätigt, dass die Validierung, die Spam-Bearbeitung und die erfolgreiche Speicherung abgeschlossen sind. Der genaue Zeitpunkt im Lebenszyklus variiert je nach Plugin. Ein gespeicherter Datensatz allein reicht nicht aus, da manche Speicher-Tools, darunter auch Flamingo, Spam-Beiträge ebenfalls aufbewahren können.

Die Speicherung muss Teil des Designs sein. Contact Form 7 benötigt ein Add-on zur Speicherung von Einträgen wie beispielsweise Flamingo oder einen benutzerdefinierten Backend-Datensatz, wenn du eine dauerhafte Lead-ID haben möchtest. Andere Plugins speichern Einträge möglicherweise nur bei bestimmten Tarifen oder wenn die Speicherung von Einsendungen aktiviert ist. Überprüfe die tatsächliche Plugin-Konfiguration, anstatt davon auszugehen, dass jedes in wp-admin sichtbare Formular einen Datensatz erstellt.

Jedes Plugin stellt einen anderen Backend-Hook bereit. Ein Entwickler kann den „confirmed-success“-Hook mit einem Webhook verknüpfen – einer HTTP-Anfrage, die automatisch gesendet wird, sobald das Ereignis eintritt. Der Webhook sendet eine kleine JSON-Nutzlast – also die von dir ausgewählten Felder – an einen zulässigen Data-Client-Pfad auf deinem sGTM-Endpunkt.

Der sGTM-Client ist der Teil, der die Anfrage empfängt und deren JSON-Felder in Event-Daten umwandelt. Tags im Server-Container entscheiden dann, an welches Ziel das Event weitergeleitet wird. Diese Webhook-Übersicht erklärt das Modell, während die Anleitung zum Testen von Webhooks zeigt, wie man eine eingehende Nutzlast im Vorschau-Modus des Server-Containers überprüft. Teste mit synthetischen Datensätzen und einer minimalen, auf der Whitelist stehenden Nutzlast – niemals mit Live-Formularinhalten oder sensiblen Antworten.

Backend-Capture macht Sicherheitsmaßnahmen nicht überflüssig. Der Pfadabgleich steuert das Routing, nicht die Authentifizierung. Frag den Entwickler, ob sichergestellt ist, dass die Anfrage mit einer Signatur oder einem Geheimnis authentifiziert wird, fehlerhafte Payloads abgelehnt werden, die Anfragerate begrenzt ist und Wiederholungen verhindert werden, sofern das Design dies zulässt. Geheimnisse und Formularinhalte haben in URLs oder Debug-Logs nichts zu suchen.

Sende nur die Felder, die der Empfänger tatsächlich benötigt, und lass alles weg, was nicht ausdrücklich erlaubt ist. Medizinische Angaben, Gründe für Termine, Freitextantworten und andere sensible Daten sollten niemals an Analyse- oder Werbeplattformen gesendet werden. Du oder der rechtmäßige Eigentümer entscheidet, ob der Anwendungsfall und die Rechtsgrundlage stichhaltig sind.

Ist das für dich das erste Mal? Unsere Checkliste für den Einstieg in das server-side Tracking behandelt die Einrichtung von Container, Domain und Einwilligung – dieser Ablauf setzt voraus, dass du diese bereits eingerichtet hast.

So entdoppelst du einen Lead ohne Transaktions-ID

Lead-Formulare haben vielleicht keine „transaction_id“, aber ein Plugin, das Einsendungen speichert, weist nach erfolgreichem Speichern eine Eintrags-ID zu. Diese ID ist ein praktischer gemeinsamer Schlüssel für die Konvertierung.

Angenommen, Gravity Forms speichert den Eintrag 8742. Der Webhook kann dann einen bereichsspezifischen Wert wie „gravity-12-8742“ senden, der das Plugin, die Formular-ID und die Eintrags-ID kombiniert. Die Bereichsspezifizierung ist wichtig, wenn mehrere Formulare oder Websites dieselbe numerische ID erzeugen können.

Für die Duplikatsbereinigung bei Meta Pixel und der Conversions-API müssen das Browser-Event und das Server-Event denselben Ereignisnamen und dieselbe Ereignis-ID haben. Die Erfolgsantwort des Formulars oder der Plugin-Callback muss daher die gespeicherte Eintrags-ID an das Browser-Event weitergeben. Es funktioniert nicht, wenn du eine zufällige ID in GTM und eine weitere in PHP generierst.

Wenn der Browser die Eintrags-ID nicht empfangen kann, ist es sicherer, ein einziges verbindliches Server-Event zu verwenden, anstatt eine Browser-Kopie, die nicht zugeordnet werden kann. Die von Meta empfohlene duale Konfiguration hilft nur, wenn beide Pfade denselben Schlüssel verwenden. Die Einrichtungsanleitung für die Meta Conversions API behandelt die Server- und Container-Seite.

Googles Offline-Lead-Importe können eine Bestell-ID – auch Transaktions-ID genannt – nutzen, um doppelte Uploads innerhalb der jeweiligen Conversion-Aktion zu vermeiden. Die bereichsspezifische Formular-Eingabe-ID kann diese Rolle übernehmen, wenn sie für diese Aktion eindeutig bleibt und bei wiederholten Versuchen unverändert bleibt.

Welche Lead-Events sollten in die Gebote bei Google und Meta einfließen?

Die Backend-Übermittlung verringert deine Abhängigkeit von Browser-JavaScript und davon, dass die Seite geöffnet bleibt. Sie macht das Lead selbst nicht wertvoller, und Fehler bei Webhooks oder Zielseiten erfordern weiterhin Wiederholungsversuche und Überwachung. Ein wertloses Lead zuverlässig zu übermitteln, bedeutet immer noch, ein wertloses Lead zu übermitteln.

Wenn jede gespeicherte Einreichung zu einer primären Conversion-Aktion wird, die für das Bidding herangezogen wird, kann Google Smart Bidding die Kampagne auf dieses Event hin optimieren. Meta Advantage+ Leads-Kampagnen können CRM-Ergebnisse nutzen, die über die Conversions-API gesendet werden, um die Kampagne auf Leads zu optimieren, bei denen die Wahrscheinlichkeit einer Conversion höher ist. Wenn man einem der beiden Systeme Spam oder Kontakte mit geringer Kaufabsicht zuführt, erhält es schwache Eingabedaten statt der qualifizierten Ergebnisse, die das Unternehmen eigentlich anstrebt.

In der Praxis sieht die sinnvolle Aufteilung so aus:

• generate_lead für einen gültigen Formulareintrag, wird oft als Analyse-Event oder sekundäre Konversion gespeichert
• „qualified_lead“, nachdem das CRM- oder Vertriebsteam den Lead angenommen hat
• converted_lead, wenn aus dem Lead ein Kunde wird, mit einem Wert, sofern das Unternehmen dies unterstützt

Es gibt keinen Grund, so zu tun, als wäre ein Kontaktformular schon Umsatz. Wenn man spätere CRM-Phasen an die Werbeplattformen zurückmeldet, erhalten deren Gebotssysteme ein genaueres Bild des Ergebnisses, das das Unternehmen anstrebt. Die aktuellen Leitlinien von Google empfehlen für Werbetreibende im Bereich Lead-Generierung, die „Erweiterte Conversions für Leads“ nutzen, Ziele für qualifizierte oder konvertierte Leads festzulegen.

Mehr darüber, wie du spätere Ergebnisse an Google Ads zurückmeldest, erfährst du in diesem Leitfaden zu Offline-Conversions. Für B2B-Kampagnen wird dasselbe Prinzip im Leitfaden zur LinkedIn Conversions API behandelt.

Speichere Klick-IDs im Lead-Datensatz, nicht im Browser

Lange Verkaufszyklen werden unterbrochen, wenn die Attributionsdaten nur im Browser verbleiben. Verfügbare Werbe-Klick-IDs können auf der Landingpage erfasst, in versteckten Formularfeldern abgelegt und zusammen mit der Formulareingabe gespeichert werden – vorbehaltlich der Einwilligungsentscheidungen des Besuchers und der Regeln der Plattform.

Versteckte Felder sind immer noch vom Besucher gesteuerte Eingaben, daher sollte alles, was darin eingeht, als nicht vertrauenswürdig behandelt werden. Überprüfe das erwartete Format und die Länge, akzeptiere nur Parameter, die du erkennst, und verwende diese Werte niemals zur Autorisierung oder Identitätsfeststellung. Speichere den Einwilligungsdatensatz separat und verknüpfe ihn mit der Übermittlung, die den Webhook ausgelöst hat.

Zu den gängigen Werten gehören:

• gclid für berechtigte Google Ads-Klicks
• fbclid aus Meta-Landing-URLs, während die Werte _fbc und _fbp von Meta üblicherweise für das CAPI-Matching verwendet werden
• li_fat_id, wenn das erweiterte Conversion-Tracking von LinkedIn aktiviert ist

Wenn du die Kennung beim Eintrag speicherst, kann sie ins CRM übernommen werden. Wenn ein Geschäft Wochen später qualifiziert wird, kann ein CRM-Webhook das Ergebnis mit der ursprünglichen Kennung senden, anstatt die aktuelle Browsersitzung zu bitten, sich an einen alten Besuch zu erinnern.

Google empfiehlt, GCLIDs weiterhin zu importieren, sofern verfügbar, um die Konversionen für Leads zu verbessern. LinkedIn akzeptiert „li_fat_id“ als First-Party-Tracking-Identifikator für Anzeigen zum Abgleich mit der Conversions API. Gehashtete First-Party-Kundendaten können berechtigten Plattformen ebenfalls dabei helfen, eine spätere Konversion abzugleichen, doch das Hashen hebt die Pflichten in Bezug auf Einwilligung, Benachrichtigung, Sicherheit oder Datenminimierung nicht auf.

Für einen praktischen CRM-Ablauf schau dir diese Erklärung an, wie Offline-Daten den ROAS von GA4 und Werbeplattformen korrigieren können.

Warum Safari die Nachverfolgung langer Lead-Zyklen erschwert

Eine Lücke von sieben Tagen lässt sich im B2B-Bereich, als Agentur oder in einer Branche, die hochwertige Dienstleistungen anbietet, leicht überbrücken. Beim ersten Besuch wird möglicherweise eine Browser-ID erstellt, während die Demo oder der unterzeichnete Vertrag erst einige Wochen später eintrifft. Deshalb gehört die Klick-ID in den Lead-Datensatz und nicht in ein Cookie.

Safari wendet nicht auf jedes First-Party-Cookie eine einheitliche Ablaufzeit von sieben Tagen an. Die Regel hängt davon ab, wie die Speicherung programmiert ist und ob Safari die Konfiguration als Tracking einstuft.

WebKit kann durch Skripte beschreibbaren Speicher nach sieben Tagen Safari-Nutzung ohne Benutzereingriff entfernen. Ein Tracking-Anbieter kann über eine benutzerdefinierte Subdomain so aussehen, als wäre er Teil der Website, während sein Server weiterhin auf der Infrastruktur eines Drittanbieters läuft. Safari kann solche Konfigurationen erkennen und auch einige vom Server gesetzte Cookies einschränken. Der Link-Tracking-Schutz kann zudem bekannte Klickparameter in geschützten Browsermodi entfernen.

Das Speichern von Klick-IDs im Lead-Datensatz kann einen Verknüpfungsschlüssel nach dem Absenden erhalten. Es stellt jedoch keine Kennung wieder her, die bereits vor dem Absenden des Formulars durch den Besucher verschwunden war, und garantiert auch nicht, dass eine Werbeplattform diese zuordnen kann.

Der verlinkte Bericht zum Tracking-Schutz in Safari 27 enthält weitere Erkenntnisse aus der Analyse des WebKit-Quellcodes durch TAGGRS. Apples öffentlich zugängliche Informationen zu Safari 27 bestätigen nicht alle diese versionsspezifischen Details, daher sollten sie eher als technische Analyse von TAGGRS und nicht als offizielle Ankündigung von Apple betrachtet werden. Die „Cookie Recovery“-Funktion von TAGGRS ist dokumentiert, um für Marketingzwecke zugelassene Cookies zu behandeln, für die eine Einwilligung vorliegt, und erfordert das „Enhanced Tracking Script“. Sie verknüpft keine Geräte, verlängert nicht das Attributionsfenster einer Werbeplattform und ersetzt auch nicht die Einwilligung.

Überlappende WordPress-Tracking-Plugins prüfen

Probleme beim Tracking in WordPress beginnen oft schon, bevor sGTM hinzugefügt wird. Site Kit, MonsterInsights, GTM4WP, das Meta-Plugin und ein Plugin zur Einwilligungsverwaltung können alle Skripte einbinden oder den Zeitpunkt der Tag-Ausführung verändern.

Es kann vorkommen, dass zwei Tools gleichzeitig GA4 laden. GTM und ein Meta-Plugin senden möglicherweise jeweils dasselbe Lead-Event. Ein CMP kann eine Kopie blockieren, während ein anderes Plugin ein Tag einfügt, das außerhalb seiner Kontrolle liegt. Der Browser sendet dann doppelte oder nicht genehmigte Events, bevor der Server-Container überhaupt etwas empfängt.

Ein sinnvolles Audit benennt den Verantwortlichen für jede Funktion: das Tool, das GTM einbindet, dasjenige, das GA4-Seitenaufrufe sendet, und die Komponente, die die Standardeinstellungen für die Einwilligung festlegt. Ein Verantwortlicher pro Funktion ist die übersichtlichste Konfiguration. GTM4WP kann weiterhin Datenlayer-Werte bereitstellen, während eine andere Methode die Analysedaten übermittelt – diese Aufteilung muss jedoch bewusst erfolgen.

Die Anleitung zum Consent Mode von Site Kit warnt davor, dass es zu Konflikten kommen kann, wenn der Consent Mode in Site Kit parallel zur Consent Mode-Funktion eines anderen Plugins aktiviert wird. Die gleiche allgemeine Regel gilt auch an anderer Stelle. Dass ein Plugin mit GTM kompatibel ist, bedeutet nicht, dass sein Standard-Tracking aktiviert bleiben sollte.

Plugin-Konflikte sind nur eine Möglichkeit, wie eine Konfiguration unbemerkt beeinträchtigt werden kann. Unser Leitfaden zur Robustheit deiner Tracking-Konfiguration erklärt dir den Rest.

Übertrage den Consent Mode v2 in den Server-Container

Complianz, CookieYes und Real Cookie Banner können die Einwilligungsoptionen von WordPress mit dem Google Consent Mode v2 verknüpfen. Die genauen Einstellungen und Anforderungen an den Tarif unterscheiden sich, daher solltest du die aktuelle Dokumentation des CMP als Teil der Implementierung heranziehen.

Consent Mode v2 umfasst „ad_storage“, „analytics_storage“, „ad_user_data“ und „ad_personalization“. Im von Google dokumentierten Tagging-Ablauf fügt der Web-Container Einwilligungsparameter hinzu, und der GA4-Client des Server-Containers wertet diese aus. Ein direkter WordPress-Webhook übernimmt diesen Status nicht automatisch. Er muss den für die Übermittlung erfassten Einwilligungsstatus enthalten, und jedes Server-Tag, das nicht von Google stammt, benötigt Regeln, die diesen Status vor dem Auslösen auswerten.

Das CMP bleibt die Quelle für die Entscheidung des Besuchers. sGTM ist kein Umgehungsmechanismus für die Einwilligung. Dieser Leitfaden zum Consent Mode v2 erklärt, wie die Signale einen Server-Container erreichen und wo Tags, die nicht von Google stammen, zusätzliche Bedingungen erfordern.

Leads, die nie über ein WordPress-Formular laufen

Das Formular ist nur ein Weg in ein Dienstleistungsunternehmen. Anrufe, WhatsApp-Chats, Calendly-Buchungen und Website-Chats können zu Leads werden, ohne dass ein Eintrag im WordPress-Formular entsteht.

Jede Quelle braucht ihr eigenes bestätigtes Erfolgsereignis. Eine Telefonplattform sendet vielleicht nach einem qualifizierten Anruf einen Webhook. Calendly kann ein Backend benachrichtigen, sobald eine Buchung erstellt wurde. Ein CRM wie HubSpot oder eine Chat-Plattform kann melden, wenn aus einer Unterhaltung ein Lead wird. Ein Klick auf einen Telefon- oder WhatsApp-Link zeigt lediglich die Absicht zur Kontaktaufnahme an und sollte daher nicht automatisch das gleiche Gewicht haben wie ein abgeschlossener Anruf oder ein qualifizierter Chat.

Innerhalb von sGTM können diese Ereignisse einem einheitlichen Namensschema folgen, auch wenn sie aus verschiedenen Systemen stammen. Die Nutzdaten enthalten die Quelle, die externe Datensatz-ID, den Zeitpunkt des Ereignisses, den Einwilligungsstatus und die verfügbaren Attributionskennungen. Eine externe Buchungs-ID oder Anruf-ID kann denselben Zweck der Dublettenbereinigung erfüllen wie eine WordPress-Formulareingabe-ID.

Wo TAGGRS ins Spiel kommt

TAGGRS hostet den server-side GTM-Container und stellt einen Daten-Client bereit, der Backend-Webhooks auf zugelassenen Pfaden empfangen kann. Bei einer WordPress-Lead-Konfiguration kann ein Plugin-Hook, der den erforderlichen Erfolgszustand bestätigt, das Event an diesen Endpunkt senden. Deine Container-Konfiguration ordnet es GA4, Google Ads, Meta oder einem anderen Ziel zu, und ein späterer CRM-Webhook kann den qualifizierten oder konvertierten Lead mithilfe der gespeicherten Klick-ID und desselben Lead-Schlüssels senden.

Der Webhook-Tester hilft dabei, eine synthetische Nutzlast zu überprüfen, bevor sie von Live-Tags empfangen wird. TAGGRS bietet außerdem eine sGTM-Vorlage zur Lead-Generierung und einen Leitfaden für Offline-Konversionen für spätere CRM-Ergebnisse.

Fazit: Entscheide, welcher Datensatz gezählt werden darf

Bevor die Implementierung freigegeben wird, muss eine Frage genau beantwortet werden: Welcher Backend-Datensatz belegt, dass ein akzeptierter Lead vorliegt? Die nächste Frage ist, welche spätere CRM-Phase die Werbebietungen leiten soll.

Wenn keine der beiden Antworten dokumentiert ist, ist das Tracking-Konzept noch nicht ausgereift. Ein Webhook kann sehr zuverlässig das falsche Event liefern.

Die Plugins, das CRM und die Formulare unterscheiden sich von Website zu Website, aber das Prinzip bleibt dasselbe: Ein Eintrag im Backend entscheidet darüber, ob ein Lead vorliegt, und in einer späteren Phase wird festgelegt, worauf die Werbung bietet.

Schreib dir diese beiden Antworten auf, der Rest ist nur noch Konfiguration – du kannst mit einem kostenlosen TAGGRS-Konto loslegen und dein erstes Lead-Event über das Backend senden.

FAQ zum server-side Lead-Tracking in WordPress