Define a purchase event before installing another marketing tag

Before adding a pixel or analytics tag, decide what your business means by purchase. A submitted request, created order, successful payment and delivered order are not interchangeable events.

Draw the business sequence

Write the steps your store actually follows. A direct-payment order may exist before the merchant confirms receipt. A gateway flow may create an order before payment completes. A service request may still need acceptance.

Choose the event that each report is intended to count. Do not use a convenient button click as a substitute for a confirmed business outcome.

Specify the fields and their sources

Identify the order reference, amount, currency and product information that the event should carry. Record whether the amount includes shipping, discounts or tax. A number without its definition cannot be reconciled reliably.

Google Analytics documents recommended ecommerce events and their parameters. Use the current provider specification for the system you implement; this article is not an event-code recipe. GA4 event reference

Test unsuccessful paths too

A cancelled payment, validation failure or repeated page load should not accidentally count as a new completed purchase. Ask the implementer to demonstrate those cases in a controlled environment.

Do not create live charges or real customer records without authorisation. A test should prove the event boundary without becoming an unwanted business transaction.

Keep the reporting meaning visible

Name reports in a way that matches the event. If you measure order requests, call them requests. Calling them paid purchases can make campaign performance look better while hiding the collection work still required.

Also distinguish platform-reported attribution from the business's order ledger. They can differ for reasons that need investigation rather than automatic correction.

Install only after the definition is agreed

Give the implementer the event definition, allowed data and negative cases. Confirm privacy and consent requirements through the appropriate process before collecting visitor information.

The result should be one coherent measurement plan, not several tags each counting a different milestone as revenue. Use the order-workspace overview to keep the operational state distinct from marketing measurement. No native integration is assumed by this guide.

Illustrative case to check

A direct-payment customer submits an order and transfers funds later. If your report counts submission as paid revenue, it overstates what has been confirmed at that moment. Define separate milestones or label the existing event as an order request. The event plan should match the real business state, even if that makes the dashboard less immediately impressive.