Jenseits von Offline Conversions: Google Ads B2B Tracking Deep-dive

Tracking ist nicht sexy. Es ist nicht das, was man sieht. Aber es ist die Grundlage von allem. Dies könnte der entscheidende Hebel bei der Gewinnung von Neukunden sein. Ohne sauberes Tracking optimiert Google ins Leere.

TL;DR: Smart Bidding lernt nur auf dem, was ankommt — hier 20 Hebel, mit denen mehr ClickIDs überleben, Deal-Events aus dem CRM zurückfließen und Müll-Conversions per order_id wieder aus Google Ads zurückrufen.

Was für eine Online-Marketing-Engine zählt, ist Effizienz. Dass das Verfahren am Ende wirtschaftlich aufgeht. Ein durchgetuntes Tracking ist ein Wettbewerbsvorteil gegenüber allen anderen.

Dieser Artikel geht deutlich weiter als „Offline-Conversions importieren“. Er nimmt den kompletten Zyklus auseinander — Capture, Delivery und Quality.

Das Setup, das ich voraussetze: Cookie-Banner, Server-Side- und Offline-Conversion-Tracking, Consent Mode V2. Darüber müssen wir nicht reden – das ist Pflicht.

Attributionsfenster auf Maximum setzen

Mechanizmus: Google Ads wertet nur Conversions innerhalb eines festen Zeitfensters nach dem Klick — wer das Fenster verlängert, gibt dem Bidding Zugriff auf ältere Events.

Der Effekt: Google Ads schaut weiter in die Vergangenheit und ordnet der Kampagne mehr Conversions zu.

Google Ads rechnet eine Conversion der Kampagne nur zu und benutzt sie fürs Bidding, wenn sie innerhalb eines bestimmten Zeitraums passiert ist. Ältere Events ignoriert es und benutzt sie nicht — auch dann nicht, wenn sie getrackt sind oder der Advertiser die ClickIDs hochlädt. 

Im B2B ist die Trägheit lang, Wochen bis Monate. D.h.: wenn ich heute einen Demo Request habe und 75 Tage später Offer Sent, dann ignoriert der Google-Algorithmus diese Events und weist sie der Kampagne nicht zu, wenn das Attributionsfenster nicht groß genug eingestellt ist.

Nur ist jede Conversion wertvoll, besonders im B2B mit hohem CLV. Deshalb ist die grundlegendste Einstellung, die Attributionsfenster der Conversions auf Maximum einzustellen:

• Click-through Window: 90 days
• Engaged-view Window: 30 days
• View-through Window: 30 days

Dadurch findet auch das Bidding qualitativere und besser passende Interessenten.

Auto-Tagging & Tracking Templates

Mechanizmus: Auto-Tagging aktivieren und ein UTM Tracking Template mit allen Parametern hinterlegen.

Der Effekt: Jede Kampagne hat Identifikatoren, und es werden mehr Conversions zugeordnet.

Tracking und Matching lassen sich auch verbessern, indem man bei jedem Klick und für jeden Besucher UTM-Parameter anhängt. In den GAD Account Settings kann man Auto-Tagging aktivieren und ein Tracking Template hinterlegen. 

Das bewährte Template:

Tracking template: {lpurl}

Final URL suffix: utm_source=google&utm_campaign={campaignid}&mgc={gclid}&mwb={wbraid}&mgb={gbraid}&utm_campaignname={_campaignname}&utm_adgroup={adgroupid}&utm_content={creative}&device={device}&utm_term={keyword}&matchtype={matchtype}&network={network}&placement={placement}

Gclid muss man im Tracking Template nicht definieren — Auto-Tagging fügt ihn automatisch hinzu. Zu mgc usw. komme ich gleich im Artikel.

Dieselben Templates lassen sich auch auf Kampagnen- oder Ad-Group-Ebene definieren. Aber Achtung! Nicht dieselben Parameter mit unterschiedlichen Werten — utm_medium=paid auf Account-Ebene und utm_medium=cpc auf Kampagnen-Ebene kollidieren in einer URL. Beim nutzen von verschiedenen utm_medium es auf Account-Level besser leer lassen.

