Drop-off-Analyse fürs Formular-Funnel

Lead-Tracking sagt dir, wer konvertiert hat. Die Formular-Funnel-Analyse sagt dir, wer angefangen hat, wer abgesprungen ist und an welchem Feld. Beaconry erfasst drei Signale pro Formular (form_start, form_abandon, Lead-Submit), aggregiert sie zu einer Drop-off-Tabelle pro Formular und hält die Verhaltens-Signale strikt analytics-only, sodass sie nie zu einer Werbeplattform durchsickern.

Das Problem, das es löst

Eine Lead-Conversion ist eine einzelne Zahl: jemand hat abgeschickt. Sie kann dir nicht sagen, dass vierzig Prozent der Leute, die dein Angebots-Formular gestartet haben, am Telefon-Feld aufgegeben haben, oder dass dein dreistufiges Bewerbungs-Formular in Schritt zwei Besucher verliert. Diese Erkenntnis lebt in der Lücke zwischen "hat angefangen zu tippen" und "hat abgeschickt", und der einzige Weg, sie normalerweise in GA4 zu sehen, ist, selbst form_start-Events zu instrumentieren, von Hand eine Funnel-Exploration zu definieren, jeden Schritt zu benennen und dieses Funnel jedes Mal synchron zu halten, wenn du das Formular bearbeitest.

Die Formular-Funnel-Analyse erledigt diesen Teil für dich. Du legst einen Schalter um, und Beaconry pflegt pro Formular eine Tabelle aus Starts, Leads, Abbrüchen, einer Conversion-Rate und den Feldern, an denen Leute abbrechen, berechnet aus Daten, die es bereits durch die Pipeline laufen sieht. Keine GA4-Exploration zu bauen, kein Event-Schema zu entwerfen, keine Funnel-Definition zu pflegen.

Die drei Signale

Jedes Formular wird aus drei unabhängigen Events zusammengefasst, alle an dasselbe Formular gekoppelt, sodass sie zu einer Funnel-Zeile zusammenfallen.

• form_start, von der Browser-Engine beim ersten Fokus in ein Formular-Input gefeuert. Ein Start pro Formular pro Besuch, als Counter erfasst.
• form_abandon, von der Browser-Engine beim Verlassen der Seite (pagehide / visibilitychange) gefeuert, wenn ein Formular gestartet wurde, mindestens ein Feld ausgefüllt ist und es nicht abgeschickt wurde. Es trägt nur den NAMEN des zuletzt berührten Felds plus die Counts für ausgefüllte und gesamte Felder. Nie einen Feldwert.
• Lead-Submit, server-seitig gefeuert, wenn das Formular tatsächlich abgeschickt wird, dasselbe Lead-Event, das der Rest von Beaconry ohnehin schon sendet. Es ist an den stabilen Key des Formulars gekoppelt, sodass es als der "konvertierte" Schenkel desselben Funnels zählt.

Starts, Abbrüche und Submits werden als Buckets pro Formular und pro Tag in einer einzigen nicht-autoloaded Option gespeichert, beim Schreiben gekürzt mit einem 90-Tage-Daily-Cron-Cleanup dahinter. Es gibt keine zusätzliche Datenbank-Tabelle und keine Zeile pro Event, der Funnel-Store ist ein kleines rollierendes Aggregat.

Die drei Signale auf ein Formular ausrichten

Damit das Funnel korrekt gelesen wird, müssen sich alle drei Events einig sein, zu welchem Formular sie gehören. Beaconry macht das mit einem stabilen zusammengesetzten Formular-Key.

Die Browser-Engine leitet einen Key aus dem Formular in der Seite ab, und der Server leitet denselben Key aus dem Submission ab. Für Fluent Forms und Kadence Advanced Form stimmen die beiden exakt überein (fluent_<id> / kadence_adv_<post_id> auf beiden Seiten), sodass diese zwei Plugins das volle Bild bekommen: Starts, Abbrüche und Leads fallen alle auf eine Zeile zusammen. Für die anderen Formular-Plugins landen der Browser-Start und -Abbruch unter der DOM-id des Formulars, während der Lead-Submit unter dem Server-Key landet, sodass du für jedes Plugin weiterhin einen vollständigen Lead-Count bekommst, und das Start-/Abbruch-Drop-off-Detail ist auf Fluent und Kadence Advanced am vollständigsten, wo die Keys übereinstimmen.

Deshalb ist die Abbruch-Detail-Hälfte des Features auf Fluent und Kadence Advanced am stärksten. Das ist eine Folge davon, dass diese Plugins eine id offenlegen, die der Browser vor dem Submit lesen kann, keine Tier-Entscheidung.

Die Drop-off-Tabelle pro Formular

