Click-Tracking

Manche Conversions sind einfach nur ein Klick. Ein "Termin buchen"-Button, ein ausgehender Link zu deinem Polar-Checkout, ein "Kostenlos testen"-CTA, der in einer Drittanbieter-App lebt. Setze eine von fünf Beaconry-CSS-Klassen auf dieses Element und der Klick feuert eine echte server-seitige Conversion an jeden Kanal, den du verbunden hast, ganz ohne Per-Vendor-Snippet und ohne JavaScript-Klebcode.

Was es macht

Formular-Submissions und Commerce-Events werden von dedizierten Hooks abgefangen (Beaconry bindet den echten Submission-Hook von sieben Form-Plugins und die echten Funnel-Hooks von WooCommerce, EDD und SureCart). Aber viele bedeutsame Aktionen sind weder ein Formular noch ein Warenkorb-Event: ein Anchor, der deine Site Richtung externem Checkout verlässt, ein Button, der ein Booking-Widget öffnet, ein "Trial herunterladen"-Link, ein Pricing-CTA, der zu einem iframe scrollt. Es gibt keinen server-seitigen Hook zum Binden, weil die Aktion vollständig im Browser passiert und oft wegnavigiert.

Click-Tracking schließt diese Lücke mit einer generischen, klassengetriebenen Erfassung. Du dekorierst das Element mit einer Beaconry-Klasse, annotierst es optional mit ein paar Data-Attributen, und Beaconry behandelt den Klick wie jedes andere Event: Er läuft durch denselben Same-Origin-REST-Endpoint und denselben server-seitigen Forwarder, sodass er als Standard-Conversion bei Meta, Google Ads, TikTok und dem Rest landet. Kein Vendor-Pixel berührt die Seite.

Die fünf Klassen-Slots

Es gibt genau fünf Slots. Jeder bildet ein Standard-Werbe-Event ab, und zwar bewusst, damit Vendor-Kanäle ihr Optimierungs-Signal behalten, statt ein undurchsichtiges Custom-Event zu bekommen, auf das sie nicht bieten können. Setze die Klasse auf ein beliebiges klickbares Element (<a>, <button> oder alles, an das du einen Klick delegierst) und das Event dieses Slots feuert.

Eine Anmerkung zu den GA4-Namen, weil sie Leute stolpern lässt: Der Checkout-Slot sendet GA4-begin_checkout, nicht initiate_checkout. begin_checkout ist GA4s kanonische Schreibweise, und der Forwarder ist es, der das pro Kanal übersetzt: Meta und TikTok bekommen InitiateCheckout, Pinterest bekommt initiate_checkout, Snapchat sein eigenes Start-Checkout-Event und so weiter. Du konfigurierst eine CSS-Klasse, jede Plattform bekommt den Namen, den sie erwartet.

Die Slots .beaconry-contact und .beaconry-cta lösen zu Events auf, die keine Meta-Standard-Events sind, daher gehen sie bei Meta als Custom-Events raus (Contact, ViewContent), während sie bei GA4 erstklassige Standard-Events bleiben. Das ist Absicht: Ein Kontakt oder ein generischer CTA ist echtes Engagement, das festzuhalten sich lohnt, aber er sollte sich nicht als Checkout oder Kauf ausgeben.

Per-Button-Overrides mit Data-Attributen

Die Klasse entscheidet das Event. Vier optionale data-bcnr-*-Attribute entscheiden die Payload, pro Element, sodass zwei Buttons, die sich eine Klasse teilen, trotzdem unterschiedliche Werte und Katalog-IDs tragen können.

Beispiel, ein Checkout-Button, der an Polar übergibt und jedem Kanal genau mitteilt, was gekauft wurde und zu welchem Preis:

Dieser eine Klick versendet ein begin_checkout an GA4 mit einem Ein-Item-items[]-Array, ein InitiateCheckout an Meta mit content_ids: ["studio-tier"] und Wert 149 USD, und das passende Event an jeden anderen verbundenen Kanal. Der sichtbare Text des Buttons wird als kurzes Label erfasst (auf 100 Zeichen gekürzt) für die Spalte "Source" im Live-Dashboard, und wenn das Element ein <a> ist, wird auch sein href festgehalten, sodass du im Dashboard sehen kannst, von welchem ausgehenden Link eine Conversion kam.

Alle vier Attribute sind optional. Lass sie weg und der Klick feuert trotzdem, mit dem Per-Slot-Default-Wert und der Währung, die du im Tracking-Tab gesetzt hast (oder Wert null ohne Katalog-Daten, falls du nie eines gesetzt hast). Am wichtigsten sind sie für die Checkout- und Lead-Slots, wo ein Wert für ROAS-Bidding wirklich nützlich ist; ein schlichter Kontakt- oder CTA-Klick ist oft ganz ohne Wert in Ordnung.

Wie man es aktiviert

Click-Tracking ist standardmäßig aus. Schalte es ein unter wp-admin, Beaconry, Tracking, Click-Tracking-Karte. Auf dieser Karte setzt du die globalen Defaults, die greifen, wenn ein Element kein data-bcnr-*-Override hat:

• Eine Default-Währung für alle Klick-Events.
• Ein Default-Wert pro Slot: je einer für Checkout, Lead, Signup, Kontakt und CTA. Lass einen Slot auf null, wenn diese Klicks keinen Geldwert zuzuweisen haben.

Speichern, und ab dem nächsten Seitenaufruf hängt Beaconry einen einzelnen delegierten Klick-Listener an das Dokument. Es gibt nichts, was du deinem Theme über die CSS-Klassen selbst hinaus hinzufügen müsstest, und nichts, was du in einzelne Buttons einfügen müsstest, es sei denn, du willst ein Per-Button-Override.