Non-Relevante Leads auf separate Thankyou-Page umleiten

Mechanizmus: Relevante und non-relevante Leads werden direkt im Formular erkannt, basierend auf „Privat oder Unternehmen“ und dem Company Name. Non-relevante Leads landen auf einer Thankyou-Page ohne Conversion-Tracking.

Der Effekt: Weniger Trash-Leads, mehr relevante Leads.

Non-relevante Leads als Conversion zu zählen ist kontraproduktiv. Der Algo sucht danach genau solche User weiter, und die Delivery der Kampagne kippt insgesamt in die falsche Richtung.

Der sauberste Weg, schlechte Leads herauszufiltern und gar nicht erst an die Kampagne zurückzumelden, ist eine eigene Thankyou-Page ohne Tracking. Dort landen Anfragen, die geschäftlich überhaupt nicht relevant sind. Die Conversion wird nicht ausgelöst, und der Algorithmus läuft weiter in die richtige Richtung.

Plugins wie Gravity Forms erlauben es, die Thankyou-Page abhängig von der Antwort im Formular zu setzen. Die grundlegende Frage im B2B ist „Privat oder Unternehmen?“. Danach empfiehlt es sich, über den Firmennamen zu exkludieren. Für einen Tiefbauer sind zum Beispiel Architekten, Immobilien, Gasthaus oder Landschaftsbau auszuschließen.

Das Gegenstück im B2C- und D2C-Umfeld ist, Bestellungen mit winzigem Bestellwert gar nicht erst als Conversion zu triggern.

Conversion-Set mit mehreren Conversions

Mechanizmus: Akquise-Kampagnen auf mehrere Acquisition-Events steuern, nicht nur auf Demo Request und CRM-Offline-Conversions.

Der Effekt: Mehr Conversion-Events, bessere Optimierung und ein präziseres Targeting der Zielgruppe.

Offiziell empfiehlt Google Ads, ausschließlich auf das Zielevent zu optimieren. Viele erfahrene Marketer raten davon ab und empfehlen, weitere relevante Events aufzunehmen. Auch bei mir bringt das die besseren geschäftlichen Ergebnisse.

D.h. einen Conversion-Set mit mehreren Conversions anlegen: 

• Contact Form, 
• App Registration, 
• Engaged Trial, 
• Demo Request, 
• Demo Done, 
• Offer Sent, 
• New Customer.

Eine App Registration ist oft bereits ein SQL, aus dem sich easy ein Demo Call entwickelt. Dank dessen kriegt die Kampagne mehr Conversion-Events. Sie läuft nicht mehr blind, sondern hat genug Signale, um den richtigen Nutzer zu targeten.

Wichtig ist, dass alle Conversions akquisefähig sind und aus derselben Kategorie kommen. Ein Engagement-Event lässt sich nicht in dieses Set einsetzen. Contact-Form-Submits nur dann aufnehmen, wenn sie zu Demo Calls führen.

Offline-Conversions hängen stark an Menschen, weil sie nur in Demo Calls entstehen. In Urlaubszeiten gibt es davon deutlich weniger, und dann hilft es enorm, wenn sich die Kampagnen zusätzlich auf Web-Conversions stützen können. 

Es gibt weitere Wege, Web-Conversions voll relevant zu machen und halten. Mehr dazu in der Fortsetzung.

ClickID Rescue mit myClickID (mgc/mwb/mgb)

Mechanizmus: Adblocker und Tracking-Preventions löschen die ClickIDs der Werbesysteme. Im Tracking-Template lässt sich ein eigener Parameter für die ClickID definieren. Diese Parameter kennt die Tracking-Prevention nicht.

Der Effekt: Mehr ClickIDs überleben die Tracking-Prevention, und Google Ads schreibt der Kampagne mehr Conversions zu.

Viele Adblocker und Browser-Tracking-Preventions löschen die ClickIDs der Werbesysteme. Harmlose bzw. unbekannte Parameter bleiben stehen, ClickIDs und andere Werbeinformationen werden gelöscht. Einige Adblocker löschen den kompletten Query-String samt UTMs, da lässt sich nichts machen.

