Ein abgeschicktes Formular ist kein Geschäftsergebnis. Die Messung wird erst brauchbar, wenn der Vertrieb zurückmeldet, was aus dem Kontakt geworden ist — und wenn beide Seiten etwas davon haben.
Die meisten B2B-Messkonzepte enden bei der Danke-Seite. Danach übernimmt der Vertrieb, und die Spur reißt ab. Das Ergebnis kennt jeder: Marketing berichtet 40 Anfragen, der Vertrieb sagt, davon war eine brauchbar, und niemand kann zeigen, aus welchem Kanal diese eine kam.
Dieser Leitfaden schließt die Kette. Er hat drei Teile für drei Rollen: einen kurzen für den Vertrieb, dessen Rückmeldung das Ganze trägt, einen für die Umsetzung, und einen für die Berichte. Wenn Sie den Vertrieb führen, genügt Ihnen der Abschnitt Was der Vertrieb tut — und was er zurückbekommt; er ist bewusst so geschrieben, dass er einzeln weitergeleitet werden kann.
Auf einen Blick
- Der Vertrieb pflegt zwei Felder — rund vier Stunden je Quartal fürs ganze Team, inklusive der Kontakte ohne Formular — und bekommt dafür monatlich zu sehen, welcher Kanal ihm Arbeit macht.
- Gemessen wird der bestätigte Formularerfolg, nicht der Klick auf „Senden“.
- Eine technische Kennung verbindet Website und Kundenmanagement, ohne personenbezogene Daten in Analytics.
- Zwei Fristen entscheiden über den technischen Weg: 72 Stunden Rückdatierung und 90 Tage Rückblickfenster. Beide sind kürzer als ein B2B-Zyklus.
- Die Einwilligungslücke gehört sichtbar in jeden Bericht, nicht in eine Fußnote.
Vier Fragen, die die Messung beantworten soll
Bevor ein einziges Ereignis eingerichtet wird, schreiben Sie diese vier Fragen auf. Sie sind der Prüfstein für jede spätere Entscheidung: Was das Konzept nicht beantwortet, muss auch nicht gemessen werden.
- Aus welchem Kanal kommen die Anfragen, die der Vertrieb als brauchbar bewertet?
- Welche Seiten und Formulare erzeugen brauchbare Anfragen — und welche erzeugen nur Arbeit?
- Wie viele Anfragen werden zu Verkaufschancen, und wie viele davon zu Aufträgen?
- Was kostet uns eine brauchbare Anfrage je Kanal? (Der Weg dorthin steht unter Der Weg, der die Kostenfrage beantwortet.)
Und eine Frage, die Analytics im B2B nicht beantworten kann: welcher Kontaktpunkt den Auftrag verursacht hat. Bei sechs Monaten Vertriebszyklus, drei beteiligten Personen im Kundenunternehmen und einem Anteil an Kontakten, die jede Messung ablehnen, ist jede Ursachenzuschreibung eine Schätzung. Wer das vorher sagt, muss es später nicht verteidigen.
Was der Vertrieb tut — und was er zurückbekommt
Dieser Abschnitt richtet sich an die Vertriebsleitung. Ohne die Rückmeldung aus dem Vertrieb ist alles Weitere sinnlos, deshalb steht er vor der Technik und nicht dahinter.
Zwei Felder, nicht fünf
Am Datensatz im Kundenmanagement hängen fünf Felder. Drei davon füllt die Technik automatisch — Kennung, Erstquelle, Datum der Anfrage. Sie sind da, bevor jemand den Datensatz öffnet.
Zwei Felder füllt der Vertrieb: die Stufe (bearbeitet, qualifiziert, abgelehnt, Auftrag, verloren) und — im Ablehnungsfall — den Grund aus einer Auswahlliste. Beides sind Klicks in ein Auswahlfeld, kein Freitext.
| Wer | Wann | Was | Aufwand |
|---|---|---|---|
| Innendienst | direkt nach dem Erstkontakt | Stufe auf „bearbeitet“ | 2 Klicks, unter 5 Sekunden |
| Innendienst oder Außendienst | nach dem Erstgespräch | Stufe auf „qualifiziert“ oder „abgelehnt“ plus Grund | 3 Klicks, unter 10 Sekunden |
| Außendienst | bei Auftrag oder Absage | Stufe auf „Auftrag“ oder „verloren“ | 2 Klicks, unter 5 Sekunden |
| Innendienst | bei Kontakt ohne Formular (Telefon, Messe, Empfehlung) | Datensatz anlegen und Erstquelle setzen | rund 2 Minuten |
Rechnen Sie ehrlich mit beiden Anteilen. Bei 180 Formularanfragen im Quartal sind die Statusklicks rund 60 Minuten für das gesamte Team. Kommen 90 Kontakte ohne Formular dazu, die erst angelegt werden müssen, sind es weitere drei Stunden. Zusammen also rund vier Stunden je Quartal, verteilt auf drei Monate und mehrere Personen. Nennen Sie die Gesamtzahl in der Vertriebsrunde und nicht die schönere — die Lücke fällt sonst dem Ersten auf, der nachrechnet, und dann steht die ganze Vereinbarung in Frage.
Was der Vertrieb dafür bekommt
Eine Rückmeldung, die nur in eine Richtung läuft, versandet in sechs Wochen. Deshalb gehört die Gegenleistung schriftlich in dieselbe Vereinbarung.
- Monatlich eine Seite an den Vertrieb: welcher Kanal wie viele unbrauchbare Anfragen erzeugt hat, mit welchem Grund — und was daraufhin geändert oder abgestellt wurde. Ohne den zweiten Teil ist es nur eine weitere Auswertung.
- Weniger Müll im Postfach. Das ist der eigentliche Zweck. Wenn eine Anzeigengruppe seit zwei Monaten Bewerbungen liefert, sieht man das erst, wenn der Grund erfasst wird — und dann kann man sie abschalten.
- Die Pflegequote als eigenes Frühwarnsignal — und zwar zuerst beim Vertrieb. Eine Zeile „Anteil Datensätze mit gepflegter Stufe und Grund“ gehört in den Vertriebsbericht, nicht nur in den Betriebsbericht. Liegt sie unter etwa achtzig Prozent, ist die Auswertung nicht belastbar — und das soll die Vertriebsleitung als Erste sehen und selbst nachsteuern können, statt es später vom Marketing gesagt zu bekommen.
- Eine Abschaltklausel. Wenn nach einem Quartal keine Änderung aus den Daten gefolgt ist, wird die Pflege wieder eingestellt. Das nimmt dem Team die Sorge vor „noch ein Feld für immer“ und setzt das Marketing unter denselben Nachweisdruck wie den Vertrieb.
Die Ablehnungsgründe kommen aus dem Vertrieb
Eine Liste, in der das Team seinen häufigsten Fall nicht findet, produziert Zufallsklicks — und damit eine Auswertung, die schlechter ist als keine. Setzen Sie sich deshalb mit dem Innendienst hin und leiten Sie die Liste aus den letzten fünfzig Anfragen ab. Diese sieben Werte decken in unserer Erfahrung den größten Teil ab und sind ein Vorschlag, kein Katalog:
- Kein Bedarf — Thema passt nicht
- Wiedervorlage — grundsätzlich passend, aber erst in einigen Monaten
- Kein Entscheider erreichbar
- Budget passt nicht
- Falscher Markt — Region, Branche oder Unternehmensgröße außerhalb
- Bewerbung
- Werbung und Anbieteranfragen
Mehr als sieben pflegt niemand zuverlässig. Wenn eine achte Kategorie unbedingt gebraucht wird, streichen Sie dafür eine andere.
Zwei Auswahlfelder sterben in jedem Kundenmanagement aus demselben Grund: Sie liegen auf dem dritten Reiter und sind kein Pflichtfeld. Beide gehören in die Standardmaske, sichtbar ohne Klick, und die Stufe wird beim Speichern erzwungen. Die Einführung selbst kostet einmal fünfzehn Minuten in der Vertriebsrunde — mehr braucht es nicht, wenn die Felder dort liegen, wo ohnehin gearbeitet wird.
„Wiedervorlage“ ist eine Sonderrolle und braucht eine eigene Behandlung. Ein erheblicher Teil der heute abgelehnten Anfragen wird in sechs bis achtzehn Monaten wieder relevant. Wenn diese Fälle dauerhaft als „abgelehnt“ wegsortiert werden, entsteht genau das schiefe Bild, das die Messung verhindern soll. Zwei Regeln: Der Datensatz behält seine Kennung und seine Erstquelle. Und wird er später doch qualifiziert, wird die Stufe fortgeschrieben, statt einen neuen Datensatz anzulegen — sonst verliert der Auftrag den Kanal, aus dem er ursprünglich kam.
Was die Zahlen auch über den Vertrieb sagen
Eine Offenheit vorweg, die besser vorher ausgesprochen wird: Der Trichter, der monatlich an die Geschäftsführung geht, speist sich aus diesen Eingaben — und er sagt damit auch etwas über den Vertrieb aus. Wenn dort steht, dass von 180 Anfragen 96 bearbeitet wurden, ist das zunächst eine Zahl über die Bearbeitung und nicht über den Kanal. Deshalb gehört in denselben Bericht, wie viele der übrigen schon an der Anfrage erkennbar unbrauchbar waren. Ohne diesen Zusammenhang wird die Bearbeitungsquote falsch gelesen — und wer die Daten liefert, steht schlechter da als der, der sie auswertet.
Anfragen ohne Formular gehören dazu
Im B2B kommt oft die Hälfte der guten Kontakte per Telefon, über die Messe oder auf Empfehlung. Wenn nur Formularanfragen gepflegt werden, entsteht ein Bild, in dem die Kanäle gut aussehen, die Formulare erzeugen — und die besten Quellen unsichtbar bleiben. Das ist schlechter als keine Messung, weil daraus falsche Budgetentscheidungen folgen.
Diese Kontakte bekommen deshalb ebenfalls einen Datensatz, dieselben zwei Felder und im Feld Erstquelle einen manuell gesetzten Wert: Telefon, Messe mit Name, Empfehlung, Bestandskunde. Sie tauchen dann in derselben Auswertung auf wie die Website-Kontakte, nur ohne Analytics-Bezug. Genau deshalb liegt die vollständige Auswertung im Kundenmanagement und nicht in Analytics.
Die Lead-Stufen: erst der Prozess, dann die Technik
Google Analytics 4 kennt sechs empfohlene Ereignisse für Leadgenerierung. Sie sind eine gemeinsame Sprache und kein Vorgehensmodell — sinnvoll sind sie nur, wenn hinter jedem Namen die Definition steht, auf die sich Marketing und Vertrieb geeinigt haben.
| Ereignis | Bedeutet | Ausgelöst von | Aufwand im Vertrieb |
|---|---|---|---|
generate_lead | Kontakt hat Daten hinterlassen | Website | keiner |
working_lead | Erstkontakt erfolgt | Kundenmanagement | 2 Klicks |
qualify_lead | Erfüllt die vereinbarten Kriterien | Kundenmanagement | 2 Klicks |
disqualify_lead | Erfüllt sie nicht, mit Grund | Kundenmanagement | 3 Klicks |
close_convert_lead | Auftrag erteilt | Kundenmanagement | 2 Klicks |
close_unconvert_lead | Verloren | Kundenmanagement | 2 Klicks |
disqualify_lead ist die Stufe, die am häufigsten weggelassen wird und am meisten erklärt. Ohne sie sieht ein Kanal, der viele unbrauchbare Anfragen liefert, genauso gut aus wie einer, der wenige gute liefert — und das Marketing optimiert monatelang in die falsche Richtung, während der Vertrieb Bewerbungen zurückruft.
Nicht jedes Unternehmen braucht alle sechs Stufen. Drei sauber gepflegte sind mehr wert als sechs, von denen vier leer bleiben. Streichen Sie im Zweifel working_lead und close_unconvert_lead.
Zu diesen Ereignissen empfiehlt Google die Parameter value und currency — und zwar gemeinsam: Ein Wert ohne Währungsangabe wird ignoriert. Wenn Sie später wertbasiert steuern wollen, hinterlegen Sie je form_type einen festen Schätzwert und senden Sie ihn von Anfang an mit. Nachträglich lässt sich das nicht ergänzen.
Zwei Weichenstellungen vor dem ersten Tag
Zwei Entscheidungen bestimmen, wie alles Weitere gebaut wird. Sie gehören an den Anfang, weil sie sich später nur mit Umbau korrigieren lassen.
Erstens: Basis- oder erweiterter Einwilligungsmodus
Das ist im DACH-Raum die Entscheidung, die Ihr Datenschutzbeauftragter in der ersten Minute stellen wird.
| Basismodus | Erweiterter Modus | |
|---|---|---|
| Vor der Einwilligung | es wird nichts gesendet, die Tags laden nicht | die Tags laden und senden cookielose Signale |
| Modellierung fehlender Daten | nicht möglich | möglich, wenn die Schwellenwerte erreicht sind |
| Datenschutzliche Bewertung | unkritisch | wird von manchen Aufsichten und Beauftragten abgelehnt |
| Geeignet für | kleinere Websites, strenge interne Vorgaben | höhere Zugriffszahlen, wenn die Bewertung positiv ausfällt |
Die Modellierung hat harte Schwellenwerte, und die meisten B2B-Websites erreichen sie nicht. Verlangt werden mindestens 1.000 Ereignisse je Tag mit abgelehnter Speicherung über mindestens sieben Tage und mindestens 1.000 tägliche Nutzer mit Einwilligung an sieben der letzten 28 Tage. Wenn Ihre Zahlen darunter liegen, bekommen Sie keine Modellierung — unabhängig davon, wie sorgfältig Sie den erweiterten Modus einrichten. Prüfen Sie das, bevor Sie ihn mit dem Argument Modellierung begründen.
Unabhängig von der Wahl gilt: Für alles, was Richtung Werbeplattformen geht, sind die Einwilligungssignale zur Nutzung von Nutzerdaten und zur Personalisierung seit 2024 verpflichtend. Wer sie nicht setzt, verliert Zielgruppen und Messwerte in den Werbekonten.
Zweitens: Export nach BigQuery sofort verknüpfen
Der Export ist nicht rückwirkend. Er beginnt am Tag der Verknüpfung. Alles, was vorher passiert ist, liegt nie in BigQuery. Das ist der teuerste stille Fehler in diesem ganzen Themenfeld, weil er erst ein Jahr später auffällt.
Richten Sie die Verknüpfung deshalb am ersten Tag ein, auch wenn niemand die Daten zunächst auswertet. Drei Dinge dazu, die in Werbetexten fehlen: Für Standard-Properties liegt die Grenze bei etwa einer Million Ereignisse je Tag — wird sie überschritten, setzt der Export aus. Der laufende Export in Echtzeit wird gesondert berechnet, Speicher und Abfragen in BigQuery ebenfalls jenseits des Gratiskontingents; für B2B-Zugriffszahlen bleibt das meist im niedrigen einstelligen Bereich pro Monat, aber „kostenlos“ ist es nicht. Und: modellierte Daten stehen nicht im Export. In BigQuery liegen nur die Treffer mit Einwilligung. Die Zahlen in der Oberfläche und im Export weichen deshalb voneinander ab, und das ist kein Fehler.
Das Messkonzept: ein Dokument, das der Technik vorausgeht
Bevor jemand den Tag Manager öffnet, entsteht diese Tabelle. Sie ist gleichzeitig die Abnahmegrundlage und das, was Sie beim Personal- oder Anbieterwechsel in der Hand haben.
| Spalte | Inhalt | Beispiel |
|---|---|---|
| Ereignis | Name nach GA4-Empfehlung | generate_lead |
| Auslöser | das technische Signal, wörtlich | Erfolgsmeldung des Formularsystems in der Datenschicht |
| System | wer sendet | Website über Tag Manager |
| Parameter | alle, mit erlaubten Werten | form_type, service_interest, lead_id, value, currency |
| Als Dimension registriert | ja/nein — und warum nicht | lead_id: nein, zu viele verschiedene Werte |
| Schlüsselereignis | ja/nein | ja |
| Verantwortlich | Name, nicht Abteilung | J. Rehm |
| Getestet am | Datum und Testfall-Nummer | 14.03. / T-03 |
Parameter: kontrollierte Werte statt Freitext
Ein Parameter mit freiem Text ist nach drei Monaten unbrauchbar, weil dieselbe Sache in vierzehn Schreibweisen vorliegt. Legen Sie zu jedem Parameter die erlaubten Werte fest und lassen Sie nichts anderes zu.
| Parameter | Zweck | Erlaubte Werte | Als Dimension? |
|---|---|---|---|
form_type | trennt die Anfragearten | projektanfrage, quick_check, newsletter, bewerbung, rueckruf | ja |
service_interest | welche Leistung gemeint ist | fester Katalog, identisch mit der Navigation | ja |
lead_id | verbindet Website und Kundenmanagement | zufällige Kennung, nicht sprechend | nein |
lead_source_detail | Herkunft, wo die Kanalzuordnung nicht reicht | messe_hannover, katalog_qr, empfehlung | ja |
disqualify_reason | warum abgelehnt | kein_bedarf, wiedervorlage, kein_entscheider, budget, falscher_markt, bewerbung, werbung | ja |
Warum lead_id keine Dimension werden darf: Eine eindeutige Kennung je Anfrage erzeugt so viele verschiedene Werte, dass Analytics sie in den Berichten zu einer Sammelzeile zusammenfasst. Die Dimension ist dann nicht nur nutzlos, sie beeinträchtigt auch die Berichte, in denen sie vorkommt. lead_id wird als Parameter mitgesendet und ausschließlich im BigQuery-Export ausgewertet. Das ist der Unterschied zwischen einem Parameter und einer Dimension, und er wird regelmäßig übersehen.
Planen Sie mit den Grenzen. Je Ereignis sind 25 Parameter möglich; Parameternamen dürfen 40 Zeichen lang sein, Werte 100. Je Property gibt es 50 ereignisbezogene und 25 nutzerbezogene benutzerdefinierte Dimensionen, 50 benutzerdefinierte Messwerte, 30 Schlüsselereignisse und 500 unterschiedliche Ereignisnamen. Deshalb: nicht je Formular ein eigenes Ereignis, sondern ein Ereignis mit dem Parameter form_type.
Personenbezogene Daten fernhalten — und den häufigsten Fehler abstellen
Name, E-Mail-Adresse, Telefonnummer, Firmenname und Freitextfelder gehören nicht in Analytics. Das ist zugleich Nutzungsbedingung und datenschutzrechtliche Anforderung. Der häufigste Verstoß passiert unabsichtlich: Die Danke-Seite trägt die eingegebenen Werte in der Adresszeile, und die Adresse landet als Seitenpfad in der Auswertung.
Dagegen gibt es drei Maßnahmen, die zusammen wirken:
- Ursache abstellen: Das Formular sendet per POST oder leitet auf eine Danke-Seite ohne Parameter weiter. Alles andere ist Symptombehandlung.
- Im Datenstream schwärzen: Analytics kann E-Mail-Adressen und benannte Abfrageparameter aus Ereignisparametern einschließlich der Seitenadresse entfernen, bevor gesendet wird. Zusätzlich lassen sich Abfrageparameter im Datenstream generell ausschließen.
- Im Tag Manager bereinigen: eine eigene Variable, die die Seitenadresse ohne Abfrageteil zurückgibt und überall statt der Standardvariable verwendet wird.
Wichtig: Keine dieser Maßnahmen repariert bereits erfasste Daten. Für Vergangenes gibt es nur die Datenlöschung, und die greift begrenzt und nur innerhalb der Aufbewahrungsdauer. Wer eine Beanstandung hatte, stellt die Ursache ab und beantragt die Löschung.
Den Erfolg messen, nicht den Klick
Ein Auslöser auf den Klick des Absende-Buttons zählt auch dann, wenn die Pflichtfeldprüfung anschlägt, der Spamschutz blockt oder der Versand scheitert. Solche Zählungen liegen regelmäßig deutlich über den tatsächlich eingegangenen Anfragen — und die Abweichung fällt erst auf, wenn jemand die Zahlen mit dem Postfach vergleicht.
Richtig ist ein Auslöser auf die Erfolgsmeldung des Formularsystems. Die gängigen Formularerweiterungen melden den bestätigten Versand als eigenes Signal, das sich im Tag Manager abgreifen lässt; wo das nicht vorgesehen ist, schreibt die Entwicklung im Erfolgsfall einen Eintrag in die Datenschicht. Eine eigene Danke-Seite je Formularart ist die einfachste Variante und hat einen Nebennutzen: Sie ist auch ohne Tag Manager auswertbar.
Der Abgleich, der die Frage endgültig klärt: Zählen Sie einen Monat lang die tatsächlich eingegangenen Anfragen im Postfach oder Kundenmanagement und stellen Sie die Zahl neben die Ereignisse in Analytics. Eine Abweichung nach oben bedeutet, dass Sie Klicks statt Erfolge messen. Eine Abweichung nach unten ist normal und erklärt sich durch abgelehnte Einwilligungen, Werbeblocker und Kontakte, die direkt anrufen. Dieser Abgleich gehört einmal im Quartal wiederholt.
Die Kennung, die beide Welten verbindet
Damit eine spätere Qualifizierung dem ursprünglichen Kanal zugeordnet werden kann, brauchen Website und Kundenmanagement einen gemeinsamen Schlüssel. Rechnen Sie mit ein bis zwei Personentagen: verstecktes Feld im Formularsystem, Feldanlage im Kundenmanagement samt Berechtigungen, Variablen im Tag Manager, Testlauf mit abgelehnter Einwilligung, Freigabe durch den Datenschutz.
- Eigene Kennung. Beim Absenden erzeugt die Website eine zufällige Kennung und schreibt sie in ein verstecktes Feld. Sie geht als
lead_idan Analytics und als Feld ins Kundenmanagement. Das ist der verlässlichste Schlüssel, weil Sie ihn selbst kontrollieren. - Analytics-Client-Kennung. Lesen Sie sie über die Abfragefunktion des Tags aus, nicht direkt aus dem Cookie: Der Cookie-Wert enthält einen Versionsteil, und wer ihn ungefiltert speichert, kann später nicht auf das Gegenstück im BigQuery-Export verbinden.
- Kampagnenangaben und Werbeklick-Kennungen der Sitzung ebenfalls in versteckte Felder — dazu gleich mehr, sie sind der Schlüssel zur Kostenrechnung.
Erwarten Sie von der Client-Kennung keine Wiedererkennung über Monate. Sie steht in einem Erstanbieter-Cookie, das per Skript gesetzt wird; Safari begrenzt solche Cookies auf sieben Tage. Anderes Gerät, anderer Browser, gelöschte Cookies, Werbeblocker: jedes Mal eine neue Kennung. Und bei abgelehnter Einwilligung existiert sie gar nicht, das versteckte Feld bleibt leer. Die Client-Kennung dokumentiert also den Zustand beim Absenden — sie ist kein dauerhafter Personenschlüssel. Für die Verbindung über Monate taugt allein Ihre eigene Kennung im Kundenmanagement.
Und zur Einordnung, bevor jemand daraus die falsche Schlussfolgerung zieht: Eine zufällige Kennung, die Sie im eigenen System einer Person zuordnen können, ist pseudonym und nicht anonym. Sie bleibt ein personenbezogenes Datum, die Verarbeitung bleibt einwilligungspflichtig, und sie gehört ins Verarbeitungsverzeichnis. Der Zweck der Kennung ist, dass keine Klardaten an Analytics gehen — nicht, dass die Datenschutzfrage erledigt wäre.
Die Rückführung: warum der naheliegende Weg meist ausscheidet
Hier machen die meisten Anleitungen einen Fehler. Sie empfehlen, den Statuswechsel im Kundenmanagement per Measurement Protocol als Ereignis an Analytics zu senden. Das funktioniert technisch — aber drei Grenzen stehen dagegen, und alle drei sind kürzer als ein B2B-Vertriebszyklus.
- 72 Stunden Rückdatierung. Weiter zurück nimmt das Measurement Protocol keinen Zeitstempel an. Für eine korrekte Zuordnung nennt Google zusätzlich ein Fenster von 48 Stunden nach dem ursprünglichen Ereignis.
- Neue Sitzung ohne Sitzungskennung. Ein Ereignis, das ohne passende Sitzungskennung zur Client-Kennung ankommt, eröffnet eine neue Sitzung und landet in der Quelle „direct“ — auch nach zwei Stunden. Das ist der Grund, warum schon der Erstkontakt bei vielen falsch zugeordnet ist, nicht erst der Auftrag.
- 90 Tage Rückblickfenster. Das ist die härteste Grenze und die, die am seltensten genannt wird: Für Schlüsselereignisse lässt sich das Rückblickfenster auf 30, 60 oder 90 Tage stellen, mehr nicht. Bei vier bis neun Monaten Zyklus ist der Auftrag also selbst dann ohne Kanalbezug, wenn Sie die beiden anderen Probleme lösen.
| Weg | Geeignet für | Aufwand | Grenze |
|---|---|---|---|
| Measurement Protocol | Stufen binnen 48 Stunden — etwa working_lead bei schneller Erstreaktion | gering, wenn das Kundenmanagement Automatisierungen kennt | 72 Stunden; Sitzungskennung zwingend mitsenden |
| Datenimport, Nutzerdaten | Anreicherung vorhandener Nutzer um Merkmale | mittel | braucht eine eigene Nutzer-Kennung, die es ohne Anmeldebereich nicht gibt |
| Datenimport, Ereignisse als Datei | Nachtrag von Stufen in Dateiform | mittel | im Kern derselbe Weg wie das Measurement Protocol und mit derselben 72-Stunden-Grenze |
| Export nach BigQuery und Zusammenführung | der Regelfall im B2B | höher im Aufbau, danach gering | braucht jemanden, der Abfragen schreibt |
| Offline-Conversion-Import in die Werbekonten | Steuerung von Anzeigen auf qualifizierte Anfragen | mittel | Klickfenster maximal 90 Tage |
Der Regelfall sieht deshalb so aus: Analytics misst, was auf der Website passiert, bis generate_lead. Das Kundenmanagement führt die späteren Stufen. Der Abgleich passiert außerhalb von Analytics, über die Kennung, in BigQuery oder in einem Auswertungswerkzeug.
Der Weg, der die Kostenfrage beantwortet
„Kosten je qualifizierter Anfrage“ ist die Kennzahl, die die Geschäftsführung sehen will — und Analytics allein liefert sie nicht. Der Weg führt an den Werbekonten entlang, nicht durch Analytics.
- Die Klick-Kennung steht nur in der Adresse der Einstiegsseite — bei Google Ads
gclidsowie die Entsprechungen für App- und Browserfälle. Bis der Besucher beim Kontaktformular ankommt, ist sie weg. Sie muss deshalb auf der Einstiegsseite gelesen, zwischengespeichert und beim Absenden in ein verstecktes Feld geschrieben werden. Das ist der häufigste Grund, warum dieser ganze Weg still nichts liefert: Ein leeres Feld wirft keinen Fehler. - Die Zwischenspeicherung ist einwilligungspflichtig, weil sie Speicher im Browser braucht. Wer ablehnt, hinterlässt keine Klick-Kennung und wird nie zurückgemeldet. Rechnen Sie das mit: Die Kosten je qualifizierter Anfrage stellen die vollen Kanalkosten nur den einwilligenden Anfragen gegenüber und fallen deshalb systematisch zu hoch aus. Bei einer Zustimmungsrate von 62 Prozent ist das keine Nachkommastelle — nennen Sie den Effekt im Bericht, bevor jemand die Zahl zum ersten Mal sieht.
- Beim Wechsel auf „qualifiziert“ wird die Kennung mit Zeitstempel als Offline-Conversion zurück an das Werbekonto gemeldet. Damit kann die Gebotssteuerung auf qualifizierte Anfragen optimieren statt auf Formularsendungen.
- Das Klickfenster beträgt maximal 90 Tage. Genau deshalb wird auf
qualify_leadgesteuert und nicht auf den Auftrag: Die Qualifizierung liegt meist innerhalb dieser Frist, der Auftrag nicht. - Zwei Voreinstellungen im Werbekonto lassen den Weg sonst scheitern, obwohl alles andere stimmt: Die automatische Kennzeichnung der Anzeigenklicks muss aktiv sein, sonst existiert gar keine Kennung. Und das Conversion-Fenster der Conversion-Aktion muss auf 90 Tage stehen — steht es kürzer, wird der Upload an Tag 60 abgelehnt, obwohl die Frist eingehalten ist.
- Wo keine Klick-Kennung vorliegt, bleibt die Variante mit gehashten Kontaktdaten — einseitig verschlüsselt und nicht rückrechenbar, das ist der Unterschied, auf den es im Gespräch mit dem Datenschutz ankommt. Sie hat eigene Anforderungen und gehört vorher geprüft.
- Für LinkedIn, im B2B häufig der zweitgrößte bezahlte Kanal, gibt es einen eigenen Weg für Offline-Konversionen. Er folgt derselben Logik und braucht dieselbe Kennung im Datensatz.
Die Kosten selbst kommen nicht von allein in die Auswertung. Für Google-Kanäle liefert die Verknüpfung der Werbekonten die Zahlen; alle anderen Kanäle brauchen einen Kostendatenimport per Datei oder werden im Auswertungswerkzeug getrennt angebunden und über Kampagnenname und Datum zusammengeführt. Planen Sie diesen Schritt ein — er ist der Unterschied zwischen einer handgepflegten Tabelle und einem Bericht, der sich selbst aktualisiert.
Die Zusammenführung in BigQuery
Der Export legt je Tag eine Tabelle mit einer Zeile je Ereignis an. Drei Felder brauchen Sie, alles andere ist Zugabe: user_pseudo_id ist das Gegenstück zur Client-Kennung, event_params enthält die mitgesendeten Parameter als verschachtelte Liste, und session_traffic_source_last_click liefert den Kanal der Sitzung.
Beim Quellenfeld greifen fast alle zuerst zum falschen. Es gibt drei, und sie bedeuten Verschiedenes. collected_traffic_source enthält nur, was in genau diesem Ereignis an Kampagnenangaben mitkam — auf einer Danke-Seite nach mehreren internen Klicks ist das leer, und die Abfrage liefert dann durchgehend Nullwerte, obwohl die Messung stimmt. traffic_source ist die erste Akquisition des Nutzers und damit nutzerbezogen, nicht sitzungsbezogen. Was Sie brauchen, ist session_traffic_source_last_click: auf jeder Ereigniszeile der Sitzung gefüllt, mit Untergruppen für manuelle Kampagnen, Google-Ads-Kampagnen und die kanalübergreifende Zuordnung.
Innerhalb dieser Feldgruppe gibt es dieselbe Falle noch einmal eine Ebene tiefer: manual_campaign greift nur bei handausgezeichneten Links mit Kampagnenparametern. Google Ads mit automatischer Kennzeichnung, organische Suche, direkt und Verweise liegen dort nicht — sondern in cross_channel_campaign. Deshalb steht in der Abfrage unten COALESCE über beide. Kampagnennamen aus Google Ads holen Sie zusätzlich aus google_ads_campaign.campaign_name.
Die Werbeklick-Kennung holen Sie aus demselben Grund nicht aus dieser Zeile, sondern aus dem versteckten Formularfeld über das Kundenmanagement. Und eine Fußnote für Bestandsinstallationen: session_traffic_source_last_click gibt es erst in den neueren Exporten — in sehr alten Tagestabellen fehlt das Feld.
Diese Abfrage liefert je Anfrage den Kanal — sie ist die einzige, die Sie zum Start brauchen. Die Tabelle mit den Stufen aus dem Kundenmanagement verbinden Sie anschließend über lead_id.
SELECT
-- die eigene Kennung aus den Ereignisparametern herausziehen
(SELECT value.string_value FROM UNNEST(event_params)
WHERE key = 'lead_id') AS lead_id,
(SELECT value.string_value FROM UNNEST(event_params)
WHERE key = 'form_type') AS form_type,
user_pseudo_id,
-- Kanal der Sitzung, in der die Anfrage entstand
COALESCE(session_traffic_source_last_click.manual_campaign.source,
session_traffic_source_last_click.cross_channel_campaign.source)
AS quelle,
COALESCE(session_traffic_source_last_click.manual_campaign.medium,
session_traffic_source_last_click.cross_channel_campaign.medium)
AS medium,
session_traffic_source_last_click.cross_channel_campaign
.default_channel_group AS kanalgruppe,
PARSE_DATE('%Y%m%d', event_date) AS datum
FROM `projekt.analytics_XXXXXX.events_*`
-- der Bereichsfilter schließt die vorläufigen Tabellen des
-- laufenden Tages aus; der Platzhalter allein täte das nicht
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20261231'
AND event_name = 'generate_lead'
Damit steht die Grundlage: eine Zeile je Anfrage mit Kanal und Kennung, verbindbar mit den Vertriebsstufen. Alles Weitere — Trichter, Quoten, Kosten je Stufe — ist eine Auswertung auf dieser einen Verbindung.
Statuswechsel und Dubletten
Ein Datensatz wird häufig bearbeitet. Wenn die Rückmeldung an jeder Speicherung hängt, zählen Sie denselben Auftrag fünfmal. Drei Regeln verhindern das.
- Auslöser ist der Wechsel in einen Status, nicht das Vorliegen des Status.
- Je Kennung und Stufe wird genau einmal gemeldet. Das Kundenmanagement bekommt dafür ein Feld „gemeldet am“ je Stufe — ist es gefüllt, passiert nichts mehr.
- Rückschritte erzeugen kein Gegenereignis, sondern einen Protokolleintrag. Eine Ausnahme ist der Fall „Wiedervorlage“: Wird ein zurückgestellter Kontakt später doch qualifiziert, wird die Stufe am selben Datensatz fortgeschrieben und einmalig gemeldet — mit der ursprünglichen Kennung, damit der Kanal erhalten bleibt.
Die Einwilligungslücke gehört in den Bericht
Ein Teil Ihrer Besucher lehnt die Messung ab. Deren Anfragen kommen trotzdem an, tauchen in Analytics aber nicht oder nur modelliert auf. Das ist kein Fehler, sondern die Rechtslage — und es hat zwei Folgen, die im Bericht stehen müssen.
- Analytics zeigt weniger Anfragen als das Postfach. Nennen Sie den Anteil, statt ihn zu erklären, wenn jemand fragt. Eine Zeile im Bericht: „Zustimmungsrate im Zeitraum: 62 Prozent. Die ausgewiesenen Zahlen bilden diesen Anteil ab.“
- Die Kanalzuordnung ist bei Ablehnern schwächer oder fehlt ganz. Modellierte Werte sind Schätzungen und gehören als solche gekennzeichnet.
Die Zustimmungsrate liefert Analytics nicht von selbst. Sie entsteht in Ihrer Einwilligungslösung: Diese meldet die Entscheidung als eigenes Ereignis, oder Sie leiten aus dem Einwilligungsstand eine Dimension ab. Planen Sie das mit ein — sonst steht die Forderung nach der Zahl im Bericht und niemand kann sie liefern.
Der Test, der wirklich etwas beweist
Ein verbreiteter Prüfvorschlag lautet: Einwilligung ablehnen, Formular absenden, am Folgetag nachsehen, ob der Vorgang in Analytics auftaucht. Dieser Test führt in die Irre. Im erweiterten Einwilligungsmodus ist es der Normalzustand, dass die Tags feuern und cookielose Signale senden — die Treffer erscheinen dann, ohne dass ein Rechtsverstoß vorliegt. Wer den Test wörtlich nimmt, meldet dem Datenschutz ein Problem, das keines ist.
Prüfen Sie stattdessen die Punkte, an denen sich rechtmäßig von unrechtmäßig unterscheidet:
- Immer im frischen privaten Fenster testen. Wer vorher zugestimmt hat, findet alte Cookies, die manche Einwilligungslösung nicht löscht — und meldet dann doch wieder einen Verstoß, den es nicht gibt.
- Wird ein Analytics-Cookie gesetzt? Nach der Ablehnung darf im Browser kein Analytics-Cookie liegen. Liegt eines da, ist es ein Rechtsproblem.
- Trägt der Treffer den Einwilligungsstand korrekt? Im Netzwerkverlauf steht er in der gesendeten Anfrage im Parameter
gcs:G100bedeutet abgelehnt,G111bedeutet zugestimmt. Der ausführliche Stand einschließlich der Werbesignale liegt seit der zweiten Fassung des Einwilligungsmodus zusätzlich ingcd. Achten Sie auf die Stellen einzeln: Die vorletzte steht für die Werbespeicherung, die letzte für die Analytics-Speicherung.G101— Werbung abgelehnt, Analytics erlaubt — ist bei einer Einwilligungslösung mit getrennten Zwecken ein völlig normaler Zustand. Fehlerhaft ist es, wenn nach einer vollständigen Ablehnung an der letzten Stelle eine Eins steht.
Zur Vollständigkeit gehören außerdem ein dokumentierter Auftragsverarbeitungsvertrag, eine Beschreibung der Datenflüsse im Verarbeitungsverzeichnis, eine bewusst gesetzte Aufbewahrungsdauer und die Prüfung, ob die Rückmeldung aus dem Kundenmanagement wirklich nur technische Kennungen und kontrollierte Werte enthält. Dieser Beitrag ersetzt keine Rechtsberatung.
Aufbewahrungsdauer: die Voreinstellung ist zu kurz
Analytics ist standardmäßig auf zwei Monate eingestellt. Das ist der häufigste stille Datenverlust überhaupt. Für nutzer- und ereignisbezogene Daten sind in der kostenlosen Ausführung höchstens vierzehn Monate möglich — stellen Sie das am ersten Tag um.
Wichtig für die Einordnung: Die Begrenzung betrifft alles, was auf einzelne Nutzer und Ereignisse zurückgreift — also Explorationen, Segmente und nachträgliche Auswertungen. Die aggregierten Standardberichte bleiben darüber hinaus abrufbar. Sie können also weiterhin zwei Jahre generate_lead je Kanal vergleichen; was Sie verlieren, ist die Möglichkeit, diesen Zeitraum nachträglich neu zu schneiden. Genau dafür ist der BigQuery-Export da.
Die Reihenfolge: wer baut was, und wann
Die Abhängigkeiten sind wichtiger als die Einzelschritte. Wer in der falschen Reihenfolge arbeitet, baut zweimal.
| Nr. | Schritt | Wer | Setzt voraus |
|---|---|---|---|
| 1 | Lead-Stufen und Ablehnungsgründe festlegen, Gegenleistung und Abschaltklausel vereinbaren | Marketing und Vertrieb | — |
| 2 | Einwilligungsmodus entscheiden, Bewertung durch den Datenschutz | Marketing und Datenschutz | — |
| 3 | Aufbewahrung auf 14 Monate stellen, BigQuery verknüpfen | Marketing | — |
| 4 | Messkonzept als Tabelle schreiben | Marketing | 1 |
| 5 | Felder im Kundenmanagement anlegen, Auswahllisten pflegen | Kundenmanagement-Betreuung | 1 |
| 6 | Versteckte Felder im Formular, Kennungen erzeugen und übergeben | Entwicklung | 4, 5 |
| 7 | Ereignisse im Tag Manager, Auslöser auf den bestätigten Erfolg | Marketing oder Dienstleister | 4, 6 |
| 8 | Testdurchlauf mit dokumentierten Fällen | Marketing | 7 |
| 9 | Offline-Conversion-Import in die Werbekonten | Marketing oder Dienstleister | 6, 8 |
| 10 | Stufen aus dem Kundenmanagement nach BigQuery bringen: geplanter Export, Konnektor oder Tabelle als externe Quelle | Kundenmanagement-Betreuung und Marketing | 5, 8 |
| 11 | Auswertung in BigQuery, Berichte aufsetzen | Marketing | 3, 10 |
Schritt 10 wird regelmäßig vergessen und ist ein eigener Arbeitsschritt mit eigener Berechtigungsdiskussion: Die Tabelle mit den Vertriebsstufen muss in BigQuery ankommen, bevor sich irgendetwas verbinden lässt. Ein geplanter Export aus dem Kundenmanagement ist der saubere Weg, ein Konnektor der bequeme, eine gepflegte Tabelle als externe Quelle der pragmatische.
Schritt 2 und 3 stehen bewusst vor allem anderen: Der Einwilligungsmodus entscheidet, ob die Client-Kennung im versteckten Feld überhaupt existiert, und der Export beginnt nur mit dem Tag, an dem er verknüpft wird.
Der Testdurchlauf: ein Datensatz durch die ganze Kette
Eine Messung gilt als eingerichtet, wenn ein vollständiger Testfall dokumentiert vorliegt — nicht, wenn im Tag Manager alles grün ist.
| Schritt | Prüfung | Bestanden, wenn |
|---|---|---|
| Formular gesendet | Fehlerbehebungsansicht in Analytics | ein generate_lead mit allen Parametern, kein zweites |
| Pflichtfeld leer gelassen | Fehlerbehebungsansicht | kein Ereignis |
| Danke-Seite aufgerufen | Seitenpfad im Bericht | keine Abfrageparameter mit Eingaben |
| Datensatz im Kundenmanagement | manuell nachsehen | Kennung, Erstquelle und Datum sind gefüllt |
| Einstieg über eine Adresse mit angehängter Klick-Kennung, Formular auf einer anderen Seite absenden | Datensatz im Kundenmanagement | Klick-Kennung ist gefüllt — das prüft die Zwischenspeicherung |
| Status auf „qualifiziert“ | Zielsystem der Rückmeldung | genau eine Meldung, Kennung stimmt überein |
| Status erneut gespeichert | Zielsystem | keine zweite Meldung |
| Zurückgestellt, später qualifiziert | Zielsystem | eine Meldung, ursprüngliche Kennung erhalten |
| Einwilligung abgelehnt | Browser und Netzwerkverlauf | kein Analytics-Cookie, Einwilligungsstand korrekt übermittelt |
Halten Sie Datum, Prüfer und Ergebnis je Zeile fest. Dieses Protokoll ist bei der nächsten Umstellung — neues Formularsystem, neue Website, neuer Dienstleister — das Dokument, gegen das erneut abgenommen wird.
Drei Berichte, nicht einer
Wer die Daten liefert, gehört auf die Verteilerliste. Deshalb sind es drei Berichte und nicht zwei — der dritte ist die Gegenleistung an den Vertrieb.
| Betrieb, fortlaufend | Vertrieb, monatlich | Geschäftsführung, monatlich | |
|---|---|---|---|
| Inhalt | Ereignisse je Formularart, Quellen, Fehlerquoten, Zustimmungsrate (Herkunft der Zahl siehe Einwilligungslücke) | unbrauchbare Anfragen je Kanal und Grund, was daraufhin geändert wurde, und die Pflegequote | Trichter in absoluten Zahlen, Anteil erkennbar unbrauchbarer Anfragen, Kosten je qualifizierter Anfrage samt Hinweis auf die Einwilligungslücke |
| Frage | Funktioniert die Messung, und wo hakt es? | Wird der Müll weniger? | Zahlt der Kanal sich aus? |
| Format | Auswertungswerkzeug, frei filterbar | eine halbe Seite, immer gleich | eine Seite, gleicher Aufbau jeden Monat |
Nach dem Anfragedatum auswerten, nicht nach dem Qualifizierungsdatum. Bei vier bis neun Monaten Zyklus ist das die entscheidende Auswertungsregel und zugleich die häufigste Falle. Wer im Juni die Quote qualifizierter Anfragen nach Qualifizierungsdatum rechnet, misst die Bearbeitungsgeschwindigkeit des Vertriebs und nicht die Kanalqualität. Ordnen Sie jede Anfrage ihrem Anfragemonat zu — und markieren Sie die jüngsten drei bis sechs Monate ausdrücklich als unvollständig, sonst wird der naturgemäße Abfall am rechten Rand als Einbruch gelesen.
In den ersten sechs Monaten tragen die Zahlen noch nicht. Bei 180 Anfragen und 9 Aufträgen im Quartal haben Sie je Kanal einstellige Fallzahlen — darauf lässt sich nichts steuern. Berichten Sie in dieser Zeit die Stufe „qualifiziert“ statt der Aufträge, und fassen Sie Kanäle zu Gruppen zusammen. Auf Auftragsebene wird die Auswertung erst belastbar, wenn je Kanal zweistellige Fallzahlen vorliegen.
Der Trichter für die Geschäftsführung braucht absolute Zahlen und Quoten nebeneinander: 180 Anfragen, davon 96 bearbeitet, davon 34 qualifiziert, davon 9 Aufträge. Prozentwerte allein verdecken, dass die letzte Stufe aus neun Fällen besteht — und dass eine Veränderung um zwei Fälle keine Trendwende ist.
Sechs Fehler, die die Messung wertlos machen
- Den Buttonklick statt des bestätigten Versands messen. Erzeugt Zahlen über der Wirklichkeit — und niemand merkt es, solange niemand mit dem Postfach abgleicht.
- Alle Formulare als dieselbe Conversion behandeln. Newsletter, Bewerbung und Projektanfrage in einer Zahl ergeben eine Kennzahl, die keine Entscheidung trägt.
- Späte Stufen per Measurement Protocol senden. Nach 72 Stunden entsteht ein Ereignis ohne Kanalbezug, und selbst darunter greift das Rückblickfenster von höchstens 90 Tagen.
lead_idals Dimension registrieren. Zu viele verschiedene Werte, die Berichte kippen in eine Sammelzeile.- Personenbezogene Daten in Parametern oder Adresszeilen. Meist unabsichtlich über die Danke-Seite — und nachträglich nur begrenzt zu reparieren.
- Den Vertrieb liefern lassen, ohne ihm etwas zurückzugeben. Die Pflege bricht dann nach etwa sechs Wochen ab, und niemand nennt den wahren Grund.
Prüffragen vor der Abnahme
- Hat der Vertrieb die Ablehnungsgründe selbst festgelegt, und findet sein häufigster Fall sich in der Liste?
- Steht die Gegenleistung schriftlich — monatlicher Bericht an den Vertrieb und Abschaltklausel nach einem Quartal?
- Liegt die Pflegequote über achtzig Prozent, und sieht der Vertrieb sie zuerst?
- Wird nach Anfragedatum ausgewertet, und sind die jüngsten Monate als unvollständig markiert?
- Existiert das Messkonzept als Tabelle, bevor der Tag Manager geöffnet wurde?
- Misst jedes Ereignis den bestätigten Erfolg, belegt durch einen Testfall?
- Ist die Aufbewahrung auf 14 Monate gestellt und der BigQuery-Export verknüpft?
- Wandern Klick-Kennungen ins Kundenmanagement, und ist der Rückweg in die Werbekonten eingerichtet?
- Kann ein Parameter oder eine Adresszeile personenbezogene Inhalte tragen — und ist die Ursache abgestellt, nicht nur das Symptom?
Häufige Fragen
Unser Vertriebszyklus dauert neun Monate. Was messen wir dann überhaupt?
In Analytics: alles bis generate_lead, mit sauberer Kanalzuordnung und Formularart. Alles Weitere im Kundenmanagement, verbunden über die Kennung, ausgewertet in BigQuery. Die Steuerungsgröße für das laufende Jahr ist nicht der Auftrag, sondern die Rate qualifizierter Anfragen je Kanal — sie liegt nach Wochen vor und passt in das 90-Tage-Fenster der Werbekonten.
Wie überzeuge ich den Vertrieb, zwei Felder zu pflegen?
Mit drei Zusagen, nicht mit Argumenten: eine ehrliche Zahl zum Aufwand (Statusklicks unter zehn Sekunden je Anfrage, das Anlegen eines Kontakts ohne Formular rund zwei Minuten — zusammen etwa vier Stunden je Quartal fürs Team), ein monatlicher Bericht in die Gegenrichtung, und eine Abschaltklausel nach einem Quartal. Und indem der Vertrieb die Ablehnungsgründe selbst festlegt. Eine Liste, in der das Team seinen häufigsten Fall nicht findet, erzeugt Zufallsklicks und damit unbrauchbare Daten.
Dürfen E-Mail-Adressen als Parameter gesendet werden?
Nein. Personenbezogene Daten gehören nicht in Analytics — weder als Parameter noch in der Adresszeile noch in einem Freitextfeld. Verwenden Sie zufällige Kennungen und kontrollierte Kategorien. Für die Rückmeldung an Werbekonten gibt es einen eigenen Weg über gehashte Kontaktdaten — einseitig und nicht rückrechenbar — mit eigenen Anforderungen.
Analytics zeigt weniger Anfragen als unser Postfach. Ist das ein Fehler?
Meistens nicht. Die Differenz erklärt sich durch abgelehnte Einwilligungen, Werbeblocker und Anfragen, die per Telefon oder E-Mail direkt eingehen. Auffällig wird es in die andere Richtung: Zeigt Analytics mehr Anfragen als das Postfach, messen Sie fast sicher Klicks statt Erfolge.
Wir haben kein Kundenmanagement. Geht das trotzdem?
Ja, mit einer gemeinsamen Tabelle. Sie braucht sechs Spalten: Kennung, Datum, Erstquelle, Klick-Kennung, Stufe, Ablehnungsgrund. Der Vertrieb pflegt die letzten beiden nach dem Erstgespräch. Das ist weniger komfortabel und liefert dieselben Erkenntnisse — die Systemfrage ist zweitrangig, die Disziplin bei der Pflege nicht.
Hilft serverseitiges Tagging gegen die Messlücke?
Teilweise. Es macht die Erfassung robuster gegenüber Werbeblockern und verlängert die Lebensdauer von Cookies, die der Server setzt. Es ersetzt aber keine Einwilligung, hebt die Browserbeschränkungen nicht vollständig auf und verursacht laufende Kosten für den Betrieb. Sinnvoll, wenn die Grundlagen stehen — nicht als erster Schritt.
Begriffe: Klartext und technischer Name
Damit der Text lesbar bleibt und die Umsetzung trotzdem kopierbar ist, hier die Zuordnung.
| Im Text | Technisch |
|---|---|
| Client-Kennung | Client ID, im Export user_pseudo_id |
| Abfragefunktion des Tags | gtag('get', 'G-XXXXXXX', 'client_id', callback) |
| Sitzungskennung | session_id, im Measurement Protocol mitzusenden |
| Parameter mit dem Einwilligungsstand | gcs — vierstellig, vorletzte Stelle Werbung, letzte Analytics (G100 alles abgelehnt, G111 zugestimmt, G101 nur Analytics); ausführlich gcd. Fehlt gcs ganz, ist der Einwilligungsmodus nicht eingebunden. |
| Einwilligungssignale für Werbeplattformen | ad_user_data, ad_personalization |
| Werbeklick-Kennung, App- und Browserfälle | gclid, wbraid, gbraid |
| Kanal der Sitzung im Export | session_traffic_source_last_click |
| Einwilligungsmodus, Basis und erweitert | Consent Mode basic / advanced |
| Datenschicht | dataLayer |
| Fehlerbehebungsansicht | DebugView |
| Schlüsselereignis | bis 2024 „Conversion“ genannt |
Quellen und Vertiefung
- Google Analytics: Empfohlene Ereignisse, darunter die sechs Lead-Stufen
- Measurement Protocol: Ereignisse senden — 72-Stunden-Grenze für die Rückdatierung
- Google Analytics: Attributionseinstellungen — Rückblickfenster von 30, 60 oder 90 Tagen
- Google Analytics: Datenaufbewahrung — 2 oder 14 Monate
- Google Analytics: BigQuery-Export — Einrichtung, Tageslimit und Kosten
- Google Analytics: Verhaltensmodellierung — Schwellenwerte
- Google Analytics: Nutzerdaten aus Ereignissen entfernen lassen
- Google Analytics: BigQuery-Exportschema — Felder zur Besucherquelle
- Google: Funktionsweise des Einwilligungsmodus
Passende nächste Schritte
Den Aufbau der Messkette beschreibt unsere Leistung Analytics & Tracking. Wenn die Zahlen anschließend Kampagnen steuern sollen, ist SEA der passende nächste Schritt.
Bauen Sie eine Messung, die beim Auftrag endet
Wir ordnen Ereignisse, Einwilligung und Kundenmanagement so, dass Marketing nicht bei der Formularsendung aufhört — und dokumentieren jeden Testfall.