How to track checkout field completion on Checkout Extensibility?

Shopify Partner
1 0 0

Hello, everyone!


I'm trying to create some custom customer events on my checkout page to eventually send to GA4. My current process is this:


1.- Create a Checkout UI Extension ( that uses some javascript to check (by DOM selector) if the specific fields are filled in. I'd like to do this with a "blur" event on each that checks that the field is not empty -no validation rules needed for now-.


2.- From inside that Checkout Extension, create some custom customer events and emit them (

3.- Inside the Customer Events section of the settings, create a Custom Pixel that includes my GTM code, subscribes to the custom events I created in step 2 and pushes them to GTM's Data Layer (


4.- Do all the work required in GTM -I don't need help with this- to send the events to GA4 once specific Data Later events are triggered.


This all makes sense to me, but my team of developers is having issues implementing it. I'd like a few details:

-Can the Event Listener on Blur for DOM elements actually be done via a Checkout Extension?

-Is there a limit or restriction on the amount or type of custom events the extension can emit?

-Are there any flaws in the process I described?


Thank you very much, community!

Replies 2 (2)

Shopify Staff
2731 299 769

Hi EnriqueOcampo,

Your process seems to be generally correct, but there are a few things to note:

  1. Event Listeners for DOM: Depending on the type of Checkout UI Extension you are using, you may not have full access to the DOM. Checkout UI Extensions run in a sandboxed iframe, not in the main browser context. This means you have access to a limited set of APIs and can't directly manipulate the checkout DOM. You may have to find other ways to monitor changes in the checkout fields.

  2. Custom Events Limit: While the documentation does not explicitly mention a limit on the number or type of custom events you can emit, it's usually a good practice to limit the amount of custom events emitted to only what is necessary. This can help prevent potential performance issues or data overload.

  3. Process Flaws: As for potential flaws in the process, note that the custom pixel you create must be able to the custom events you're emitting. Make sure that the events you're emitting are correctly formatted and contain all the necessary data. Also, make sure to test thoroughly to ensure that the events are being captured correctly and that they triggering the desired actions in Google Tag Manager.

Your developers could also be facing issues due to the sandboxed nature of Checkout UI Extensions, or there might be issues with the way the custom events are being emitted or captured. It might be helpful to have your developers provide more specific details on the issues they're experiencing.

Hopefully, this provides a bit more clarity!

Liam | Developer Advocate @ Shopify 
 - Was my reply helpful? Click Like to let me know! 
 - Was your question answered? Mark it as an Accepted Solution
 - To learn more visit or the Shopify Web Design and Development Blog

Shopify Partner
4 0 2

Hi Liam, thanks for this info. It's helpful. We (Aura Frames) are facing a similar challenge: In `checkout.liquid`, we were able to access DOM elements on the checkout page, so we could add mutation observers and event listeners to those elements and send events to Google Analytics in the callbacks. But it doesn't look like we have access to `document` in checkout UI extensions. It seems like this could be a common desire, to add event listeners on DOM elements on the checkout page for analytics purposes. Do you have any suggestions for workarounds? Or does Shopify plan to offer more access inside app extensions to existing / default checkout UI elements in the future? Or maybe we've missed something in the documentation that would allow us to do this?


Specifically, we're interested in adding an event listener to the "Apply" button next to the discount code input, so we can monitor which discount codes users are entering (not only the codes they end up actually applying, which we obviously do have access to).