Skip to content
SignalRelay

Architecture & Cache-Safe Deduplication

The Problem with Traditional Server-Side Tracking

On a typical WordPress site using full-page caching:

  1. Static HTML Caching: The server renders the HTML once and stores it on disk or in memory (WP Rocket, LiteSpeed, Cloudflare).
  2. ID Collision: If a plugin generates the event_id in PHP during page generation, that single ID is frozen into the cached HTML. Every subsequent visitor receives the exact same event_id.
  3. Lost Conversions: When two different visitors submit a form on the cached page, Meta sees the duplicate event_id and discards the second real conversion as a duplicate.
[ Visitor A ] ──▶ Loads cached page (event_id: "xyz-123") ──▶ Submits Form ──▶ Meta records Lead
[ Visitor B ] ──▶ Loads cached page (event_id: "xyz-123") ──▶ Submits Form ──▶ Meta DISCARDS (Duplicate) ❌

SignalRelay Solution: Client-Generated event_id

SignalRelay decouples ID generation from server page rendering:

[ Visitor A ] ──▶ JS generates unique event_id "sr_a98f..." ──▶ Server dispatches CAPI with "sr_a98f..." ──▶ Meta Accepts ✅
[ Visitor B ] ──▶ JS generates unique event_id "sr_b44c..." ──▶ Server dispatches CAPI with "sr_b44c..." ──▶ Meta Accepts ✅
  1. Client-Side Generation: The lightweight tracking.js script generates a unique cryptographic UUID v4 for each event at the exact instant an action occurs.
  2. Dual-Channel Dispatch: The same event_id is passed simultaneously to the browser pixel (fbq('track', 'Lead', {...}, {eventID: id})) and to the local SignalRelay REST endpoint (/wp-json/signalrelay/v1/event).
  3. Server-Side Delivery: Your WordPress server receives the payload, verifies user consent, hashes customer data with SHA-256, and dispatches the conversion to the official API.
  4. Accurate Deduplication: Meta, TikTok, and Pinterest merge both signals using the matching event_id, maximizing your Event Match Quality (EMQ) without double counting.