Shopify Checkout Extensibility Review: 8 Months In and Dozens of Implementations.

In 2024, anyone working in analytics for Shopify websites has been busy “upgrading” to Checkout Extensibility. This is especially true for Analytics Ninja as one of our major clients is a significant Shopify user with over 30+ websites. The migration, which began in 2023, remains a work in progress, with a few sites still in the process of adopting Checkout Extensibility.

Checkout Extensibility is a broad term that encompasses changes in Shopify across payment integration, compliance, security, third-party app integration, and other areas. Most of the online content about Checkout Extensibility frames it as an obvious and necessary improvement. While that may be true for some aspects of Shopify outside of our expertise, the reality is far more nuanced when it comes to Marketing and Analytics. In this article, we’ll explore the features and implications of Checkout Extensibility for analytics implementation, and share our hands-on experiences.

Sandbox and pixels: Beyond the Martech Gibberish!

For analytics and marketing, the critical change is the deprecation of checkout.liquid and the necessity of using “Customer events” to track user behavior on checkout pages.

Web Pixels API and Pixels Manager.

To understand what’s happening to our analytics implementation, it’s important to look at the Web Pixels API and the Customer Events.

The Customer Events section provides an interface for managing tracking pixels. The Web Pixels API allows pixels to subscribe to events within sandboxed environments. Together, these tools are designed to manage and integrate tracking pixels in Shopify.

“Sandboxed”

When implementing analytics using theme.liquid we had full control over tracking behavior and data collection. Competences, time and budget were the limits… With Checkout Extensibility everything is “sandboxed”. This shift introduces several significant limitations:

• Can’t render UI elements (buttons, forms, banners, modals).
• Can’t automatically detect:
  • Events from DOM scraping
  • Metadata from DOM scraping
  • User information (email, phone) from DOM scraping
  • Outbound link clicks from DOM scraping
  • Page scrolling
  • Clicks and mouse movements for heatmaps from DOM scraping
• Page URLs show a sandbox version, not the main window’s URL.
• Limits on accessible information, control of third-party data access.
• May not be compatible with some third-party pixels.

These constraints limit tracking and data collection to Shopify-defined events and properties, making it far less flexible compared to traditional code-based or DOM-based tracking methods.

Standard and DOM Events.

As we have less flexibility to build our own tracking, Shopify is providing some predefined events with predefined properties through the Web Pixel API with Standard Events (e.g., cart_viewed, checkout_started, checkout_completed) and DOM Events*(e.g., clicked, form_submitted).

Each event comes with predefined properties. For example, the checkout_completed event includes:

• currency_code
• order_id
• total_price
• shipping_address
• etc…

Custom & App Pixels.

You can access events dispatched by The Web Pixel API using Custom or App Pixels. App Pixels are installed through Apps and Sales channels section. Custom pixels are created from the Customer events page.

Here’s an example of a Custom pixel we have implemented to push standard event with their properties into the data Layer:

const processEvent = (event, customer) => {
  window.dataLayer.push({
    event: event.name,
    customer: customer,
    eventData: event
  });
}

const events = [
  'cart_viewed',
  'checkout_address_info_submitted',
  'checkout_completed',
  'checkout_contact_info_submitted',
  'checkout_shipping_info_submitted',
  'checkout_started',
  'page_viewed',
  'payment_info_submitted',
];

events.forEach((eventName) => {
  analytics.subscribe(eventName, (event) => {
    processEvent(event, customer);
  });
});

This snippet loops through each standard event available in the events array when triggered and pushes them to the data layer, including all available information (the entire data object is pushed into the data layer).

You can access the data layer of the sandbox environment selecting the web pixel iframe to verify your implementation.

Customer Privacy API and Consent Management for Pixels.

App and Custom Pixels can require permission from Customer Privacy, Shopify’s built-in Consent Management Platform (CMP). For App Pixels, permissions are defined by the app’s creator. To review the permissions an app requires, you can check the View Permissions window by clicking the three dots next to the app listed under Customer Events.

In the example above the App will only be triggered when marketing and analytics permission are granted.

For Custom pixels you have to set the permission from the Custom pixel itself.

Potpourri of lessons learned, hands-on experience and feedback.

As mentioned in the introduction of this article we have upgraded 30+ websites to Checkout Extensibility. Even though we are much more comfortable with it we have yet to find the perfect setup. In this section we are going to share our experience of the migration and reflect on the current state of of checkout extensibility.

The Migration

During our migration to checkout extensibility, we faced two primary challenges:

1. Transitioning from Open to Closed environment: We had to adapt our tracking from a system where custom tracking, DOM scraping, and open access to the Shopify data object were standard to a new framework where these capabilities were either restricted or non-existent.
2. Consolidating Scattered Marketing Assets: Gathering manually added JavaScript splattered across online preferences, checkout scripts and apps.