Meist greift aber nur der erste Fall, und dann lässt sich die ClickID retten, indem man einen neuen Parameter definiert, den die Tracking-Prevention nicht kennt.

Beispiel: 

Der Link enthält: gclid={gclid}&wbraid={wbraid}&gbraid={gbraid}

Und zusätzlich: mgc={gclid}&mwb={wbraid}&mgb={gbraid}

Die ClickID Strings sind identisch. Ein Adblocker löscht die erste, das Backup überlebt.

mgc rettet den Fall, in dem die ClickID gestrippt oder das Cookie geblockt wird. mwb und mgb retten den Fall, in dem Google gar keinen gclid gesetzt hat.

‘Mygclid’ wird praktisch nie gestrippt, weil ihn kein Browser kennt. D.h es überlebt URL-Cleaner in Browsern, Adblocker mit Query-Filter und gtag/Cookie-Blocking. Überlebt nur keinen kompletten Query-String-Strip.

Selbstverständlich: alle Listener müssen diese eigenen Parameter lesen und verarbeiten können, und zwar als Backup, wenn der Hauptparameter leer ist. Wer also ein Lead-Formular hat, das in die UTMs oder ins Cookie schaut, muss es auch hier hineinschauen lassen.

Einige Tracking-Provider wie Stape.io haben diesen Rescue bereits in ihre Prozesse eingebaut.

Klar, das ist eine kleine Verbesserung — geschätzt +5 %. Macht ein Advertiser fünf solcher Dinge, hat er +20% mehr Conversions. Das ist ein deutlicher Sprung mit Wirkung auf das gesamte Geschäft und seine Economics. Und es wirkt dauerhaft, über Jahre, auf jeden Euro Ad-Spend.

Stape Tracking – www.stape.io 

URL Parameters Forwarding

Mechanizmus: Ein cookieless Skript auf die Website verbauen, der die URL-Parameter auf jede weitere Unterseite mitnimmt — auch nach einem Refresh.

Der Effekt: Viele UTM- & URL-Parameter überleben bis zum Lead-Submit. Dort liest sie ein Listener aus und nutzt sie als Hidden Field Values fürs Tracking.

Wird das Cookie-Banner abgelehnt und werden Cookies blockiert, sinkt die Wahrscheinlichkeit eines Conversion-Matchings rapide. Hier hilft ein cookieless URL-Listener, der die URL-Parameter von der Landingpage auf jede weitere Subpage weitergibt.

Das Ergebnis? Die UTM- & URL-Parameter überleben deutlich länger — besonders auf Mobile. Und viele überleben bis zum Form-Submit.

Das Lead-Formular braucht einen zweiten Listener. Er liest die URL-Parameter nach dem Submit aus und schickt sie als Hidden Form Fields mit — zuerst aus der URL, Cookies nur als Backup. So kommen ClickIDs und Campaign-Infos in Google Ads, auch wenn keine Cookies existieren. 

Spezialfälle benötigen ein Löschen des Parameters. Beispiel: conversion_uid: die eindeutige ID jeder Web-Conversion. Die soll nur bis zur Thank-You-Page überleben — danach raus, sonst wird sie auf jede weitere Unterseite mitgeschleppt.

Cookie-based ClickID Capture

Mechanizmus: Ein cookie-based Listener, der nach der Cookie-Zustimmung die ClickID aus URL abfängt und in eine Cookie speichert.

Der Effekt: Noch besseres ClickID-Capture. Mehr attribuierte Conversions — und das Bidding bringt daraufhin zusätzliche Conversions.

URL Parameters Forwarding ist cookieless, aber URL- und UTM-Parameter sind fragil. Sie überleben nur die erste Session. B2B konvertiert aber nicht beim ersten Besuch. Zwischen Klick und Lead liegen eine Pause, ein Vergleichen, ein zweiter Besuch aus Organic, eine Mail vom Kollegen. In diesem Moment ist die URL leer. 

Deshalb: Akzeptiert der User Cookies, lässt sich ein besserer und noch langlebigerer Listener einbauen.

Beispiel:

Der User klickt am Montag auf eine Ad. Die gclid steht in der URL, der Listener speichert sie in einem Cookie. Am Donnerstag kommt der User direkt über Search zurück, drei Unterseiten, dann Checkout.

In der URL steht keine ClickID. Das Cookie hat sie aber — samt dem Zeitpunkt des ursprünglichen Klicks — und beim Form-Submit wird sie ausgelesen und mitgeschickt.

Der URL-Listener ist also One-Visit, Cookies sind Multi-Visit. UTM kennt nur die aktuelle Session, Cookies auch wiederkehrende Besuche.

Hinweis: Capture allein reicht nicht. Die Forms müssen diese Cookies als Fallback lesen können. 

Stape Power-Ups aktivieren

Mechanizmus: Stape Power-Ups aktivieren.

Der Effekt: Weniger blockierte Daten, mehr abgefangene ClickIDs, mehr gemessene Conversions.

Stape.io empfehle ich als Serverside- und Tracking-Provider. Sie haben außerdem Power-Ups, die sich einschalten lassen und das Tracking verbessern: 

• Custom Loader — lädt GTM/GA4-Scripts über deine eigene Domain, damit Ad-Blocker sie nicht blockieren.
• Cookie Keeper — verlängert Cookie-Lebensdauern, die Safari-ITP sonst verkürzt.
• Anonymizer — pseudonymisiert Daten, bevor sie in den sGTM-Container gehen.
• Click ID Restorer — stellt in Safari verlorene gclid/msclkid wieder her.
• User ID — generiert eine stabile User-ID aus IP, User-Agent und anderen Request-Parametern.
• Ad Blocker Info — flaggt per Header, ob der Besucher einen Ad-Blocker nutzt.
• Enricher — Automatische Speicherung und Wiederverwendung von Benutzerdaten aus eingehenden Requests.

Die aktiven Power-Ups sorgen zusammen dafür, dass dein Tracking trotz Ad-Blockern, Safari-ITP und Consent-Hürden möglichst vollständig und datenschutzkonform funktioniert.

Der Custom Loader zum Beispiel maskiert das Google-Tag-Manager-Skript — kaum zu detektieren, kaum zu blockieren. 

Der Anonymizer maskiert umgekehrt die Server-side-Daten über eine First-Party-Domain (z.B. venus.yourdomain.com).

Lead Forms Submit Listener

Mechanizmus: Auf den Form-Entry-Pages einen Universal Listener einbauen, der die Formularfelder und ClickIDs aus allen Quellen liest, eine conversion_uid generiert und den fertigen Payload in ein 5-Minuten-Cookie schreibt.

Der Effekt: Der GTM auf der Thank-You-Page hat alle Match-Signale — auch über Blocker und Redirect hinweg. Das Capture kann um zweistellige Prozentwerte steigen.

Bisher ging es um das Überleben der Identifier. Beim Submit geht es ums Auslesen. Dafür ist da ein Universal Listener — er schaut in alle möglichen Backups: UTM- & URL-Parameter, my*IDs, Google Cookies, Stape und eigene First-Party Cookies.

Seine wichtigste Aufgabe ist der ClickID-Fallback — eine dreistufige Priorität für gclid/wbraid/gbraid:

• Hidden Fields für die ClickIDs, per Dynamic Population aus der URL gefüllt — nie überschreiben!
• Wenn leer: in der URL nach ClickIDs und danach my*-ClickIDs schauen.
• Wenn die URL leer ist: Cookies lesen: GCL.{ts}.{val} + .k{val}$i{ts} + Stape Cookies + First-Party Cookies

Zugleich läuft mein Listener alle 300 ms, verarbeitet die Match-Felder des Formulars, generiert die conversion_uid und legt ein Cookie an, das nur die Thankyou-Page überlebt.

Die meisten Form-Plugins lesen nur die Daten aus den UTM-Parametern — also Single-Visit-Sessions. Das ClickID-Capture aus Cookies macht daraus Multi-Visit-Tracking.

API Upload von gclid / wbraid / gbraid

Mechanizmus: CRM-Events (Demo Done, Offer Sent, Won) mit der gecapturten ClickID per API als Offline-Conversions an Google Ads zurückspielen.

