Meta-Pixel + Conversions API mit Beaconry: Pixel-ID und Access-Token in einem Screen

Meta ist der Kanal, in dem Beaconrys Match-Rate-Arbeit am sichtbarsten ist. Server-Side-CAPI-Dispatch mit gehashter PII out of the box, optionaler Hybrid-Modus für fbp/fbc-Cookies, Dedup via stabiler event_id. Match Quality klettert von "Poor" auf "Good" in einer Woche.

Setup, vier Schritte

1. Access-Token generieren. Events Manager → Settings → Conversions API → Set up direct integration. Vor dem Kopieren "Expires: Never" verifizieren. Langlebiger System-User-Token, gescopet auf einen Pixel.
2. In Beaconry einfügen. Tracking → Meta. Pixel-ID + Access-Token, speichern. Verschlüsselt im Ruhezustand mit AES-256-CBC.
3. Test-Event senden. Der Button feuert ein synchrones ViewContent via CAPI. HTTP 200 = Credentials passen. Mit gesetztem Test-Event-Code landet das Event in Test Events; sonst live.
4. Events fließen automatisch. PageView, ViewContent (50 % Scroll + 10 s), Lead (Kadence-/Fluent-Forms), AddToCart / InitiateCheckout / Purchase / Refund (WooCommerce). Alles mit gehashter PII und stabiler event_id.

Was gehasht und gesendet wird

Bei jedem Event baut Beaconry das user_data-Objekt zusammen, das Meta erwartet:

• em: SHA-256 der lowercased E-Mail.
• ph: SHA-256 der nur-Ziffern-Telefonnummer mit Ländervorwahl.
• fn, ln: SHA-256 der lowercased Vor-/Nachnamen.
• ct, st, zp: Stadt, Bundesland, PLZ, lowercased und gestrippt.
• fbc: gebaut aus fbclid + Landing-Timestamp, im nl_ext für 90 Tage persistiert.
• fbp: nur gesendet, wenn Hybrid-Modus an ist und der Browser-Pixel das Cookie gesetzt hat.
• client_ip_address, client_user_agent: Server liest sie aus dem Request, Meta hashed sie.
• external_id: WooCommerce-Customer-ID für eingeloggte Käufe. Leer für anonyme.

Das Hashing folgt Metas Matching-Vorgaben exakt. Fehlende Felder werden einfach weggelassen; Metas Algorithmen bestrafen fehlende Felder nicht, sie nutzen nur, was sie bekommen.

Hybrid-Modus, wann aktivieren

Für Meta speziell zahlt sich Hybrid-Modus stärker aus als bei den anderen Kanälen, weil Metas Match-Rate ungewöhnlich sensitiv für First-Party-Cookies ist. Aktivieren wenn:

• Deine Zielgruppe ist überwiegend Retail-Mainstream (niedrige Adblock-Quote).
• Match Quality liest aktuell "OK" oder "Good" und du willst auf "Great" pushen.
• Du fährst große Smart-Bidding-Kampagnen, in denen Match-Rate direkt den ROAS treibt.

Überspringen, wenn die Adblock-Rate >30 % ist (B2B, Dev). Der Hybrid-Pixel wird eh geblockt, du behältst den Server-Side-Pfad, kein Vorteil gewonnen aber +30 KB ausgeliefert.

Test-Event-Code, der Staging-Flag

Beaconry hat ein "Test Event Code"-Feld im Meta-Channel-Setup. Solange gesetzt, wird jedes Event mit test_event_code getaggt und an Events Manager → Test Events geroutet, statt live zu gehen. Nützlich für Staging-Umgebungen, wo du die Pipeline verifizieren willst, ohne das Production-Reporting zu verseuchen.

Kritisch: Test-Code vor dem Launch entfernen. Live-Conversions, mit Test-Code getaggt, erscheinen nicht in Metas Standard-Reporting, was heißt, Smart-Bidding optimiert nicht auf sie. Wir haben mehrere Kunden mit noch gesetztem Test-Code in Production gehen sehen; Symptom ist "Meta sagt null Conversions, obwohl wir wissen, dass wir Bestellungen haben". Das zuerst checken.

Was du in Meta noch konfigurierst

• Domain-Verifikation in Business Settings → Brand Safety → Domains.
• Trusted-Domains-Liste auf dem Pixel → Settings → Traffic Permissions.
• Aggregated-Event-Measurement-Prioritäten, gerankt Purchase > SubmitApplication > Lead > ViewContent.

Keines davon ist Beaconry-spezifisch; das ist Meta-seitige Konfiguration, die jedes CAPI-Setup braucht. Beaconry kann das nicht für dich tun, weil es ein Meta-seitiges Login verlangt.

Fazit

Meta ist der Höchst-ROI-Kanal für Server-Side-Dispatch. Beaconrys Setup sind zwei Strings (Pixel-ID + Token) plus optionaler Test-Event-Code, der Rest ist automatisch. Match Quality klettert von "Poor" auf "Good", sobald Domain-Verifikation auch da ist; von "Good" auf "Great" mit Hybrid-Modus und AEM-Prioritäten.