TikTok Events API Explained: Server-Side Events and Deduplication
You already run the TikTok Pixel. Orders happen in your store, yet TikTok reports fewer than you can see in your own records. The question is whether to add the Events API, and what you risk if you add it carelessly.
The risk is real. A second data path can complete your picture, or it can report every purchase twice. Which one you get depends on a single field.
What the Events API is
The Pixel is code in your visitor's browser. The Events API is a server-to-server connection: your store, your server or a connected tool sends events to TikTok directly. TikTok's own documentation describes it as working alongside the Pixel, and it covers sources beyond a website, such as apps, offline sales and CRM systems.
For an online store the practical meaning is simple. An event no longer depends on a script surviving in the browser. It can be sent from the order record, at a moment you choose.
Why running only the Pixel falls short
A browser event can fail for ordinary reasons: a blocked script, a closed tab, a slow connection, a consent choice. When that happens the order exists in your store and is missing in TikTok. The campaign then looks weaker than it is, and the platform learns from fewer real purchases.
The usual reaction is to switch on the server path as well, without planning how the two paths will be reconciled. That is how stores end up with inflated counts.
- Browser PixelFires in the visitor's browser
- Events APISent from your server or a connected tool
If only one path arrives, it is counted alone. If both arrive with matching fields, they merge.
The deduplication rule
TikTok's help article on event deduplication says you need to share the same `event_id` through both the Pixel and the Events API. The two events must also carry the same event name and the same pixel ID. Deduplication applies to overlapping events, so it matters when both paths report the same action, not when they report different ones.
The practical consequences:
- Create the ID once per action, then pass that exact value to the browser event and to the server event. For a purchase, the order number is a stable choice.
- Do not let each path invent its own random ID. Two different IDs look like two different purchases.
- Keep event names identical on both paths. `CompletePayment` on one side and a differently named event on the other will not pair.
- TikTok also describes a first-party cookie, `_ttp`, as recommended for matching. Check the current documentation for how it is used.
The same logic applies on Meta, and the article Duplicate Purchase Events: Causes and How Deduplication Works explains the failure pattern in more depth.
A worked example
The bar for 360 is capped at full width. It is 180% of real orders.
Take a store with 200 real orders in a week. Suppose the Pixel catches 164 of them and the server sends 196. In that case 160 orders arrive on both paths, 4 only in the browser and 36 only from the server, so 160 + 4 + 36 = 200.
- With matching event IDs, TikTok can merge the overlap and the count lands near 200.
- With mismatched IDs, it receives 164 + 196 = 360 purchases, which is 180% of reality.
Now put spend on it. At an average order of 150 SAR and 6,000 SAR of ad spend, 200 orders give a revenue-to-spend ratio of 30,000 / 6,000 = 5.0. The inflated 360 gives 54,000 / 6,000 = 9.0. Nothing about the campaign changed; only the counting did. A number like 9.0 would push you to scale on a result that does not exist.
Trade-offs and when the advice changes
- Low volume. If you sell a handful of orders a week, the gap from lost browser events is small in absolute terms. A lighter setup may be enough, and the effort is better spent elsewhere.
- Platform integration or custom build. Store platforms and tag tools may offer a TikTok integration that sends server events. Check what it actually sends and whether it shares an event ID with your Pixel before you trust it. A custom build gives control and costs maintenance.
- Different events on each path. If the Pixel sends page and cart events and the server sends only purchases, there is little overlap and less to deduplicate. Decide this on purpose, not by accident.
- Cash on delivery. An order placed is not an order delivered. The server path lets you send the purchase later, after confirmation. Whether that suits your campaign is a separate decision from the technical setup.
- Consent. Sending from a server does not remove your obligation to respect the visitor's choice. Confirm what applies to you with the relevant authority or adviser.
Implementation steps
- List the events your Pixel already sends, using the checks in TikTok Pixel Setup for E-commerce: Events, Parameters and Checks.
- Decide which events the server will also send. Start with purchase.
- Choose where the event ID is created, once, and make both paths read it.
- Send value, currency and the customer details TikTok documents, following its hashing and formatting rules.
- Test with TikTok's event testing tools and confirm each test action appears once.
- After a week, compare TikTok's purchase count with your order records. Expect some difference; investigate if the Ads Manager count is higher than your real orders.
What the data cannot tell you
A clean deduplicated count tells you that TikTok recorded the purchase. It does not tell you that TikTok caused it. Attribution windows, views, and customers who also saw other ads all remain. Server events improve completeness, not proof of cause. For the wider reconciliation problem see Why Your Store Sales Don't Match Meta and Google Ads, and for the Meta equivalent of this setup read Meta Conversions API Explained.
Next step
Open your TikTok event reporting and your store's order list for the same week. If the two counts disagree in either direction, check event IDs before touching the campaign. If you want the browser path, the server path, deduplication and testing set up and verified together, the tracking setup service covers exactly that chain.