Der Effekt: Smart Bidding optimiert nicht mehr auf Formular-Submits, sondern lernt, welche Klicks zu Umsatz führen. +30–40 % mehr gematchte Conversions, nur durch wbraid/gbraid.

Die ganze Investition in Capture zahlt sich hier aus: Die ClickID wandert mit dem Lead ins CRM und wartet. Sobald ein Deal-Event eintritt, wird die Offline-Conversion mit exakt dieser ClickID per API an Google Ads gesendet.

(!) Der Fehler, den fast alle machen: Die meisten Advertiser senden nur den gclid — die meisten Tools arbeiten ja auch nur damit. Aber Google Ads matcht drei ClickID-Typen: gclid, wbraid und gbraid. Die braid-IDs entstehen dort, wo iOS/ITP den gclid killt; sie matchen Kohorten statt einzelner User, wbraid präziser als gbraid. 

Daher die Kaskade: gclid, sonst wbraid, sonst gbraid senden. Wer nur gclid sendet, verschenkt 30–40% seiner Offline-Conversions.

Google Ads API: https://developers.google.com/google-ads/api/docs/conversions/upload-clicks

Data Tags statt GAD Conversion Tags

Mechanizmus: Im Tag Manager Data Tags statt native Google Ads Conversion Tags. Der Browser sendet Conversion-Daten nicht mehr direkt an Google, sondern via Data Tag an den eigenen Server-Container — erst dort feuert die sConversion.

Der Effekt: Adblocker und Safari/ITP blockieren Third-Party-Requests an Google — die eigene Domain steht auf keiner Blockliste, Capture und Zustellung steigen.

Vordefinierte GAD Conversion Tags laufen im Browser und rufen googleadservices.com direkt auf — genau die Requests, die Tracking-Prevention, Adblocker und DNS-Filter als Erstes killen.

Ein Data Tag (Custom Event) dreht die Architektur um: Der Browser spricht ausschließlich mit der eigenen First-Party-Subdomain, für den Client sieht das wie normaler Website-Traffic aus. 

Der Server-Container übernimmt den Rest — Anreicherung mit gclid und Enhanced-Conversion-Daten, Consent-konforme Verarbeitung, dann die Übergabe an Google Ads per Server-zu-Server-Request, den keine Browser-Restriktion mehr erreichen kann.

Nebeneffekt: First-Party-Cookies, die der Server setzt, leben deutlich länger als browserseitig gesetzte (Safari cappt 7 Tage) — Klick-IDs bleiben also auch bei längeren B2B-Entscheidungszyklen attribuierbar.

Unterm Strich: ein messbar vollständigeres Conversion-Signal.

Enhanced Conversions mit 3-Tier-Fallback

Mechanizmus: First-Party-Daten werden beim Form-Submit gehasht an Google übergeben — Google matcht sie gegen eingeloggte Google-Accounts und attribuiert Conversion auch ohne Click-Cookie.

Der Effekt: Conversions, die durch ITP, Cookie-Block oder Cross-Device verloren gingen, werden rescued — Coverage +20–30%.

Normalerweise hängt jede Conversion am gclid-Cookie. Enhanced Conversions braucht keine ClickID. Es ergänzt die ClickID-Attribution: Ist der gclid da, matcht Google direkt — EC greift genau dann, wenn das Click-Cookie fehlt.

Email, Name und Phone werden gehasht an Google übergeben, Google matcht die Hashes gegen eingeloggte Google-Accounts und ordnet die Conversion dem ursprünglichen Ad-Klick zu — ohne ClickID.

Die technische Hürde ist der Form-Submit selbst: Er löst einen Redirect aus, die Form-Page stirbt, bevor ein Tag feuern könnte. Deshalb legt ein Listener die Match-Felder beim Submit bereits aufbereitet in ein First-Party-Cookie (5 Min TTL), das den Page-Refresh überlebt.

Signals Gateway: CAPI-Forwarder mit First-Party-Domain

Mechanizmus: Der Browser sendet Events an die eigene Subdomain statt an Google/Meta — ab dort läuft es server-side weiter, d.h. unsichtbar für jede Browser-Restriktion.

