Cross-Platform Conversion Parameters Matrix: One Event, Six Networks

Why One Conversion Needs Six Different Fields

The cross-platform conversion parameters that matter are the deduplication and click fields each network expects. When you route the same conversion to Meta, TikTok, Reddit, Snapchat, Pinterest, and Google Ads, each network ingests it independently and deduplicates it independently. Meta never asks TikTok whether a purchase was already counted; every platform collapses duplicates inside its own reporting using a key built from parameters you supply. The catch: the parameter name, the matching rules, and the deduplication window differ per network.

The practical failure mode is familiar to anyone running multi-network campaigns: the same order is fired to Meta and Snap with a single ID attached to only one of them, one network counts it twice, the other deduplicates a conversion it should have counted. A cross-platform conversion parameters matrix solves this by treating the ID assignment as a routing problem - one canonical conversion ID, translated into each network's expected field.

The conceptual model behind this is in event ID deduplication; this guide is the field-level map.

The Matrix

Two patterns emerge. Meta, TikTok, and Pinterest converge on the same field name - event_id - which makes them easy to feed from one payload. Reddit names its key after the thing it identifies: the recommended conversion_id method, with session-based dedup as the fallback when no ID is shared. Snapchat splits the concern: a general-purpose client_dedup_id for any event within 48 hours, and a transaction_id reserved for purchases with a much longer 30-day window. Google sits outside the event-stream pattern entirely: its transaction ID applies to conversions you import or adjust, documented as the way to minimize duplicate conversions. The Reddit-specific setup path, including the payload objects, is in the Reddit Conversions API setup; the failure side of every network is consolidated in CAPI error codes.

Snap's Two-Parameter System

Snap's Conversions API documentation is explicit about the two recommended parameters. client_dedup_id works for any event and opens a 48-hour deduplication window; it can be any string as long as it is unique per event and identical across every tracker reporting that event - Snap names Pixel, CAPI, and MMPs explicitly. transaction_id is eligible only for purchase events and opens a 30-day window; the two can be combined on a purchase.

For a routing pipeline the consequence is simple: a Snap-bound purchase should carry both fields, and the client_dedup_id value must equal what your Snap Pixel emitted for the same event - otherwise Snap treats browser and server reports as two different conversions.

A Single Conversion ID That Works Everywhere

The robust pipeline keeps one source of truth: the tracker or backend already assigns a unique order or lead ID. That value becomes the canonical conversion ID, and the delivery layer maps it per network:

Canonical ID: order-8842
  -> Meta:      event_id = "order-8842"     (+ same event_name on both channels)
  -> TikTok:    event_id = "order-8842"
  -> Pinterest: event_id = "order-8842"
  -> Reddit:    conversion_id = "order-8842"
  -> Snap:      client_dedup_id = "order-8842", transaction_id = "order-8842"
  -> Google:    transaction_id / order ID = "order-8842" (import and adjustments)

Two disciplines keep this honest. First, stability: the canonical ID is assigned once, at conversion time, and never regenerated - resending with a fresh ID turns one conversion into two on every network. Second, channel symmetry: wherever both a browser tag and a server call report the same event, both must carry the identical ID; that is the entire mechanism in Meta pixel and CAPI event deduplication and its TikTok twin in TikTok Events API delivery from trackers.

Click identifiers obey the same cross-platform logic with different names - Meta's fbclid (persisted in the _fbc cookie), TikTok's ttclid, Reddit's rdt_cid, Snap's ScCid - and they travel separately from deduplication keys. The _fbp browser ID is not a click identifier: it labels the browser, not the click. For the server-side context around this whole matrix, see server-side tracking versus browser pixels and the server-side tracking performance guide.

Automating the Matrix

The matrix is exactly the kind of rule set that humans eventually stop applying: a new landing launches, someone forgets the Snap client_dedup_id, and that network's reporting inflates silently. This is the problem MOST is built for - one postback in, correct per-network parameters out, with retries and deduplication handled per network. For a single landing and manual workflow, Pixel Activator applies the same parameter logic without code.

Before trusting any automated setup, validate per network: Meta's Test Events tool for Meta, Events Manager test events for TikTok, and the reconciliation habit from the postback troubleshooting checklist everywhere else.

Sources