Formular-Setup

Beaconry hängt sich server-seitig in das Submission-Event von sieben Form-Plugins und feuert eine Lead-Conversion an jeden Kanal, den du angebunden hast, wobei E-Mail, Telefon und jede andere erkannte PII gehasht wird, bevor sie deinen Server verlässt. Kein JavaScript-Gefrickel, keine Pixel-Snippets pro Formular. Plugin aktivieren, die Formular-Integration anschalten, fertig.

Die sieben Adapter

Jedes Form-Plugin bekommt einen eigenen Adapter, der sich an den echten Submission-Hook dieses Plugins bindet (nicht an einen generischen DOM-Listener). Ein Adapter registriert sich nur, wenn sein Host-Plugin tatsächlich geladen ist, sodass eine Installation mit nur Fluent Forms niemals Gravity-Code-Pfade mitschleppt. Alle sieben sind in jedem Beaconry-Build enthalten und stabil. Es gibt keine Beta-Adapter.

Die Spalte "Eager Discovery" zählt für die Setup-Ergonomie. Fluent und Kadence Advanced legen ihre vollständige Formular-Liste über eine einzige Query offen, sodass Beaconry jedes Formular im Moment, in dem du den Formulare-Tab öffnest, in der Mapping-Tabelle anzeigen kann. Die anderen Plugins speichern Formulare auf Arten, die bei jedem Admin-Seitenaufruf zu teuer zu scannen sind, deshalb erscheinen ihre Zeilen nach der ersten echten Submission. Das Tracking funktioniert für diese Formulare trotzdem sofort, du konfigurierst Overrides nur, nachdem sie einmal gefeuert haben.

Eine Formular-Integration anschalten

Der Formulare-Tab erscheint im Beaconry-Menü nur, wenn mindestens ein unterstütztes Form-Plugin aktiv ist, sodass du nie auf einen leeren Tab starrst. Darin hat jedes erkannte Plugin einen Master-Schalter. Schalte ihn an, und jedes Formular, das zu diesem Plugin gehört, beginnt beim Absenden Lead-Events zu feuern. In das Formular selbst muss nichts eingefügt werden.

Wenn du nur einige Formulare eines Plugins tracken willst, nutze die Whitelist pro Formular im selben Tab statt des pauschalen Schalters. Eine leere Whitelist bedeutet "alle Formulare"; Einträge engen es auf genau diese ein.

Wie die Auto-Erkennung funktioniert

Beaconry verlangt nie, dass du deine Formulare von Hand benennst. Zwei Mechanismen halten die Mapping-Tabelle mit der Realität synchron:

1. Eager Katalog-Sync. Jedes Mal, wenn der Formulare-Tab rendert, fragt Beaconry jeden aktiven Adapter nach seinen Formularen und merged sie in den gespeicherten Katalog. Neue Formulare bekommen eine leere Default-Zeile, umbenannte Formulare bekommen ihr Label aufgefrischt, und deine bestehenden Einstellungen pro Formular bleiben unangetastet. So ist ein Formular, das du gerade in Fluent oder Kadence Advanced gebaut hast, konfigurierbar, bevor es jemals abgesendet wurde.
2. Lazy Erst-Submission-Registrierung. Für die Plugins, die nicht günstig gescannt werden können (und für Kadences Inline-Block-Formular), registriert die erste echte Submission das Formular. Ab dann hat es eine Zeile in der Tabelle wie jedes andere.

So oder so wird das Formular über eine stabile zusammengesetzte ID (plugin_formid, bereinigt) verschlüsselt, sodass dasselbe Formular über Renders und Submissions hinweg immer auf dieselbe Konfigurationszeile abbildet.

Die Feld-Mapping-Oberfläche pro Formular

Wenn ein Besucher absendet, läuft Beaconry die abgesendeten Felder durch und versucht, die zu erkennen, die für die Werbetreibenden-Match-Qualität nützlich sind: E-Mail, Telefon, Vorname, Nachname, PLZ, Stadt, Bundesland, Land, Geschlecht, Geburtsdatum und eine externe Kunden-ID. Die Erkennung ist eine Heuristik über Label und Name des Felds, abgestimmt auf englische, deutsche und spanische Formulierungen. So lösen E-Mail, email_1, Ihre Mail-Adresse alle auf den E-Mail-Slot auf; Vorname löst auf Vorname auf; PLZ und Postleitzahl lösen auf PLZ auf.

Der Formulare-Tab rendert eine Tabelle pro Formular mit jedem erkannten Feld neben dem, worauf die Heuristik es aufgelöst hat. Jede Zeile trägt ein Dropdown, sodass du die Vermutung überschreiben kannst:

• Lass es auf der dynamischen Auto (X)-Voreinstellung, um die Heuristik zu akzeptieren.
• Wähle ein anderes Ziel, um ein Feld umzumappen, das die Heuristik falsch zugeordnet oder verpasst hat (zum Beispiel ein deutsches Land-Feld, das du auf Land mappen willst, das die eingebaute Heuristik absichtlich in Ruhe lässt, um Fehlmatches wie Deutschland oder Landkreis zu vermeiden).
• Wähle Nicht mappen, um ein Feld komplett auszuschließen (siehe nächster Abschnitt).

Overrides gelten pro Formular, nicht global. Dasselbe Feld-Label kann in zwei verschiedenen Formularen auf verschiedene Slots mappen, und die Zeile ist mit (auto) oder (manual) annotiert, sodass du auf einen Blick siehst, welche Felder du angefasst hast.