Der Effekt: Adblocker, ITP und DNS-Filter greifen nur im Browser — die eigene Domain steht auf keiner Blockliste, blockierte Conversions kommen trotzdem an.

Signals Gateway (von Stape) ist im Kern ein First-Party-Relay. Der Trick liegt im ersten Hop: Der Browser spricht nicht zu googleadservices.com — genau die Domains, die jeder Adblocker kennt — sondern zur eigenen Subdomain – z.B. www.mars.yourdomain.com.

Eine eigene Domain gilt als First-Party, nicht als Tracker, und steht auf keiner Blockliste. Nach diesem einen Hop ist der Browser raus: Alles Weitere läuft server-zu-server, und Server-Requests sieht kein Adblocker, kein ITP.

Eine Einschränkung: SGW ist primär für Meta und TikTok gebaut — dort hängt man die CAPI-Destination direkt hinten dran. Für Google Ads existiert keine fertige Destination; der Weg dorthin erfordert einen Custom Client und eigene Templates im Server-Container. Machbar, aber Eigenbau.

Fazit: Eine zweite, unabhängige Conversion-Pipeline, die den ~10% Adblock-Traffic zurückholt.

Deduplizierung durch conversion_uid

Mechanizmus: Bei jedem Form-Submit wird ein zufälliger String aus Ziffern und Buchstaben generiert, der die Web-Conversion eindeutig identifiziert und als order_id mitgesendet wird.

Der Effekt: Web-Conversions werden dedupliziert — auch wenn der User die Thank-you-Page neu lädt, refresht oder zwei Pipelines dieselbe Conversion melden.

„Count: One“ reicht oft nicht — es dedupliziert nur per Klick. Läuft eine Conversion ohne ClickID ein oder melden parallele Pipelines (Browser + Server-Side) dieselbe Conversion, zählt Google doppelt.

Die order_id löst das an der Wurzel: Jede Conversion mit bereits gesehener order_id wird verworfen — unabhängig von Klick, Pipeline oder Timing.

Technisch: Die UID wird beim Form Submit generiert, überlebt den Redirect via Cookie bzw. Query-String, landet als DataLayer-Variable im GTM und wird von dort an alle Conversion-Tags angehängt — Web Tags, Data Tags und Server-Side Tags lesen dieselbe Variable als order_id.

Der Bonus: Über die order_id lassen sich Non-Relevant-Conversions nachträglich aus Google Ads löschen.

Signal Recovery: App Registration Backfill

Mechanizmus: Ein Deep Link speichert die ClickIDs serverseitig, bevor der Website-Visitor in den App Store abbiegt — beim ersten App-Open matcht das SDK den Klick per Fingerprint und die Registrierung geht mit Original-ClickID als Offline-Conversion an Google Ads.

Der Effekt: In-App-Registrierungen, die für Google Ads bisher unsichtbar waren, werden rescued und attribuierbar. D.h. mehr Conversions für die B2B-Kampagnen.

Das Mess-Loch: Klickt ein User eine Ad, landet auf der Website und geht dann in den App Store, bricht die Attribution ab — gclid/wbraid/gbraid überleben den Übergang Website → Store → App nicht. 

Registriert er sich durch App Store, existiert die Conversion für Google Ads schlicht nicht. Das Bidding sieht nur die Web-Registrations.

Die Brücke: Der App-Store-Link wird durch einen Smart Link ersetzt, der die ClickIDs als Parameter mitnimmt und den Klick-Fingerprint (IP, User-Agent, OS, Timestamp) serverseitig speichert. Beim ersten App-Öffnen vergleicht das SDK den aktuellen Fingerprint mit gespeicherten Klicks — Match → die ClickIDs wandern in die App und mit der User-ID ins Backend.

Bei Account Created feuert ein Webhook, nach Qualitätscheck wird die Conversion mit der originalen ClickID per Offline-Upload an Google Ads gesendet.