To address these challenges, we developed the following solutions:

• Complete asset inventory: This involves creating a detailed list of all websites to be migrated along with their components. For analytics, this meant documenting critical details such as domain names, GTM container IDs, and GA4 property IDs. This inventory ensures a clear understanding of the current state and target outcomes, avoiding confusion about legacy implementations or the creation of new containers or GA4 properties.
• Clear Ownership and Accountability: Define ownership entities for each website and tag. This facilitates progress tracking, results reporting, and validation acknowledgment from stakeholders.
• Clear communication adapted to different teams: Effective communication is critical in a migration project involving diverse teams, including IT, Business, Marketing, and others. From developers to project managers and product owners, each stakeholder has unique perspectives, expectations, and levels of technical understanding. Tailoring communication to these audiences ensures everyone is aligned and onboard, which is crucial for project success.
• Thorough Audits Conduct comprehensive audits of tags, scripts, data layers, and data models to ensure continuity in functionality and data integrity:
  • Tags, Pixels, and Scripts: List all items (e.g., widgets, snippets) required on checkout pages post-migration.
  • Data Layer Variables: Identify and address variables previously used that may not be available in the new sandboxed environment. For example, if a previously collected transaction ID is unavailable, plan for alternatives like an order ID with proper formatting.

By implementing these strategies, we navigated the challenges posed by the migration. If we were to have another migration next year I’m not sure that “the pixel manager” would change anything, at least in its current state. We still have online preferences settings, script injected in theme.liquid in addition to customer events. The way pixels are managed and installed—across apps and sales channels—remains difficult to control.

Deploying, Testing and Debugging.

This part was and still is particularly painful for the multiple reasons:

• No Shopify or GTM Preview: New checkout pages are live as soon as Checkout extensibility is switched on. You can’t test it using preview theme. GTM’s preview mode is also unavailable in the sandboxed environment. Testing requires directly monitoring network requests, which also necessitates publishing your GTM workspace. Go live is the only way to move forward
• Opacity: Checkout extensibility is riddled with opacity. When something doesn’t work as expected, debugging options are limited, and contacting Shopify support often becomes the only viable way to move forward

To manage these limitations, we ended up organising live testing sessions where checkout extensibility was activated for a few hours in order to conduct test purchases and debugging issues. During these phases exporting HAR files of network requests was useful to keep track of our testing sessions and validate improvement or regressions. As we were more comfortable deploying checkout extensibility and since checkout.liquid time was counted we ultimately adopted a “fix-on-the-go” approach, deploying live, testing and fixing at the same time. Most of the work had to be done synchronically with the different teams on multiple timezones.

Now that Checkout Extensibility have been almost fully deployed we are still very limited on testing for any changes made on the checkout pages. Modifying custom pixels can’t be previewed. Any changes made in GTM need to be published and debuged in live.

The implementation

When it comes to implementation, we face two primary challenges:

1. Dual-system tracking: Apps and Custom Pixels are the only solution for analytics implementation on checkout pages, while theme.liquid remains available on all the other pages and is sometimes required to track specific custom elements.
2. “it just works” design philosophy: Most “ready-made” solutions mask underlying complexities. While no-code solutions are useful for simple use cases, they often hinder the ability to meet more advanced and complex requirements.

These challenges can’t really be addressed on our side so we’ve worked around them with the following approach:

• We rely on our own implementation as much as possible. We have opted not to use the GA4 Shopify native integration. GTM is loaded via a Custom Pixel without requiring permissions as well as on Theme Liquid. We minimize the use of App Pixels.
• Given the state of permanent dual-system tracking, many tasks are duplicated and QA efforts doubled. This also affects some apps that function seamlessly on most of the site but not on checkout pages.
• While pixels are available across the entire website, they lack the flexibility needed to handle the high level of customization often required on product pages, homepages, catalog pages, and event like “add to cart”. All kind of customisation permitted in theme.liquid still need to be tracked.

In conclusion…

I do see a world where checkout extensibility provides a unified tracking layer with centralised consent management. While this opportunity is not entirely missed, it is not there yet. Instead, for now, Checkout extensibility has introduced yet another mandatory analytics/marketing layer, adding complexity rather than simplification and making testing and debugging particularly difficult. A lot of this echoes to the lack of transparency we already noted in Shopify Google Analytics Integration back in 2013 in this same blog. I’m curious to see how checkout extensibility evolves. Will it fully replace theme.liquid? At least for marketing and analytics? Is it feasible to migrate all customisations currently handled in theme.liquid into apps? Whatever the plan, I hope Shopify will embrace the inherent complexities of marketing analytics instead of clumsily concealing them and provide comprehensive documentation for “under-the-hood” functions and design logic (and I’m not saying this is easy!).