Der Forms-Tab rendert eine Tabelle, die aus einem 30-Tage-Snapshot des Stores gebaut wird. Formulare ohne Aktivität im Fenster werden weggelassen, und Zeilen werden nach Volumen sortiert (Starts plus Submits), sodass deine aktivsten Formulare oben stehen. Jede Zeile trägt:

Die Spalte "Top-Drop-off-Felder" ist der handlungsrelevante Teil. Wenn ein Angebots-Formular die meisten seiner Abbrüche an phone zeigt, ist dieses Feld deine Reibung. Mach es optional, verschieb es nach hinten oder erkläre, warum du es brauchst, und beobachte dann die Spalte in der nächsten Woche. Die Tabelle zeigt außerdem eine Abbruch-Rate (Abbrüche über Starts) und ein "Liste leeren"-Control, um den Store zurückzusetzen, wenn du nach einem Redesign eine saubere Baseline willst.

Analytics-only by construction

Das ist der Teil, der für sauberes Ad-Reporting zählt. form_start und form_abandon sind Verhaltens-Signale, keine Conversions, und Beaconry garantiert per Code, dass sie nie einen Ad-Vendor erreichen. Zwei unabhängige Gates setzen das durch.

1. Das Opt-in-Gate läuft zuerst, innerhalb des Funnel-Observers. Es erfasst das Event immer in den Plugin-internen Store, und dann bricht es für form_abandon das Dispatch komplett ab, es sei denn, du hast das Weiterleiten von Abbrüchen an GA4 explizit eingeschaltet. Standardmäßig berührt ein Abbruch also nur Beaconrys eigenen Funnel-Store und geht über die Leitung nirgendwohin.
2. Das zentrale Routing-Gate läuft im Dispatcher, direkt nach den Pre-Dispatch-Filtern. Es gleicht den Event-Namen gegen eine einzige Analytics-only-Liste ab und routet das Event bei einem Treffer nur an GA4 und stoppt hart vor jedem Ad-Vendor-Kanal. Ein Check deckt Meta, TikTok, LinkedIn, Google Ads, Microsoft Ads, Pinterest, X Ads, Snapchat und Reddit auf einmal ab, und jeder Ad-Kanal, der künftig dazukommt, erbt die Regel automatisch, ohne dass es eine Pro-Kanal-Ausnahme zu merken gäbe.

Der Netto-Effekt, in jeder Schalter-Kombination:

• Ein Abbruch erreicht nur GA4, und nur, wenn du das GA4-Weiterleiten fürs Funnel eingeschaltet hast. Sonst bleibt er vollständig im Plugin-Store.
• Ein Abbruch erreicht nie einen Ad-Kanal.
• Ein form_start erreicht nur GA4 (wenn GA4 verbunden ist), nie einen Ad-Kanal.

Dieses zweite Gate ist die Single Source of Truth für die Trennung "internes Signal versus Ad-Vendor-Conversion". Es existiert, weil sich allein auf Pro-Kanal-Skip-Listen zu verlassen fragil ist: Kanal hinzufügen, den Skip-Eintrag vergessen, und ein Verhaltens-Event fängt still an, den Conversion-Count dieses Kanals aufzublähen. Das zentrale Gate macht diese Klasse von Regression unmöglich.

Was an GA4 weitergeleitet wird und was nicht

Selbst wenn du dich fürs GA4-Weiterleiten entscheidest, ist das, was reist, bewusst dünn. form_abandon trägt den NAMEN des zuletzt berührten Felds und die Counts für ausgefüllte und gesamte Felder. Es gibt keinen Feldwert, keine E-Mail, keine Telefonnummer, nichts, was ein Besucher getippt hat. Das ganze Feature ist PII-sicher by construction (nur Feldnamen und Counts), weshalb es kein spezielles DSGVO-Handling braucht, der Funnel-Store kann nie personenbezogene Daten enthalten, weil die Events, die ihn speisen, nie welche tragen.

Commerce-Checkouts werden bewusst ausgeschlossen

WooCommerce- (Classic und Block), Easy-Digital-Downloads- und SureCart-Checkouts werden explizit aus dem Formular-Funnel herausgehalten. Sie sind keine Lead-Formulare, und sie haben bereits ihr eigenes view-, begin_checkout-, purchase-Funnel. Schlimmer noch, ihr Bestell-Submit ist für ein Formular-Funnel unsichtbar (Store-API oder AJAX, ohne nativen Form-Submit, den der Browser sehen kann), sodass ein abgeschlossener Kauf wie ein Abbruch aussähe und bei jeder erfolgreichen Bestellung einen fälschlich feuern würde.

Zwei Schichten halten sie draußen:

• Ein render-agnostisches Exclude-Flag, gesetzt aus den Plattform-APIs selbst (is_checkout(), is_cart(), edd_is_checkout()). Das schaltet das ganze Funnel auf einer Commerce-Checkout- oder -Warenkorb-Seite ab, inklusive Markup wie EDDs eigenem Block-Checkout, das ein CSS-Selektor nicht zuverlässig matchen könnte.
• Ein CSS-Klassen-Backstop in der Browser-Engine, der die Checkout- und Warenkorb-Komponenten-Klassen von WooCommerce, EDD und SureCart erkennt, falls das Signal auf Seiten-Ebene verpasst wurde.

Checkout-Schritt-Abbruch ist weiterhin messbar, das ist nur die Aufgabe des Commerce-Funnels: ein begin_checkout ohne passenden purchase. Siehe Server-seitiges Tracking fürs Commerce-Funnel.

Wie du es aktivierst

wp-admin, Beaconry, Forms-Tab, Form-Funnel-Karte. Zwei Schalter:

1. Formular-Funnel-Analyse aktivieren schaltet das Start- und Abbruch-Recording in der Browser-Engine ein und beginnt, die Tabelle pro Formular zu füllen. Das ist alles, was du für die Drop-off-Tabelle brauchst. Die Signale bleiben im Plugin-Store. Standardmäßig aus.
2. Abbrüche an GA4 weiterleiten lässt zusätzlich form_abandon zu GA4 durch (und nur GA4, siehe oben), sodass du deine eigenen GA4-Explorations darauf aufbauen kannst. Lass es aus, und Abbrüche verlassen nie das Plugin. Standardmäßig aus.

Der Forms-Tab erscheint nur dann im Beaconry-Menü, wenn mindestens ein unterstütztes Formular-Plugin aktiv ist, und die Funnel-Karte lebt dort neben dem Pro-Formular-Feld-Mapping, das in Formular-Setup behandelt wird. Das Einschalten des Features erfordert nichts im Formular-Markup selbst.

Gegenüber einem von Hand gebauten GA4-Funnel

Du kannst ein vergleichbares Funnel direkt in GA4 bauen, und wenn du bereits eine GA4-Funnel-Exploration hast, die dir gefällt, behalte sie. Der Unterschied liegt in den Betriebskosten und den Garantien.

Sie schließen sich nicht gegenseitig aus. Der Schalter "Abbrüche an GA4 weiterleiten" existiert genau dafür, dass du beides haben kannst: die schnelle eingebaute Tabelle fürs Tagesgeschäft und den rohen form_abandon-Stream in GA4 für eine Custom-Exploration, wobei die Ad-Kanäle so oder so vom Verhaltens-Rauschen geschützt bleiben.

Troubleshooting

• "Ein Formular zeigt Leads, aber null Starts oder Abbrüche": das Plugin dieses Formulars legt keine id offen, die der Browser vor dem Submit lesen kann, sodass sein Start und Abbruch unter einem anderen Key landen als sein server-seitiger Lead. Die Lead-Counts sind weiterhin korrekt. Das volle Start-bis-Abbruch-Detail ist auf Fluent Forms und Kadence Advanced Form am vollständigsten, wo die Browser- und Server-Keys übereinstimmen.
• "Abbrüche erreichen GA4 nicht": das Funnel allein zu aktivieren hält Abbrüche im Plugin-Store. Du brauchst zusätzlich den zweiten Schalter, "Abbrüche an GA4 weiterleiten". Das ist Absicht, die Tabelle funktioniert, ohne irgendetwas an GA4 zu senden.
• "Ich sehe ein form_abandon in GA4, aber nicht in Meta oder Google Ads": das ist korrekt und kein Bug. Verhaltens-Signale sind analytics-only und werden vor jedem Ad-Kanal hart gestoppt. Es gibt keine Einstellung, die sie an einen Ad-Vendor weiterleitet.
• "Ein abgeschlossener Checkout sah wie ein Abbruch aus": sollte er nicht, Commerce-Checkout- und -Warenkorb-Seiten werden sowohl auf Seiten-API-Ebene als auch auf CSS-Klassen-Ebene aus dem Funnel ausgeschlossen. Wenn du Seiten umbenannt hast oder einen Nicht-Standard-Checkout nutzt, bestätige, dass die Seite über die Plattform-API auflöst (is_checkout() und Konsorten), denn so wird das Exclude erkannt, nie über den URL-Slug.
• "Die Tabelle ist direkt nach dem Aktivieren leer": sie füllt sich, während Besucher interagieren. Starts und Abbrüche brauchen echten Formular-Fokus und Seiten-Verlassen, und Admins sind standardmäßig vom Front-end-Tracking ausgeschlossen, also teste als ausgeloggter Besucher.