All blog posts →

A purchase event appearing in GA4 does not mean that every order field was sent correctly. The event might arrive with no items. Its value might include delivery charges. Returning to the confirmation page might trigger it again. Start with the data for one test order rather than trying to explain the total event count first.

This article checks an existing purchase payload. If the base tag is not in place, start with our GA4 setup guide for Google Tag Manager. Tag configuration, dataLayer mapping and delivery tests are parts of a GA4 setup and consulting project.

Choose the order you are comparing

Choose a test order and note its identifier, products, quantities, item total and currency. Record shipping and tax separately where relevant. Then open the purchase payload for that same order. Before comparing the total in your order system with GA4’s value field, check which amounts each total includes. A difference can come from the calculation rather than a missing event.

Check what counts as a completed purchase, too. Clicking a payment button and successfully completing an order are different actions. A failed or cancelled payment should not produce a purchase event. Your development and marketing teams should use the same definition of the order status that confirms a purchase.

Keep one unique transaction ID per order

transaction_id distinguishes an order from other purchases. A new order needs a new identifier; processing the same order again should not change its identifier. Generating a random value on every page load can make one order look like several purchases. Reusing a fixed test identifier for all live orders can cause undercounting instead.

Google Analytics uses the transaction ID to deduplicate purchase records with the same identifier. Do not send an empty string or assign the same identifier to different orders or users. Keep email addresses, telephone numbers and other information identifying a customer out of this field. Replace real order and customer details with test values before sharing examples.

Read the items and amounts together

A purchase payload needs an items array. Each item must provide at least item_id or item_name; you can supply both. Check that product identifiers match the order source. Send prices and quantities as numbers. For example, the number 450 and the formatted text ‘450.00 TRY’ are different types of value for the price field.

value is the sum of price × quantity for the items, excluding shipping and tax. Send currency when you send value, using a three-letter ISO 4217 code such as TRY. If your order source stores tax-inclusive product prices, identify the field that represents the item amount excluding tax. Matching fields by name alone can produce the wrong revenue calculation.

A small test with one product

The following values are for testing only. Two units priced at 450 give an item total of 900. Shipping is recorded separately as 50. This example does not include a tax field; if your implementation sends one, map it separately from the appropriate source.

{
  "event": "purchase",
  "ecommerce": {
    "transaction_id": "TEST-ORDER-001",
    "value": 900,
    "currency": "TRY",
    "shipping": 50,
    "items": [
      {
        "item_id": "TEST-SKU-001",
        "item_name": "Test product",
        "price": 450,
        "quantity": 2
      }
    ]
  }
}

This JSON sample is for inspection. Pasting it onto a page does not send data to GA4 by itself. GTM still needs the appropriate dataLayer fields mapped to event parameters. For successive ecommerce actions, also check that fields from a previous ecommerce object do not carry over into the next payload.

Trace where duplicate sends begin

Complete one order in GTM Preview. Look at how often purchase data is produced, how often the associated tag fires and which transaction ID is sent. A platform integration and GTM can both measure the same purchase. Identify these sources before removing a tag or plugin: other tracking may depend on the same integration.

Next, refresh the confirmation page, return to it and create a second test order. The first order’s identifier should stay the same; the second order needs a different one. Note the tags that fire in each scenario. Transaction-ID deduplication does not remove the need to investigate why a tag fires twice.

Valid data and successful delivery need separate checks

Use the free GA4 event analyzer to inspect field names, item structure and value types. It checks the sample you provide. A valid result does not show whether the trigger ran at the right time, what consent the visitor gave or whether GA4 received the event.

Check live delivery separately with Tag Assistant and GA4 DebugView. If the event is missing, follow the GA4 event troubleshooting checks. Record the consent state in your test session as well. Testing should respect the visitor’s choices rather than bypass them.

When comparing reports, use matching date ranges, currencies and order statuses. Refunds, cancellations and report processing time can also affect the comparison. If the problem extends beyond one sample, a GA4 and GTM audit can review the configuration, triggers and data flow together.

Sources and setup support

For current field definitions, see Google’s purchase event reference. Its ecommerce implementation guide provides tracking examples, while the transaction-ID guidance explains deduplication behavior.

If you would like us to review the setup, describe the order flow and the difference you are seeing in your GA4 setup enquiry. Share test examples rather than customer information.