One store order, one event sent by the browser and another by the server. Two copies are not inherently an error. Trouble starts when the integration cannot recognize them as the same action. That is why acceptance testing must cover event identity, beyond a successful connection.
Events API sends events from systems to TikTok. When overlapping copies of the same action are sent through the API and Pixel, TikTok requires event_id on both paths for deduplication. Also check event-name consistency and current matching requirements. [1]
1. Agree an event specification with the developer
Define when a purchase occurs in your system, its event name, who generates its ID, value, currency and action time. Reloading a page or changing an order note should not create a new purchase identity for the same transaction.
Check names and parameters against TikTok’s standard events. If the business distinguishes order placement from completed purchase, reflect that in the map. Renaming a report cannot repair an incorrect business definition. [2]
2. Test both paths and retries
Start with browser-only, then server-only, then one action delivered through both. Compare name, ID, time and value; document how the copies were handled under the integration documentation.
Next test a temporary delivery failure and an appropriate retry. Another attempt is not another purchase: the integration must preserve action identity. Incorrect value or currency requires correcting the data, not repeatedly sending the bad copy.
Practical example: an integration acceptance log
The developer and measurement specialist complete these hypothetical cases in an authorized test environment.
| Scenario | Check objective | Suggested acceptance evidence |
|---|---|---|
| One action through two paths | Test deduplication | Documented explanation of how both copies were handled |
| Retry | Preserve action identity | Delivery log distinguishing attempt from order |
| Incorrect value | Detect a meaning error | Rejection or diagnostic status and corrective action |
| Simulated delay | Understand freshness and acceptance limits | Action time, delivery time and outcome |
| Action not authorized for sharing | Review sharing controls | Not sent, as required by the approved design |
Add the actual outcome, internal evidence link and remediation owner to each row. “The API works” is insufficient. Trace the case from the order system through delivery and diagnostics without confusing attempts with orders.
Keep access tokens and customer data out of shared logs. Use test IDs; retain investigation data under agreed access and retention policies.
3. Read diagnostics alongside source logs
Web Diagnostics provides issue details, severity and the affected dataset. Connect each alert to a logged case: did the problem arise in event creation, transformation or delivery? That identifies the owner and what must be retested. [3]
Check the delay between action and delivery. Do not replace purchase time with retry time to make the record appear recent. Agree how persistent failures will be handled rather than leaving them unmonitored.
4. Separate integration acceptance from impact evaluation
Passing agreed cases confirms those tests passed; it does not prove increased sales. Better coverage may change attributed figures, so distinguish measurement effects from commercial evaluation.
Deliver an event map, test log, operating owner and rollback plan. Do not automatically disable Pixel because the API passed, or treat server-side delivery as a substitute for data-sharing controls. Decide according to the paths, permitted data and business need.
Official sources
Source documentation reviewed: 16 October 2026. Features and eligibility may change; check the linked documentation before implementation.
