One purchase, three systems: how to test the conversion loop
Follow a conversion from the store or network through your tracker to an ad platform, with practical checks for identity, duplicates and delivery.
The store has an order. The tracker has a conversion. The advertising platform shows a different number. Which system is wrong?
You cannot answer that from the totals alone. They may be counting different events, using different dates or attribution rules, or receiving different copies of the same event. Start with one transaction and follow it through the full loop.
A postback is a message that brings an event from a destination or partner into your tracking workflow. An outgoing conversion API request reports an eligible event to an advertising platform. The first message succeeding does not establish that the second one succeeded, or that the platform attributed the event to an ad.
Key takeaways
- A postback is a message that brings an event from a destination or partner into your tracking workflow.
- Give each identifier one job: the visit or click ID, the transaction ID and the outgoing event ID.
- An accepted API request is not campaign attribution; check the platform’s diagnostics after confirming transport and content.
- Retries are normal. Resend the same test event and keep its transaction identity instead of inventing a new one.
Give each identifier one job
Record the visit, the transaction and the outgoing event as three separate identities. Consider a fictional order for $84. A visitor clicks an ad, reaches a store and completes checkout. The store later sends a purchase notification.
There are at least three identities worth recording:
| Identifier | What it identifies | Example |
|---|---|---|
| Visit or click ID | The originating tracked visit | visit_7K2 |
| Transaction ID | The store or partner’s business transaction | order_1042 |
| Outgoing event ID | The event reported to an advertising destination | purchase_order_1042 |
These values may be related, but they are not substitutes for one another. A person can buy twice after a visit. A store can retry the same notification. A browser pixel and a server integration can both describe the same purchase.
Define how the identities connect before testing. The transaction should remain the same transaction when it is retried. A second legitimate order should have its own identity. Where browser and server events overlap, use the destination platform’s documented deduplication requirements.
The identifiers above are illustrative. Use the actual fields and identity rules required by your connected store, network and advertising platform.
Agree on what “conversion” means
Agree a written definition for each event before testing; these systems use the same word for different things. An affiliate network may report a lead before approval. A store may create an order before payment completes. A subscription service may send an initial payment and later renewals. Mapping all of those to “Purchase” makes the reporting easier to configure and harder to trust.
Write an event mapping that names the business fact. For example: a submitted form becomes a lead; a confirmed payment becomes a purchase; a rejected application does not become an approved lead. Decide separately whether a renewal is included in the campaign’s acquisition metric.
For each event, agree on its time, amount and currency. In this example, $84 is the stated value of a fictional order; it is not automatically an affiliate payout, net revenue or profit. If the partner returns commission instead of order value, label and map that amount accordingly.
Also decide how later changes are represented. A cancellation is not another purchase. Your store, tracker and advertising destination may support different correction workflows, so confirm the relevant integration behaviour before assuming a changed status will undo an earlier event everywhere.
Follow one transaction through four checkpoints
For a test order, create a short record at each checkpoint:
- At the destination: the transaction exists with the expected business status, amount, currency and event time.
- At the receiving endpoint: the actual message arrived, carrying the expected visit and transaction references.
- In the tracker: the message was interpreted as the intended event and associated with the intended visit, where attribution is possible.
- At the advertising destination: the outgoing event received a provider result, and its diagnostics show the expected event where the platform exposes that evidence.
This separates receipt, interpretation and delivery. It also gives you somewhere specific to look when a number disagrees.
If the store has the order but no incoming message exists, inspect the store’s event configuration and delivery record. If the message arrived with an unknown visit reference, inspect the parameter round trip. If the tracker has the event but the provider rejects it, inspect the outgoing mapping and provider response.
Keep API acceptance separate from campaign attribution. A destination can receive an event without crediting the ad you expected. Investigate its attribution rules and diagnostics after confirming the transport and event content.
Make retries part of the test
A delivery retry is normal behaviour in distributed integrations. Stripe, for example, documents automatic webhook retries, possible duplicate events and a lack of guaranteed event ordering. Those are Stripe’s specific delivery characteristics; check the equivalent documentation for your own sender. See Stripe’s webhook delivery guidance.
For your integration, resend the exact same test event through the supported test mechanism. Verify the result against the configured repeatability policy. Then send a genuinely different transaction for the same visit and verify that it remains distinct if your business model allows repeat purchases.
Do not generate a new transaction ID simply because a request timed out. A timeout tells the sender that it did not observe a response. It does not establish whether the receiver processed the message. Changing the identity can make a retry look like another business event.
Likewise, do not deduplicate all events from the same visit without considering their meaning. A lead followed by a purchase is not the same event twice. Two purchases with separate transaction identities may also be legitimate.
Browser and server deduplication needs its own check
Preventing duplicate incoming postbacks and preventing duplicate events at an advertising platform are separate tasks.
If a website pixel and a server integration both report a purchase, they need an agreed identity for that purchase. TikTok explicitly requires a shared event_id for overlapping Pixel and Events API events and documents its matching rules. See TikTok’s event deduplication documentation.
In a test, capture both representations of the same purchase. Compare the event identity and type against that platform’s requirements. Then inspect the platform’s diagnostics; sending two requests is not itself evidence that the platform counted one event.
Audit every sender you have enabled. A store plugin, a tag manager and a custom server integration can overlap. Document which one owns each event so a later installation does not silently introduce another copy.
Use a test matrix that can fail usefully
A single successful purchase proves only one path. A compact matrix is more informative:
| Case | Expected result to verify |
|---|---|
| Valid first purchase | The intended event is associated and forwarded as configured |
| Exact retry | No additional purchase under the chosen deduplication policy |
| Second order, same visit | A separate purchase when repeat transactions are supported |
| Missing or unknown visit reference | No invented attribution to an unrelated click |
| Unmapped partner status | No accidental mapping to a valuable conversion |
| Provider rejection | A visible delivery problem rather than an assumed success |
Use supported sandbox or test-event facilities. Keep test transactions identifiable and avoid mixing them with live campaign performance.
When the matrix passes, keep the evidence with the integration configuration: the visit reference, transaction reference, mapped event, outgoing identity and provider result. The next time totals disagree, choose one real transaction and repeat that trace. You will know whether you are investigating missing data, duplicate data, a mapping decision or attribution, instead of treating all four as the same problem.
Frequently asked questions
What is a postback URL?
A postback is a message that brings an event from a destination or partner into your tracking workflow. An outgoing conversion API request reports it to an advertising platform.
Why does my ad platform show fewer conversions than my store?
They may count different events, use different dates or attribution rules, or receive different copies of one event. Follow a single transaction through the four checkpoints instead of comparing totals.
Should a retried webhook get a new transaction ID?
No. A timeout tells the sender it did not observe a response; it does not establish whether the receiver processed the message. Changing the identity makes a retry look like another business event.
Related
- Postback Builder: build a callback template with click ID and status.
- Postback Inspector: review postback fields and unresolved macros before sending.
- Affiliates: map network statuses to your own conversion types.
- Auditing campaign parameters: check the visit identifier before the conversion returns.
- Testing browser handoff: test how the visitor reached the destination.