Conversions API best practices
Everything below is what Meta and TikTok tell you to do in their own documentation, quoted, with what it means for a node in n8n. None of it is enforced by either API: you can ignore all of it and still get a success response back, which is exactly why it is worth writing down.
Reference: Meta Conversions API best practices, Meta customer information parameters, TikTok web events
Send events when they happen
Sharing events when they happen can help your campaigns achieve the best results.
Meta, Conversions API best practices
Meta accepts events in real time or "in batches close to real time". There is a hard limit at the far end: an event_time more than 7 days old makes Meta reject the whole request, not just that event.
In n8n:fire the node from the event itself, a webhook on your thank-you page or your CRM, rather than a nightly cron over yesterday's rows. If you are backfilling, keep Event Time mapped to when the conversion actually happened, not to now: a batch of correct timestamps is better attributed than a batch that claims everything happened at 3am.
Batching is not the same as delaying
Meta's Batch Events option groups events into one request. It does not hold them back. Turn it on for bulk loads, and leave it off for webhooks, where it saves nothing and costs you the ability to see which single event failed.
Deduplicate against the pixel
If you run the browser pixel and the Conversions API for the same conversion, which Meta calls a redundant setup, you must tell Meta the two are the same event or it counts them twice.
ensure that both events use the identical
Meta, Conversions API best practicesevent_nameand that eitherevent_idor a combination ofexternal_idandfbpare included
TikTok is the same shape: event_id is "required if you are sending overlapping events from both TikTok Pixel and Events API".
In n8n: map Event ID to whatever your pixel sends as its eventIDfor the same conversion, most often an order ID. Note the trap in Meta's wording: identical event name. A pixel firing Purchase and a node sending purchase are two different events to Meta, and both will be counted.
Leave Event ID empty and the node generates one from the execution ID. That keeps a retry from double-counting itself, but it will never match your pixel's ID, so it does not deduplicate the redundant setup. It is a fallback, not a solution.
Send every identifier you have
Meta scores how well your events match real people, and says plainly that more customer information raises it:
Higher matching quality produces better results.
Meta, Conversions API best practices
Meta's floor is one identifier: "You must provide at least one of the following user_dataparameters with the correct formatting in your request". One is the minimum, not the target.
TikTok says the same thing in its own words:
To increase the probability of matching website visitor events with TikTok ads and improve your ads performance, we recommend as much information as possible.
TikTok, Report a Web Event
In n8n: map every identifier your payload carries, not just email. The click IDs are the strongest of them, because they tie the event to an actual ad click rather than to a guess about a person: Fbc for Meta, Ttclid for TikTok. If you have no Meta pixel setting _fbc, pass the fbclid from the landing URL and the node formats it.
Empty fields cost you nothing here. The node omits anything that resolves to empty rather than sending a hash of an empty string, so mapping a field that is sometimes present is always better than not mapping it.
Always send IP and user agent
Sending both the
Meta, customer information parametersclient_ip_addressandclient_user_agentparameters for all of the events you're sending through the Conversions API may help improve event matching and could also help improve ad delivery.
TikTok goes further and calls its whole context object "Required to attribute events to TikTok campaigns", adding: "When there's no pii information available, you can send us both ip and user_agent".
In n8n: these are the two people forget, because a server-side workflow does not have them lying around the way a browser does. The browser knows both; your workflow only knows what the request carried to it. So they have to survive the trip: captured at the source, included in whatever hits your webhook, and mapped into Client IP Address and Client User Agent. If the payload never carried them, no mapping can invent them.
Not your server's IP
Meta: "Always provide the real IP address to ensure accurate event reporting." If your workflow sits behind a proxy, the client IP is the first entry of X-Forwarded-For, and the node reduces a chain to that. Sending your own server's IP for every event tells Meta every one of your customers is the same person in a datacentre.
Never send unhashed personal information
Our systems are designed to not accept customer information that is unhashed Contact Information
Meta, customer information parameters
Meta is blunter elsewhere: "If you are not planning to use the Business SDK, implement hashing." TikTok requires the same: email, phone and external ID "must be hashed with SHA256 on the client side".
In n8n:this is the node's entire job, and the reason to map raw values rather than hash them upstream. The rules are not the same on both platforms, and getting them wrong is invisible: the same US phone number must hash as 12133734253 for Meta and +12133734253 for TikTok. See TikTok's phone rule.
If your data is already hashed upstream, map it anyway. The node detects a SHA-256 digest and passes it through untouched rather than hashing it twice, which would destroy the match.
Be honest about action source
Meta asks you to agree that action_source "is accurate to the best of your knowledge". It is a declaration, not just a field.
In n8n: it also has to match the dataset. An offline event set will not show website events: Meta accepts the request, answers events_received: 1, and counts the event as a real conversion instead of a test. If your events vanish, this is the first thing to check.
Measure match quality, not responses
Meta scores every web event out of 10 for "how effective your server event's customer information may be at matching it to a Facebook or Meta account". That score, in Events Manager, is the only honest feedback either platform gives you.
| Signal | Tells you |
|---|---|
events_received: 1 / code: 0 | The request parsed. Nothing more. |
| Event appears in Test Events | It reached the right destination, with the right test code |
| Event match quality | Your identifiers are actually matching real people |
| Conversions in Ads Manager | It worked |
Event match quality is the one to watch over time. It is also the number that moves when the advice on this page is followed: send it live, deduplicate it, map every identifier, include IP and user agent, and let the node do the hashing.
Meta Conversions API and TikTok Events API each cover verifying a setup before you trust it.