This Conversions API field reference covers what Meta, TikTok, Snap, and Google each require at the parameter level, since getting a single field wrong is the most common reason server-side events arrive but don't match. Each platform defines its own required parameters, its own hashing rules, and its own identifiers for tying an event back to a real person. This is a field-by-field breakdown for implementers: what each platform needs, what's optional but valuable, and exactly how the hashing works.
What fields does Meta's Conversions API require?
For background on what Meta's Conversions API does before getting into field-level requirements: every server event needs three fields at minimum: event_name, event_time, and action_source. event_time is a Unix timestamp in GMT, and it can't be more than 7 days old or Meta rejects the entire batch. action_source tells Meta where the event originated: website for browser-based events, system_generated for CRM or backend events, physical_store for in-store, app for mobile. Website events also need event_source_url and client_user_agent.
Beyond the required three, user_data needs at least one identifier for Meta to match the event to an account. The two with the biggest impact on event match quality are a hashed email (em) and a hashed phone number (ph) in E.164 format. First name, last name, city, state, zip, and country round it out. external_id, your own customer ID, also gets hashed and helps Meta keep identity stable across sessions. client_ip_address is the one field that stays as plain text; hashing it breaks matching rather than protecting it.
For deduplication, pass the same event_id from both the pixel and the server event. Meta treats a browser and server event as duplicates if they share an event_id and arrive within 48 hours of each other, and it keeps whichever one it saw first.
What fields does TikTok's Events API require?
TikTok's Events API has its own required set: event (the event name), event_id, event_time as a Unix timestamp in UTC, and event_source_url for web events. The click identifier, ttclid, is captured from the URL when someone clicks a TikTok ad and stays valid for 30 days. It's the strongest signal TikTok has for tying a conversion back to a specific ad, stronger than any hashed identifier.
User data follows the same logic as Meta: hashed email, hashed phone number, and a hashed external_id all improve match quality, and TikTok expects the same normalization before hashing, lowercase and trimmed. TikTok's attribution windows are also tighter than they look: 28 days for click-through, 7 days for view-through. An event outside those windows won't attribute even if it's technically received.
What fields does Snap's Conversions API require?
Snap's Conversions API tracks four core events for most e-commerce implementations: Purchase, Add to Cart, Start Checkout, and Sign Up. Each one needs hashed identifiers, the more the better, since Snap's match rate climbs directly with how many identifiers it can connect to a user in its system. Deduplication works the same way as Meta and TikTok: a shared event ID between pixel and server events collapses two records into one.
Snap doesn't publish a heavily granular required-field list the way Meta does; the practical requirement is straightforward. Send the event, send hashed identifiers, send an event ID for dedup. The gap most implementations hit isn't a missing required field, it's an incomplete identifier set that leaves Snap with too little to match on.
What fields does Google's Enhanced Conversions require?
Google's Enhanced Conversions requirement is structured as an either/or: you need at least one of a hashed email, a hashed phone number, or a full address block. If you send the address, first name, last name, postal code, and country are mandatory; street, city, and region are optional extras that improve matching further. A phone number alone can also serve as a standalone identifier, though Google recommends pairing it with an email.
Normalization is stricter here than on the other three platforms. Before hashing, remove leading and trailing whitespace, lowercase everything, format phone numbers to E.164, and strip periods that appear before the domain in gmail.com or googlemail.com addresses, since Gmail treats firstlast@gmail.com and first.last@gmail.com as the same inbox. Skip a normalization step and the hash won't match Google's own hash of the same raw value, even though the underlying data is identical.
What normalization rules are shared across platforms?
Three rules show up in every platform's documentation: lowercase the value, trim whitespace, and format phone numbers in E.164 (a leading +, country code, digits only, no spaces or dashes). Miss any one of these before hashing and the resulting hash won't match what the platform computes internally, so the identifier is silently useless even though it was technically sent.
Frequently asked questions
Do I need to hash the same fields for every platform?
No. Meta, TikTok, and Snap treat client IP address and user agent as plain text; Google doesn't use IP or user agent as matching identifiers at all. Hashing a field the platform expects in plain text breaks matching just as badly as sending an unhashed field it expects hashed.
What happens if I send a pre-hashed value that wasn't normalized first?
The platform can't reverse a hash to check it, so a badly normalized hash is simply treated as a non-matching identifier. The event still arrives, but that field contributes nothing to match rate.
Which single field improves match rate the most?
A hashed email address, across all four platforms. It's the identifier most consistently present in checkout and lead flows, and every platform weights it heavily in its own version of a match quality score.
Field-level accuracy is unglamorous work, but it's the difference between a conversions API integration that looks complete and one that actually delivers usable signal. For a broader look at why that signal matters before you get to field mapping, see what a server-side event needs to be useful and how Meta's event deduplication works in practice.
If you'd rather not maintain four separate field mappings by hand, book a call and we'll show you how Journify handles the mapping and hashing automatically.
