Fixing GA4 Purchase Tracking: Send Shopify Order Name as transaction_id

 

Running one of Shopify’s most recognizable tracking apps, Anowave Google Tag Manager, has revealed a question we hear from customers again and again: "How can I send the Shopify order name instead of the numeric order ID?"

 

Why does this seem like a valid question?

The Shopify order grid displays the order name (such as #1001), while Google Analytics 4 shows the numeric order ID. When you move between the two systems, the numbers don't match visually.

We are people, not machines, and this seemingly small discrepancy can make it harder to recognize that the order you're looking at in Shopify is the same order you're seeing in Google Analytics 4.

 

Why almost 100% of apps send numeric ID instead of the order name that appears naturally in order grid?

Shopify has a special mechanism that protects the Checkout and Thank You pages from running arbitrary custom scripts, such as Google Tag Manager. Instead, Shopify allows apps to install and activate custom scripts called Web Pixels.

A Web Pixel runs in a sandboxed environment, which means it does not have direct access to sensitive checkout information such as credit card details or the checkout page itself. However, Web Pixels can interact with Shopify’s Web Pixels API and subscribe to events generated by Shopify Analytics.

For transaction tracking, the key event is checkout_completed. This event is triggered when a customer successfully completes a checkout and is typically fired on the Thank You page. It is triggered once for each checkout.

When checkout_completed occurs, Shopify’s Web Pixels system notifies all active Web Pixels and provides them with relevant event data. The pixel can then process this information and send it to external platforms such as Google Analytics 4, Meta, Google Ads, TikTok, and others.

This mechanism allows apps such as Anowave Google Tag Manager to track purchases and other customer events without requiring unrestricted JavaScript access to Shopify’s protected checkout environment.

 

The problem

The problem is that Shopify's checkout_completed event payload provides the numeric order ID, but does not include the order name (for example, #1001). Shopify's Web Pixels API simply does not expose the order name as part of this event, so there is no way to obtain it directly from the checkout_completed payload.

After investigating the Shopify API, we found that this is a limitation of the event itself rather than something that can be solved by changing the event configuration or requesting additional fields.

This leaves all apps running client-side pixels without options. It's impossible to access the order name. 

 

The solution (without switching to a new third-party app)

Unfortunately, there is no 100% complete solution to this issue, but there are a couple of ways to partially mitigate it:

• Export orders
  
  You can export your orders directly from the Shopify order grid. The exported file, typically a CSV, includes the order ID in Shopify's GID format, for example gid://shopify/Order/780092323. This allows you to have the order name and numeric order ID available in the same row, making it easier to match orders between Shopify and Google Analytics 4.
   
• Use Shopify Flow

  For some of our customers, we've used Shopify Flow to work around this limitation. You can create a flow triggered when an order is created and automatically add the numeric order ID as an order tag.

  Order tags can then be displayed as a column in the Shopify order grid, allowing you to see the Shopify order name and its corresponding numeric order ID directly in the admin interface.

 

The solution using our ACT Server-Side Tracking CAPI app for Shopify.

We had to find a way around this, and the answer came while we were working on our 100% server-side ACT Server-Side Tracking CAPI app for Shopify.

The key is to move the lookup to the server. Shopify can send an order webhook to the app when an order is created. A webhook is essentially an HTTP request that Shopify sends to the app shortly after the order event occurs.

Because the webhook is delivered to our server, we can use the order data provided by Shopify's Admin API, including the order's name (order.name), such as #1001. This gives us the information that isn't available in the client-side checkout_completed event.

Using entirely server-side conversion tracking for your ad campaigns can provide greater control and flexibility. It gives you access to a broader set of order data and can make use of first-party identifiers, while reducing your reliance on browser-based tracking.

But... We LOVE Google Tag Manager!

Our users should be able to benefit from the latest available technologies, and our GTM app is no exception.

The server-side approach we developed for our ACT Server-Side Tracking CAPI app proved that the same architecture could solve the order-name problem in our Google Tag Manager app as well.

So we brought the technology over.

Anowave Google Tag Manager can now combine client-side and server-side tracking. The client-side component captures the session identifiers and advertising attribution parameters that are available in the browser and passes them to our server. When the order webhook arrives, the server has access to the Shopify order data, including the order name (order.name).

The result is a server-side purchase event that can use the Shopify order name as the transaction_id instead of the internal numeric order ID.

There is one important consideration: the client-side purchase event should be disabled when using the server-side purchase event. Otherwise, the same purchase may be sent twice, potentially resulting in duplicate conversions in Google Analytics 4 or other advertising platforms.

This approach gives merchants the best of both worlds: Google Tag Manager on the client side, combined with the additional data and capabilities available through server-side tracking.

And, perhaps most importantly for this particular problem, it allows the Shopify order name displayed in the Shopify admin to be used as the transaction_id in Google Analytics 4.

No separate tracking stack is required. The technology developed for ACT is now available directly within our Google Tag Manager solution.