Hi! Has anyone experienced Shopify Checkout IDs [instead of Order IDs] populating for some orders in Google Analytics Ecommerce Sales Performance reporting?
When searching these Checkout IDs in Shopify, they do tie to an Order ID, which is not recorded in GA [so no duplicate reporting]. Just trying to understand why some transactions record the Order ID vs. Checkout ID in GA.
Thank you!
Example below:
Hello,
I am having the same exact issue. Looks like this has been an issue for a while (https://support.google.com/analytics/thread/92447759/shopify-checkout-id-showing-instead-of-order-id-in-ecommerce-reporting?hl=en) that Shopify hasn’t fixed.
I am working to check transactions across both Shopify and GA so this is frustrating! When I read your post, I am wondering if you know how to view Checkout IDs in Shopify. I can’t find it and their support was of no help.
Same issue here. Making the analytics in GA so much of a hassle. It has been working fine but all of a sudden it does not anymore.
I contacted Google a few time to check all scripts and data layer on our checkout page. Everything was fine. So I guess there must be some issue happening for Shopify to integrate their information to GA.
I just started to notice this on a couple of our clients GA accounts too. Seems to be random. I thought maybe it was something related to Tag Manager which was picking up the wrong ID from Shopify when pushing data to GA, but don’t see how it can be otherwise all transaction IDs would mimic the checkout ID not a random selection. Let’s hope someone from Shopify looks into it.
I am having the same exact issue. How to fix it?
Sadly, no. I have asked here in the community and also contacted Shopify
support. They tried to blame Google Analytics, but it’s clearly a glitch
in their system.
I read somewhere that sometimes the Shopify order number isn’t available when the order is submitted. A user will place their order and the order number isn’t available from Shopify at that moment, so it is not showing on the confirmation page. Shopify assigns an order number a few minutes after, but not at the order submission. Universal Analytics assigns the longer number that you see in your reports in Universal Analytics and so far I am not seeing a transaction ID at all in GA4. It just shows not set in GA4 
We are experiencing the same issue and it started to pop up on/around 10/11. It was also around the same time that shop.app referral was taking credit for most transactions on site and we needed to add that as a referral exclusion. I believe Shopify changed something with their checkout functionality that caused the issue.
Same issue for us too.
It seems to have been a major change for us at the end of October.
Our reporting tool (Glew) is now suggesting that these orders had an un-identifiable source because the two aren’t lining up.
Shopify support said:
“This can happen if the customers who placed these orders were forwarded to the order thank_you page before an order number was available.”
Followed directly by:
“As of now this is a limitation with the Google Analytics integration.”
I’m not sure how it can be a limitation of GA integration if Shopify aren’t sending the order number.
Basically Shopify are saying it’s a GA issue, and therefore won’t be looked at by developers. The only way to get them to look at it is to start making noise.
Shopify needs to own up to this issue and fix it.
Our shop seems to have changed back to previous levels (2 or 3 a day) as of Friday 18th.
Has anyone else seen this happen?
This is also something we noticed in our tracking at The Data Refinery, affecting some of our clients as early back as August. When we have looked in more detail it appears that the values for identifying each Shopify order in GA were starting to differ in format meaning a straight forward 1 = 1 join between the systems is no longer going to be sufficient. Our Dev team have created a custom piece of logic in The Data Refinery that means that the joins between these two systems could be agnostic to which value was placed in the GA column and now we have correctly tracked and found the missing orders!
Happy to see if The Data Refinery could help with your tracking if you want to contact us directly - email is in my signature
I have clients with the same issue. We determined, with their UA account at least, it seems to only be a problem on ShopPay transactions.
@BlakeFischer it may be a ShopPay issue, but as another datapoint we have a client with 5 different consumer facing brands all with identical Shopify set up but this issue affects each of those 5 accounts to different degrees. One has virtually no issues with GA transaction IDs showing the Shopify Order Number correctly around 95% of the time. For another account this figure is 15%! We’re taking matters into our own hands and expanding the way we match between the two systems. One thing that is true is that it’s definitely become a more prolific issue recently (way more noticeable since August last year)
I agree with @BlakeFischer the issue only seems to be Shop Pay Transactions.. I have 2 client stores and tracking in GA4. this is the code i have been asked to use.
{% if order.name %}
transaction_id: “{{order.name | remove: “'” | remove: '”‘}}",
{% else %}
transaction_id: "{{checkout.id | remove: "’" | remove: ‘"’}}",
{% endif %}
most of the transactions are falling into else block
I know this is an old thread, but did you ever find a solution? We’ve seen this problem persist and only worsen with Extensibility.
As far as I can tell, not solved by Shopify. I set-up goal tracking in addition to Ecom tracking for Piwik Pro and my client’s small Ecom site (hundreds of sales per month, not thousands) still has a few sales each month that Piwik Pro doesn’t pick up because it’s looking for order id but Shopify is sending the checkout ID. Goal tracking catches all sales but, obviously, lacks the other metrics that come with Ecom tracking.
Appreciate the response—I’ll check out Piwik. It’s too bad this is a persistent issue.
Piwik Pro’s session logs and real-time “tracker debugger” feature is how I discovered that some purchases are not being recorded.
