Check browser and server event duplicates before trusting campaign revenue

Sending an event from both a browser and a server can produce misleading totals if the implementation does not identify the same business event consistently. Ask for a duplicate test before using the report to increase spending.

Start with one real event identity

Define which order or payment outcome the event represents. Then identify the stable reference both delivery paths should use. A new random identifier on every retry may describe delivery attempts rather than the underlying purchase.

The exact deduplication mechanism depends on the receiving platform. Require the implementer to use its current documentation rather than assuming all providers use the same fields.

Separate retries from new business activity

A network retry is not another order. A thank-you-page reload is not another payment. A second product purchase genuinely is a different event. Put those cases into the acceptance test.

The test should check the provider's received result as well as the local code. A console message saying sent does not establish how the report counted it.

Reconcile a controlled sample

Use authorised test events or a safe test environment. Record the expected business outcomes, the browser sends, the server sends and the resulting counted events. Keep personal information out of the evidence.

If two sends produce one counted purchase, retain that proof. If they produce two, fix the identity or event-boundary problem before scaling campaigns.

Check amounts independently

Duplicate prevention does not establish that the revenue amount is correct. Compare currency and the treatment of delivery, discounts and refunds with the reporting definition.

A dashboard can have the correct event count and still report a misleading value. Do not let one successful test stand in for the entire measurement contract.

Own the ongoing check

Record who maintains the integration and what changes should trigger a re-test. Checkout changes, new payment paths and tag-manager edits can all affect the event boundary.

This guide does not claim oBizee has every browser/server integration or that a particular provider guarantees exact attribution. Use the campaign budget tool only after the contribution and order assumptions behind your spending decision are understood.

Illustrative case to check

In a test, one order produces a browser send and a server send, followed by a retry of the server request. The expected business count is still one if all three represent the same outcome. Record the provider result and identifiers using its documented mechanism. If the total becomes three, stop using that report for spending decisions until the implementation is corrected.