Getrennt vom PII-Mapping hat jedes Formular einen Lead-Typ. Die Voreinstellung ist ein generischer Lead, aber du kannst ein Formular auf Kontakt, Bewerbung, Newsletter, Registrierung, Termin, Trial, Download oder Spende setzen, oder pro Kanal einen vollständig eigenen Event-Namen angeben. Der Lead-Typ ist es, der über den Event-Namen entscheidet, der an jede Plattform gesendet wird:

Der Dispatcher löst aus einem einzigen Typ-Pick den passenden Event-Namen für jeden angebundenen Kanal auf, sodass du die geschäftliche Bedeutung einmal wählst und jede Plattform den Namen bekommt, den sie erwartet. Ein nicht gesetzter oder unbekannter Typ fällt auf einen schlichten Lead zurück.

Der manuelle Skip-Marker

Die PII-Heuristik ist bewusst eager, denn Untermatchen kostet dich Werbetreibenden-Match-Qualität. Aber manchmal sieht ein Feld wie PII aus, und du willst es nicht weitergeben. Ein "Grund der Kontaktaufnahme"-Feld mit dem Wort "Mail" darin, eine interne Referenznummer, die per Muster auf die External-ID-Regel matcht, ein Freitext-Feld, das zufällig das Wort "Tel" enthält. Für die hat das Feld-Mapping-Dropdown eine Nicht mappen-Option.

Sie zu wählen speichert einen expliziten Skip-Marker für dieses Feld auf diesem Formular. Der wichtige Punkt ist, dass der Marker explizit ist: er löscht nicht nur deinen Override, er stoppt aktiv, dass die eingebaute Heuristik das Feld als Fallback erneut matcht. So bleibt ein Feld, das du übersprungen hast, übersprungen, obwohl sein Name noch nach E-Mail oder Telefon aussieht. In der Tabelle zeigt es sich als manuelle Entscheidung, nicht als nicht-gematchtes Feld, sodass du "das habe ich absichtlich ausgeschlossen" von "die Heuristik hat hier nichts gefunden" unterscheiden kannst.

Nutze es immer dann, wenn die Heuristik bei der Formulierung technisch recht hat, aber bei der Absicht falsch liegt. Es ist die saubere Alternative dazu, ein Formularfeld umzubenennen, nur um dem Tracking auszuweichen.

Was beim Absenden passiert

Wenn ein getracktes Formular abgesendet wird, baut Beaconry ein kanonisches Lead-Event und schickt es durch denselben server-seitigen Forwarder, den jedes andere Event nutzt. Konkret:

• Die erkannten Felder werden in einen User-Data-Block gesammelt (em, ph, fn, ln, zp, ct, st, Land, Geschlecht, Geburtsdatum, External-ID). Die Telefonnummer wird Richtung E.164 normalisiert, das Geschlecht auf ein einzelnes f/m, das Geburtsdatum auf YYYYMMDD, alles vor dem Hashing.
• Jeder Kanal, den du angebunden hast, bekommt das Event, jeweils mit der PII SHA-256-gehasht gemäß der Matching-Spec dieses Kanals. Die Roh-Werte verlassen deinen Server nie. Ein Kanal, den du nicht angebunden hast, wird einfach übersprungen.
• Der Event-Name pro Kanal kommt aus dem Lead-Typ des Formulars (siehe Tabelle oben). Standardmäßig ist das generate_lead für GA4 und Lead für die Ad-Plattformen.
• Der stabile Formular-Key wird als Content-ID angehängt, sodass Meta und TikTok aufhören, vor fehlenden Content-Details zu warnen, und du eine saubere Zielgruppe pro Formular zum Aufbauen bekommst. Das Beaconry-Lead-Typ-Label wird intern für die Spalte "Quelle" in Logs und Live-Dashboard festgehalten, aber bewusst nicht in content_category geschrieben (dieses Feld ist für echte Produktkatalog-Kategorien aus den Commerce-Adaptern reserviert).
• Wenn der Hybrid-Modus für einen Kanal an ist, injiziert die Browser-Engine zur Submission-Zeit eine geteilte event_id, sodass der Anbieter die Browser- und Server-Kopie des Leads dedupliziert. Siehe Hybrid-Modus.

Weil die Submission bereits in PHP passiert ist (der Besucher hat auf Absenden geklickt), gibt es auf dieser Ebene keine separate Consent-Neuprüfung. Consent wird einmal, zentral, im Dispatcher durchgesetzt, dasselbe Gate, das Commerce und Custom Events abdeckt.

Ein ganzes Formular nicht weiterleiten?

Drei Hebel, nach Härte sortiert:

1. Skip pro Feld, um den Wert eines Felds auszuschließen, während der Lead weiter getrackt wird (der Skip-Marker oben).
2. Whitelist pro Formular, um nur bestimmte Formulare eines Plugins zu tracken.
3. Plugin-Master-Schalter aus, um das Tracking der Formulare dieses Plugins komplett zu stoppen.

Wissen wollen, wo Besucher abspringen?

Lead-Tracking sagt dir, wer konvertiert hat. Form-Funnel-Analytics sagt dir, wer gestartet und abgesprungen ist, und bei welchem Feld. Es ist ein separates, opt-in Feature im selben Formulare-Tab, das Formular-Starts, Abbrüche und Lead-Submissions pro Formular aufzeichnet, nur mit Feldnamen und Zählern (nie mit Feldwerten). Es ist von Bauart her reine Analytics: ein Abbruch erreicht höchstens GA4 (und nur, wenn du das anschaltest), nie einen Ad-Kanal, und Commerce-Checkouts sind ausgeschlossen, weil sie ihren eigenen View-to-Purchase-Funnel haben. Aktiviere es unter Beaconry → Formulare → Form-Funnel und lies dort die Drop-off-Tabelle pro Formular (Starts, Leads, Abbrüche, Conversion-Rate, Top-Drop-off-Felder).