Domaine’s Director of Engineering, Connor Munro, dives into Shopify’s custom web pixels. Learn how to build custom pixels for customer engagement insights on your Shopify store. Watch the video, and ask the team at Domaine any follow up questions you may have in the AMA thread below.
Interested in working with Domaine? Email hello@meetdomaine.com. Also, check out out these additional resources from Domaine about the Checkout Extensibility upgrade:
This AMA will be open from July 22nd - 26th. We’ll aim to answer questions within a 24-hour window, though we can’t guarantee that every question will be answered.
Rules of engagement:
We’ll do our best to follow up on every question during the event.
You must be logged into your account on Community to participate.
Assume positive intent with one another and be kind. Some users may be new and learning how to engage with the Community.
Be authentic and honest with your questions and answers.
Do not ask for or share store admin login details or passwords.
Like posts and threads that are of interest or helpful to you.
Be constructive with criticism, not offensive.
Share your experiences and insights whenever you can to support others.
Abuse, harassment, and spam content won’t be tolerated.
We’re seeing some instances where the checkout_completed event isn’t dispatched for some clients. Do we have a list of scenarios when the event is not fired when compared to the old order confirmation script injection?
For a recent store we reviewed, we were seeing 30% missing orders. When we audited the checkout further for the site (which was running 6 web pixels), we were seeing pixels take 3-7 seconds to fire, which seems to be enough time for someone to leave the page and the pixel to miss the event. We would love to understand what is best practise for web pixels given they are each on their own sandboxed iframe (This was tested on a 60Mbps connection on a desktop running windows 11 and through chrome). I.e. if we have a strategic method of prioritising a pixel, or ensuring it runs higher up in the priority list that would be great.
Thanks,
EDIT: I should mention our pixels are not conditioned to any consent preferences - they are set to fire always.
How have you approached debugging in Google Tag Manager now that Preview mode no longer works with Shopify checkout customer events sandbox? When managing dozens of pixels this becomes unmanageable fairly quickly as we often need to see exactly what data is being passed to each pixel vendor.
I’m fairly new to this, so apologies if these are basic questions. I’m trying to recreate our existing ecommerce dataLayer as a custom pixel, but I can’t find any variables relating to the actual products purchased in the checkout_completed event. I.e. the variables that are nested under the products section of the current dataLayer:
Also, there is currently an additional script in place (see below) that uses the customer.orders_count value to calculate if a customer is new or returning and pass this into a variable that is pushed in the dataLayer, but I cannot find a corresponding variable in the checkout_completed data structure.
var customer_type = ({{customer.orders_count}} > 1) ? ‘repeatcustomer’ : ‘newcustomer’;
Thanks for reaching out. There are a couple things to check. First, try the Shopify pixel helper and confirm the pixels are subscribed properly to the event. Second, if you see a green dot in the shopify pixel helper it indicates that the call back ran correctly. Third, you may have a top level error in your pixel code that stops the pixel from running in some cases. Shopify is working on providing runtime error reporting for each pixel but in the meantime, let me know the shop and pixelID and I can pass that along to the Shopify team to take a look.
3-7 seconds is a large delay so I would recommend having a look at what else is loading on the page before the custom pixels and if that can be optimized. On the new Thank you page, you will not see this issue because web pixels would have initialized when the checkout was initiated.
For conversion scripts you will no longer require the first_time_accessed condition, as the checkout_completed event will only fire once regardless of the number of times a customer loads the order status page.
Unfortunately there isn’t yet a good way to preview this on the GTM side. Our process so far has been to create console logs within our custom pixels so that we can see a representation of the data that we are sending in the format we are sending it, and then to also check the network requests to ensure we’re seeing the data being sent. Hope this helps!
I would like to know how the firing of the pixels will work for orders created through the Admin APIs.
For these orders, there is no “thank you” page, the API directly returns the Order Status Page Url .
In our projects, we create some orders on the backend side this way, and then we redirect the user to the Order Status Page. We expect this page to continue firing pixels the first time the customers open it.
We would like to know if there’s yet any solution on how to integrate with the Google Customer review Survey opt-in while using new checkout and Thank you pages?
The essential problem is that the Google code snippet wants an external script to render their pop up and sandboxes of both Checkout UI extensions and Web Pixels prevent that from happening.
As far I know (I could be wrong, please let me know), there is no workaround for this yet.
You’ll find that this object does not contain all of the data you’ve outlined within your spec, so you’ll need to look at introducing data from other parts of this payload (e.g., data.checkout.discountApplications will contain some discount code titles).
Additionally, pixels can read order attributes and line item properties if you want to pass additional data from your theme code, which you would need to do in the case of the customer order count.
The checkout_completed event fires on the thank you page OR the first /post-purchase page if the merchant is using post-purchases. If the customer lands on the order status page after purchase, web pixels will not fire a checkout_completed event.
Because you’re using the Admin API to create orders, you could look at building out a service that relies on the order created webhook (list of webhook topics), though this would not be connected in any way to Shopify’s customer events functionality. If you do proceed down this path you will want to be aware of the potential for double-tracking if any users are using the traditional checkout flow.
To my knowledge there is no official support (either Google- or Shopify-built) for integrating Google Customer Reviews. That said, the app development community continues to fill in these functional gaps, so I would recommend searching the app store for something that meets your requirements (app store).
Hello, I hope you are doing well. I have questions regarding both the current situation and also future plans. Thank you in advance for taking the time to answer them.
We are experiencing issues with some Checkout events; for example, add_shipping_info and add_contact_info are triggered less frequently than add_payment_info. Do you have any information or insights regarding this situation?
Is there a plan to allow actions such as connecting/disconnecting or creating/deleting a Custom Pixel, or changing its code structure, to be performed via API? On the other hand, we can define settings via API in App Pixel, and the relevant variables can be used in the App Pixel code. Is there a goal to enable the use of variables within Custom Pixel, similar to how we use shop/app metafields on the App-Embed side or App Pixel settings as I mentioned?
Are you comparing the accuracy of the App Pixel with the Custom Pixel? If you had the chance to make a comparison, could you please share your observations and results?
Do you know there is a plan to provide a Customer Event for the review and processing steps?
We have observed that checkout_completed is generally triggered at both the processing and thank_you stages via Shop.app. Are there any investigations regarding this?
What is the difference in the display of the pages with paths “thank_you” and “thank-you” (e.g., shop.app, 3rd party checkout apps, etc.)?
How can we clean URLs from all sandbox parameters collected automatically by platforms that do not allow overriding the page URL (with a variable like GA4) collected through GTM tags? There is a method on how to edit iframe URL/location to avoid “incorrect sandbox url” tracking?
SorryJ-Dubya—I misspoke on my last point. While there will be some cases in which you’ll have to pass data through via line item properties or order attributes, the customer order count is not one of those. That data can be gleaned by drilling down into the init object (documentation).
The data provided by context.window is provided by the top-level frame of the browser, not the specific pixel iframe.
That is correct, you cannot interact with the DOM through a web pixel.
With the introduction of Customer Events, it is best practice to add all 3P pixels as individual custom or app pixels through the Customer Events area.
As you stated, pixels added through the Customer Events area are included via iframes. This provides a level of security as it ensures that the reach of that 3P script is constrained to the data provided to that iframe. This may be less of a risk with a big corporation like Google, but the reality is that any 3P script you are including within your site could change their injected code without your knowledge to perform some malicious act, or even just scrape more data than you would like/require. The iframe ensures that you have a better understanding of what each 3P has access to. Additionally, Customer Events pixels can seamlessly connect in with Shopify’s Customer Privacy API to keep you more in line with privacy regulations: you can set the type of pixel you’ve created, and this API will toggle the pixel on/off given the customer’s consent settings (when using a cookie consent banner that also supports Shopify’s Customer Privacy API, like their OOB tool, as well as a handful of 3P apps).
