Server-side fan-out & deduplication

When the tag sends a batch to /v1/ingest, the PixelFox backend enriches each event (geo-IP, user agent, identity) and fans conversions out server-side to your configured destinations. Server-side delivery is more reliable than browser pixels alone: it survives ad blockers, flaky networks and tab closes.

The event_id contract

Every event the SDK creates carries a UUID (uuid on the wire). That one value is the deduplication key across the whole system:

                        browser
  signals.track() ──┬──────────────► fbq("track", …, { eventID: uuid })
                    │                ttq.track(…, { event_id: uuid })
                    │
                    └► /v1/ingest ──► Meta CAPI      event_id: uuid
                        (backend) ──► TikTok API     event_id: uuid

Facebook and TikTok collapse a browser event and a server event that share the same id - you get the reliability of server-side delivery and the browser signals (cookies, click ids) that improve attribution, without double counting.

Why PixelFox injects the pixels itself

If (and only if) you configure Facebook CAPI or TikTok, the tag injects the matching browser pixel and fires it with the shared event_id. The injection is conflict-safe: when your site already runs its own fbq/ttq/gtag, PixelFox detects it and injects nothing - your existing setup wins and PixelFox only sends the server half.

The GA4 exception

GA4's Measurement Protocol has no event deduplication. PixelFox therefore treats browser gtag as the primary GA4 channel; server-side Measurement Protocol sending is a per-destination opt-in (send server-side) intended for server-only events like the WooCommerce/Laravel purchase helpers, where no browser event exists to collide with.

Which events fan out

Only conversion-grade events are forwarded to ad platforms - see the event property conventions for the mapped names (product_viewed, product_added_to_cart, checkout_started, purchase, …). Everything else still counts toward your dashboard rollups.

What PixelFox stores

Two stores, on purpose. A daily rollup per (event, destination) answers "how many" and stays cheap at any retention. A narrow per-event row (event name, visitor id, path, referrer, UTM, device class, truncated IP) answers the ordered, per-person questions - funnels, first/last-touch attribution, why a visitor stayed anonymous - and is pruned after 90 days. Neither holds the full property bag; see privacy for exactly what is kept.

Destination failures never block ingestion. Each vendor call has a 10-second deadline and is retried twice on network errors, timeouts, 429 and 5xx - safe because every payload carries the event id the platforms deduplicate on. A call that still fails is recorded, and the destination card shows the vendor's own error text plus how many events did not arrive in the last 24 hours.