Tracking Shopify Checkout Extensibility
Server-side checkout tracking
As Shopify has moved stores onto Checkout Extensibility (the 'new' checkout) it has become harder for stores to track the checkout steps and purchases.
One solution is to use Custom Web Pixels to insert tracking code from the checkout pages themselves, but this is messy to maintain and has technical limitations.
Littledata has a better solution, which works seamlessly for all types of checkout - automatically tracking the checkout updates from Shopify's servers, and inferring the customer behaviour.
Littledata supports checkout funnel event tracking for:
- Shopify checkout (including Checkout Extensibility) *
- Accelerated checkouts (Shop Pay, Amazon etc)
* This includes the same events for both the one-page checkout and the original three-step checkout.
Where the Shopify checkout includes checkout apps handling subscriptions or upsells. the checkout steps are the same for these customer journeys, but the resulting order is differentiated.
Littledata advantages
These are the advantages of using Littledata to track Checkout Extensibility versus custom web pixels (also known as customer events):
- No code setup - automatically installed
- No maintanance required as Shopify, Google, Meta etc change their APIs
- Tracks users with adblockers or network limitations
- Works for headless site with a Shopify checkout - please follow the headless setup guide first.
Default checkout steps
When the customer starts and progresses through the checkout on your Shopify site, Littledata triggers the following checkout step events:
- Step 1: Contact information
- Step 2: Shipping information
- Step 3: Payment method
- Purchase (Order complete)
Checkout step triggers
Let's take a closer look at the structure of these events, what we call them when they're triggered, and how they work.
Step | GA4 Event Name | User action | Technical trigger |
---|---|---|---|
1 | begin_checkout | Contact info section viewed | Checkout created in Shopify for that cart |
2 | add_shipping_info | Shipping info section viewed | Customer property added to checkout |
3 | add_payment_info | Payment section viewed | Shipping lines property addded to checkout |
Purchase | purchase | Order completed | Order is created and marked as PAID |
You can see how this works for tracking the Google Analytics checkout funnel
Accelerated checkouts
Littledata works seamlessly with one-click checkouts (like Shop Pay), tracking the purchase and sending it over to the desired destination, as well as attributing it to the original source.
But these accelerated checkouts may lack Checkout Steps - because the nature of the one-click checkout is to bypass the Shopify checkout entirely.
How sever-side tracking works
For security reasons, third-party apps such as Littledata don’t have access to load third-party JavaScript libraries (e.g. gtag or Meta Pixel) onto Shopify's checkout. We depend on Shopify's webhooks to infer the checkout pages viewed by a particular user.
When a user zips through the checkout pages in quick succession (specifically under 10 seconds), Shopify only informs us of the last page viewed by the user, and passing through these raw updates would result in a nonsense checkout funnel:
So for every checkout step, Littledata checks back if it has sent events for all previous steps for the same user ID and checkout ID in the last 3 days.
In cases where previous step events were NOT sent in the last 3 days, Littledata retroactively adds checkout steps to make sure the user’s journey looks complete in the checkout funnel.
For example, let’s say a user is already logged in and gets through to the payment page within 10 seconds. For this user, even if Shopify only communicated the final end-state (i.e. payment page), Littledata will assume that they went through all steps of the funnel as expected and send 3 separate steps:
- Contact Information (retroactively added)
- Shipping Information (retroactively added)
- Payment Method (webhook end-state)
Trade-offs
Although retroactively adding steps makes the funnel a lot more meaningful, there are a couple of trade-offs that should be kept in mind while analyzing the data:
- This method could misrepresent the cases where the users actually started the session in the middle of the funnel by retroactively sending step hits to GA.
- Events on the same user checkout beyond the 3-days cut-off will be resent, which could lead to duplicate events sent to GA. However, we believe a 3-days will cover the vast majority of cases for most e-commerce stores.
Segment destination
We send the following checkout step events.
Step 1 | Step 2 | Step 3 | Step 4 | Complete | |
---|---|---|---|---|---|
User journey | Contact info page viewed | Shipping info page viewed | Payment page viewed | Bank / payment verification | Transaction completed |
Actual trigger | Checkout created in Shopify's database for that cart | customer property added to the checkout object | shipping_lines property added to the checkout object | gateway property is added to the checkout object | Order is created and marked as Paid in Shopify |
Segment - Event name 1 | Checkout Step Viewed | Checkout Step Viewed (step 2) | Checkout Step Viewed (step 3) | Payment Info Entered | Order Completed |
Segment - Event name 2 | Checkout Started | Checkout Step Completed (step 1) | Checkout Step Completed (step 2) | Checkout Step Completed (step 3) | Thank you Page Viewed* |
* The Thank you Page Viewed event was deprecated due to Shopify's new checkout as scriptTags
can't be loaded anymore on the checkout.
Check out a detailed list of all events tracked by our Segment connection.