Erwartungsmanagement: Android matcht via Install Referrer sehr zuverlässig (~85–95%), iOS bleibt probabilistisch (~40–70%) — Private Relay und Consent-Rejects drücken die Rate. Ist eine Recovery nur teilweise, aber ohne sie ist dieser Signalpfad komplett schwarz.

Tool: Branch – Deferred Deep Linking

Signal Recovery: Demo Done Backfill

Mechanizmus: Nach einer erfolgreichen Demo springt der Deal von Planned auf Offer Sent — Demo Done wird als Status übersprungen und fehlt in den Conversions. Der Backfill trägt die Offline-Conversion nach.

Der Effekt: Demo Done wird nicht mehr systematisch untergezählt — ausgerechnet die heißesten Leads fehlen sonst im Signal.

Demo Done feuerte häufiger bei kalten Leads, die jede Stufe langsam durchlaufen. Heiße Leads springen direkt von Demo Planned zu Offer Sent — Demo und Angebot im selben Call. Demo Done-Status wird nie gesetzt und die Conversion geht verloren. Das Signal verzerrt Richtung kalte Leads.

Ein Zap löst das: Jeder Status oberhalb von Demo Done triggert einen Check „je Demo Done gehabt?“ — nein → nachtriggern. In API-Upload Sheet die Conversion mit gespeicherter ClickID eintragen.

Ausnahme: Deals ist als Non-Relevant klassifiziert (setzt kein Demo voraus). Der Check verhindert zugleich Doppelfeuern.

Timestamp kommt von der auslösenden Stage — die Conversion-Time ist leicht nach hinten verschoben, ein Proxy statt eines erfundenen Werts.

Legit? Ja — es wird kein Event erfunden, sondern ein echtes wiederhergestellt. Der Lead hatte ein Demo. Der Backfill füllt eine Erfassungslücke.

ICP Fit-Only-Conversions, Non-Relevants nicht senden

Mechanizmus: Offline-Conversions werden nur gesendet, wenn Sales den Deal als Primary oder Secondary ICP einstuft. Non-Relevants werden nicht an Google übertragen. 

Der Effekt: Smart Bidding lernt ausschließlich auf qualifizierten Deals – sucht mehr davon und generiert mehr Neukunden.

Ein Non-Relevant-Deal als Offline-Conversion trainiert das Bidding aktiv auf die falschen Klicks. Deshalb sitzt vor dem API-Upload ein Qualitäts-Gate: Nur die Sales-Einstufung im CRM entscheidet, ob das Event überhaupt gesendet wird.

Winzige Änderung, massiver Impact.

Retract Bad Leads bei Web-Conversions

Mechanizmus: Stellt sich eine Web-Conversion nachträglich als Non-Relevant heraus, wird sie über ihre order_id per Retraction-Upload gezielt aus Google Ads zurückgezogen.

Der Effekt: Die Müll-Conversions werden aus Google Ads zurückgezogen. Smart Bidding optimiert nur noch auf relevante Leads. Das Ergebnis: mehr relevante Leads fürs gleiche Budget.

Bei Web-Conversions gibt es keinen Qualitäts-Check vor dem Senden — der Form-Submit feuert sofort, die Qualität des Leads zeigt sich erst danach. Anfragen von Privatpersonen, Test-Submits, Angebote: alles landet zunächst als Conversion in Google Ads und verlangt vom Bidding „mehr davon“.

Retraction dreht das nachträglich zurück. Jede Web-Conversion trägt ihre conversion_uid als order_id — genau darüber lässt sie sich per API gezielt widerrufen.

Technisch läuft meine Bewertung dreistufig – ai / sales / manuell:

Eine AI klassifiziert jeden Lead nach ICP-Fit und Confidence — bei sehr hoher Sicherheit (z.B. Non-Relevant ≥90%) wird der Rückzug automatisch geflaggt, bei niedrigerer Confidence nur als „propose“ vorgeschlagen und wartet auf menschliche Freigabe. 

Sales-Verdicts überschreiben die AI immer, manuelle Entscheidungen überschreiben beides. 

Weil der Rückzug irreversibel ist, sitzt davor ein Veto-Fenster: Jede Zeile erscheint mindestens einmal in einer Daily Digest-Email, bevor der Retract sie endgültig aus Google Ads entfernt.