Wie es unter der Haube funktioniert

1. Ein delegierter Listener. Wenn das Feature aktiviert ist, registriert die Browser-Engine (nl-data.js) einen einzelnen Klick-Listener auf dem Dokument und löst den nächsten Vorfahren auf, der zu einer der fünf Klassen passt, via closest(). Ein Listener für die ganze Seite, nicht einer pro Button, sodass das Hinzufügen markierter Elemente später (oder ihr dynamisches Rendern) einfach funktioniert.
2. Klasse zu Event. Die gematchte Klasse wählt den GA4-Event-Namen und den Default-Wert-Slot. Data-Attribute, falls vorhanden, überschreiben Wert, Währung, Content-ID und Content-Name oben auf den Tracking-Tab-Defaults.
3. Zustellung via sendBeacon. Das Event wird mit navigator.sendBeacon() an den Same-Origin-REST-Endpoint geschickt. Das ist speziell fürs Click-Tracking wichtig: Die meisten markierten Klicks sind ausgehende Links, die sofort wegnavigieren, und ein normales fetch würde von der Navigation abgebrochen. sendBeacon übergibt die Anfrage dem Browser, der sie im Hintergrund sendet, sodass die Conversion das Verlassen der Seite überlebt.
4. Standard-Server-Side-Fan-out. Auf dem Server läuft das Event durch genau denselben BCNR_Forwarder-Dispatch wie alles andere, sodass es PII-Handling, das Consent-Gate, Multi-Currency-Normalisierung, das Per-Kanal-Event-Name-Mapping und den Live-Dashboard-Recorder erbt. Es existiert kein kanalspezifischer Klick-Code; ein neuer, zu Beaconry hinzugefügter Kanal nimmt Klick-Events automatisch mit.
5. Hybrid-Mirror. Wenn du Hybrid Mode für einen Kanal fährst (sein Browser-Pixel ist fürs Audience-Building geladen), feuert die Engine das passende Standard-Event auch auf diesem Pixel mit derselben event_id, die der Server benutzt hat, sodass der Vendor die Browser- und Server-Kopie dedupliziert. LinkedIns Insight Tag und Google Ads gtag.js haben keinen nutzbaren client-seitigen Conversion-Call, daher bekommen sie den Klick nur server-seitig. Siehe Hybrid Mode.

Keine Doppelzählung mit Auto-Events

Beaconrys Browser-Engine feuert bereits generische Engagement-Events für ausgehende Links und CTA-artige Klicks. Wenn Click-Tracking an ist, erkennt die Engine, dass ein geklicktes Element eine Beaconry-Klasse trägt, und unterdrückt ihr eigenes generisches Outbound- / CTA-Auto-Event für diesen Klick, sodass ein markierter Button genau ein Event erzeugt (die Click-Tracking-Conversion) und nicht zwei. Du kannst einen Link markieren, den die Engine sonst auch als generischen Outbound-Klick geloggt hätte, ohne dir Sorgen um ein Duplikat zu machen.

Der Kill-Switch (wp-config)

Für Power-User und geteilte Datenbanken gibt es ein hartes Override. Definiere das in wp-config.php:

Wenn die Konstante gesetzt ist, gewinnt sie zur Lesezeit über den DB-Toggle, genau wie Beaconrys andere Konstanten-Overrides. Der klassische Anwendungsfall ist eine Staging-Site, die sich die Produktiv-Datenbank teilt (oder von ihr geklont wurde): Produktion hat Click-Tracking in der DB aktiviert, aber du willst nicht, dass Staging echte Conversions in deine Werbekonten feuert, also setzt du die Konstante in Stagings wp-config.php auf false und das ganze Feature ist dort aus, egal was die geteilte Option sagt. Setze sie auf true, um auf dieselbe Weise zwangsweise zu aktivieren.

Wann man es einsetzt (und wann nicht)

Click-Tracking ist das richtige Werkzeug, wenn die Conversion ein Klick auf etwas ist, das Beaconry nicht server-seitig hooken kann. Greif danach für:

• Ausgehende Links zu einem externen Checkout oder Affiliate, wo der Kauf abseits deiner Domain abschließt.
• Buttons, die ein Drittanbieter-Widget öffnen (Booking, Chat, Rechner) ohne ein WordPress-Formular dahinter.
• Click-to-Call-, mailto- und Messaging-Links, die du als Kontakte zählen willst.
• Jeden High-Intent-CTA, bei dem der Klick selbst das Signal ist, auf das du hin optimieren willst.

Es ist das falsche Werkzeug, wenn bereits ein dedizierter Hook existiert, weil der Hook genauer ist. Konkret:

• Native Formulare: nutze die Form-Adapter. Sie feuern beim echten Submit (ein Klick auf einen Submit-Button ist kein Submit, der User könnte noch an der Validierung scheitern), und sie hashen erkannte PII für Match-Qualität, was ein Klick nicht kann.
• WooCommerce, EDD oder SureCart: nutze den Commerce-Funnel. Ein echtes begin_checkout vom Commerce-Adapter trägt den tatsächlichen Warenkorb-Inhalt und -Wert; ein .beaconry-checkout-Klick trägt nur das, was du fest in Data-Attribute codierst.

Faustregel: Wenn es einen server-seitigen Hook für die Aktion gibt, bevorzuge ihn und halte Click-Tracking für die Klicks bereit, die sonst nirgends abgefangen werden können. Die zwei Ebenen kollidieren nicht, das Commerce-begin_checkout und ein Klick-begin_checkout sind eigenständige Events aus eigenständigen Quellen, aber für einen gegebenen Button willst du normalerweise das eine oder das andere, nicht beides.