Der komplette Prozess: Retract Bad Leads: Spam-Conversions aus Google Ads entfernen 

Google Ads API Conversion Adjustments (Typ RETRACTION): https://developers.google.com/google-ads/api/docs/conversions/upload-adjustments

ClickIDs durch den Stripe Payment Link schleusen

Mechanizmus: Beim Klick auf den Zahlungslink werden die ClickIDs in die URL geschrieben, reisen im Feld ‘client_reference_id’ durch den Stripe-Checkout und kommen per Webhook zurück.

Der Effekt: Eine Zahlung auf einer fremden Domain bleibt einer konkreten Anzeige zuordenbar, ohne eigenen Checkout und ohne Cookie im Kaufmoment.

Der Kaufweg beginnt auf der eigenen Seite. Ein Website-Besucher kommt über eine Anzeige, die ClickID hängt an der Landing-URL und wird dort ausgelesen.

Im Moment des Klicks wird der Button zum Zahlungslink buy.stripe.com umgeschrieben und die gepackten ClickIDs als client_reference_id angehängt. (Gilt auch für Rechts- und Mittelklick, sonst erwischt „Link in neuem Tab öffnen“ den unmarkierten Link.)

Der Browser navigiert also zu einer URL, die die IDs enthält. Stripe liest den Parameter, hängt ihn an die Checkout-Session und behält ihn über die gesamte Zahlung.

Die Länge in diesem Feld ist knapp: 200 Zeichen, nur Buchstaben, Ziffern, Bindestrich und Unterstrich. Ein echter gclid ist rund 90 Zeichen lang. 

Deshalb werden die IDs ohne Trennzeichen gepackt, jede mit Typ-Code, Zeitstempel und Längenangabe. Ist die Zahlung durch, meldet Stripe die Session an den Webhook zurück. Dort wird das Feld entpackt und jede ClickID beim Kunden gespeichert.

Beim Senden der Conversion geht die ClickID unverändert an Google. E-Mail, Name und Adresse gehen ausschließlich als SHA-256-Hash raus.

Payment Link Funnel: Visitor-ID statt ClickIDs im Zahlungslink

Mechanizmus: Die ClickIDs wandern beim Klick serverseitig in die eigene Datenbank. Im Zahlungslink reist nur noch ein kurzer Schlüssel mit. Matching und Conversion-Transmitting passiert serverseitig.

Der Effekt: Die Zahl der ClickIDs und Werbesysteme in Payment Links ist nicht mehr an das 200-Zeichen-Limit gebunden.

Das Packing oben löst den Google-Fall vollständig. Es stößt erst an seine Grenze, wenn eine zweite Plattform dazukommt: fbclid, msclkid, li_fat_id, jede rund 90 Zeichen. Entropie lässt sich nicht komprimieren. Dieses Upgrade nimmt die IDs deshalb ganz aus dem Link heraus.

Beim Klick schickt der Browser den gesamten Satz an den eigenen Server (bzw. Datenbank). Ein Website-Besucher ergibt genau einen Datensatz, adressiert über eine eigene Visitor-ID im First-Party-Cookie. Klickt jemand fünfmal, entsteht kein fünfter Datensatz, es wird pro ID-Typ nur der neuere Wert überschrieben.

Für die Zuordnung gibt es zwei sichere Wege. Im Regelfall meldet der Webhook den Schlüssel zurück. Geht der Parameter unterwegs verloren, greift die Erfolgsseite: Stripe leitet auf die eigene Domain zurück, die URL trägt die Session-ID, der Browser die Visitor-ID.

Erst wenn beides fehlt, kommt ein Zeitfenster von wenigen Minuten ins Spiel, und nur, wenn dort genau ein Kandidat liegt. Zwei Kandidaten bedeuten keinen Versand. Eine fehlende Conversion ist besser als eine falsch zugeordnete.

Gesendet wird pro Kunde und Ereignis genau einmal, gesichert über ein Flag in der Datenbank. Ab dann speist ein Datensatz alle Ziele: je Werbesystem die passende ID, dazu dieselben gehashten Kundendaten.