Checkout Extensibility Upgrade AMA: Custom Web Pixels with Domaine

[CMunro]

Hi Alaz,

Great questions!

1. It may be that there is a runtime error for those events that you’re having trouble debugging. Shopify is in the process of implementing runtime error reporting for custom pixels, but in the meantime I would recommend reaching out to Shopify’s support team to dig into your specific issue.
2. Shopify does not have plans to allow programatic API access for the custom pixel. They would like people to use app pixels for that case. App pixels are preferred because they are more performant. They run off the main thread (via web workers), unlike custom pixels which run on the main-thread (within an iframe).
3. App pixels and custom pixels perform pretty much the same for simple cases, but when a shop has a heavy theme, you’ll see better performance with the app pixel (again this comes down to web workers vs main-thread activity). Unfortunately, I do not have any hard stats on their relative performance.
4. Shopify does not have plans for the processing step, but does for the review step. Right now you should see both of those show up in the page_view urls.
5. To my knowledge, web pixels do not track on Shop.app. This may be another question for Shopify’s support team.
6. “/thank_you” is the old thank you page while “/thank-you” is the new checkout extensible thank you page.

[Sasank]

Hi,

Thanks for doing the AMA. Here’s my question:

We are using custom web pixel on a Hydrogen storefront. Everything works perfectly till checkout_completed - all pre-checkout events on Hydrogen and checkout & purchase events on the Checkout and Thank you pages.

But the problem is with Order Status page. The pixel is not even initialised here. So unable to subscribe to even the page_view event. The order status page is not on the same domain as checkout - it is from the new customer accounts. Can you please help with this?

Ideally I don’t even want to use the new Customer accounts and keep the order status page also on the checkout domain. It is definitely out of score for this AMA, but would you know how to turn this off? There is no setting to turn this off in Settings > Customer Accounts for newly created stores.

Thanks.

[ilke_uygun]

Hello, thanks for this.

My questions are as follows:

1. So the Thank You and Order Status pages are going to be deprecated a year later but we have code blocks as such in the checkout.liquid file which is shared across all the current checkout pages:

{% if downcasedPageTitle contains 'thank you' %}
...
{% endif %}

Does this mean that they will continue to work while the rest will stop working? I am confused about this because there is no dedicated liquid file for Thank You and Order Status pages that I know of.

2. Does the custom pixels only work for analytics, conversion tracking code only? For example, I have some 3rd party scripts in the checkout.liquid file that I want to carry over, but although they seem to load fine when I test with the Pixel Helper, it doesn’t function as expected. Here is an example from the address validator script that we use:

​

which turned into:

const loadAddressValidatorScript = () => {
  const head = document.head;
  const script = document.createElement('script');
  script.type = 'text/javascript';
  script.src='https://{OUR-ID-HERE}.cloudfront.net/pobox_checker.js';
  head.appendChild(script);
};

analytics.subscribe("checkout_started", event => { 
  loadAddressValidatorScript();
});​

Is there anything wrong with the above migration? I know there are app blocks that does address validation and we have looked into them but we prefer to keep the same functionality that we have in prod if it is possible.

3. We can revert anytime before the August, 13th deadline right? And when we revert all the checkout.liquid code will be preserved. I am asking this because we are having hard time testing the GTM tags in staging and we can simply test them in production and revert if we notice any issues.

Thank you very much,

Ilke

[Wayne_Foster]

Thanks for the dialogue here and AMA - really helpful…

A few questions below:

1. Are there / can there be any plans to integrate the code into a GIT based VCS? I really don’t like working on production code within a text area on a web page…

2. What is the roadmap for consent mode 2.0 for Google products with Shopify native consent banners and tracking? Larger clients that breach the 1000 users/day for AI web beacon cookieless GA4 gap filling would benefit from this.

3. If we proxy all GA4 and Adwords tracking via Custom Pixels - assumption is we need to obtain both the true referrer and location and pass them on to the relevant tags. Are there any code examples of doing this via GTM - I’m thinking about the conversion linker in particular.

4. I think you may have touched on this on a previous comment - but can you confirm how Custom Pixel tracking works with shop.pay based transactions?

5. If we needed to add further events via GTM (e.g. tracking click events) - is it best to implement a custom event and proxy that into the Custom Pixel - rather than implementing a GTM instance in the parent DOM? I guess we’d need to ensure the custom pixel is loaded to allow that - do you have examples of how hat can be done?

6. Does the Custom Pixel iframe code have access to the parent documents cookies - read/write?

7. Can a parallel run be safely carried out using a Custom Pixel and legacy setup - wondered if the cookies could conflict (hence question #6)

8. Again - in relation to #6 - how do we pull in consent signals from a parent DOM widget into the Custom Pixel code?

9. This all still feels really raw - what percentage take up do you see across plus sites for migrating away from checkout.liquid 100%

10. If the payment elements are sandboxed in their own iFrames - this feels a little overkill to be constrained to another sandboxed iFrame - when many checkout components need access to the DOM for overlays - UX features / Debug overlays etc.

11. Does the Shopify native Google Sales channel implement its tracking using sandboxed iFrames - wondering if the choice of custom pixels vs native implementation carries a different technical approach.

Thanks so much for stepping up here - great to have an open line of dialogue with a technical expert!

[CMunro]

Hey Epats,

I tried this out in my own environment and ran into the same issue, so I spoke with Shopify and they will be updating their documentation, as this data is only available within the checkout_completed event.

[CMunro]

Hey Nicoladepoli,

I spoke to a contact at Shopify behind the scenes, and was told they do not yet have a solution for platforms other than Google for the custom pixel. In the app pixel, you will see the proper href.

The other alternative is to use the Shopify app supplied by the vendor, like Meta, TikTok, etc.

[Epats]

Hey CMunro,

Thank you so much for your quick response!

Unfortunately no, I previously tested this and it didn’t work.

Just now also tested it again on the checkout_completed event and the result is the same (attached screenshot).During the test I was logged in to the same account that is in the screenshots above, it has a few dozen purchases.

I had a theory that it has something to do with the fact that it’s a test order - but it also didn’t work, with real orders on working shop it also always returns 0. So it seems to me that this is some kind of bug.
But if you have any ideas how else I can test this - please let me know and I’d be happy to try it.

[CMunro]

Hey balaji,

This appears to be the same code that I’ve used successfully on client projects, so unfortunately I do not have any ideas as to why this would be throwing this error for you. Are you positive the source of this error is this GTM snippet? Without full context of your site, I might recommend adding in your GTM ID, subscribing to an event, and then using Shopify’s pixel tester to see if you can successfully submit a payload of data, and then loop back to that issue to further debug. I would also recommend Shopify’s support team if you continue to encounter issues—they are fabulously helpful!

[balaj]

Hi ,
Yes I am sure since the error was caught using the pixel tester and if
I deactivate this GTM custom pixel then the error goes away, that’s how I
am sure it’s because of the same.

[CMunro]

@balaj is there any additional code within your custom GTM pixel that you can provide? If not, are you attempting to inject code through GTM? Because custom pixels exist within an iframe and don’t have access to the DOM, there is a chance injected code will no longer function as expected.

[EricMainhard]

Hi @CMunro first of all thank you for this video !

I was wondering, I need to migrate some client checkout scripts to web pixels. As you know GTM is called once on the theme.liquid for events in the site, and another in the checkout.liquid for the checkout.

If I move the GTM to web pixels, should I combine checkout + theme scripts?

[CMunro]

Hey Sasank,

The issue you are experiencing is due to your use of the new customer accounts—web pixels do not yet track on these pages, but that functionality is currently in development.

To switch from new customer accounts to classic customer accounts, head into your shop settings panel, and then select customer accounts from the lefthand sidebar. From there you should see settings at the top of the page for toggling between the account types. Keep in mind that you will need liquid templated out for the classic account pages including registration and login.

[CMunro]

Hey Ilke,

1. The checkout.liquid layout file will be deprecated, so any liquid code contained within it will no longer be active, and you will need to migrate any functionality/conditions to either UI extensions, Shopify functions, or web pixels. The code in your checkout.liquid will continue to run on the order status/thank you page for about another year.
2. Web pixels are for tracking purposes. Additionally, they will not be able to manipulate the DOM, so you will need to look at building a UI extension for the functionality you are referencing. Alternatively, you could look to the app marketplace for address validation tools, and add these as app blocks to the checkout through your theme customizer. I would recommend the free Checkout Blocks app (https://apps.shopify.com/checkout-blocks), which comes with an address validator built in.
3. Yes, you’ll be able to revert your checkout back to liquid any time until the August deadline, and so long as you haven’t removed the checkout.liquid layout file from your theme code it will continue to work (until that August deadline).

[CMunro]

Hey Wayne_Foster,

Glad to hear you’re getting some value out of the discussion!

1. You can use the Shopify CLI to scaffold and deploy app pixels (https://shopify.dev/docs/apps/build/marketing-analytics/build-web-pixels), but Shopify has no plans to extend this functionality to custom pixels.
2. Google is migrating their native app to web pixels and will support cookiless pings. Timeline is completion by end of August. Today, the Google app will send consent mode v2 in regions where consent is required based on your customer privacy configurations and consent is given. It does not support the cookieless ping.
3. Location and referrer can be gleaned through these data points on the event: ‘page_location’: event.context.window.location.href, ‘page_referrer’: event.context.document.referrer
4. Shop.pay redirects to the /thank-you page on which the checkout_completed event fires.
5. It is recommended that you implement the pixel snippet within a custom pixel, and then publish new events from your theme code, and subscribe to those events within the custom pixel. I give an example of this in my video at the top of this thread.
6. Yes, custom pixels can set/get cookies, as well as interact with local storage on the top level frame (https://shopify.dev/docs/api/web-pixels-api/standard-api/browser).
7. I’m not entirely sure what you’re asking here, but I’ll take a stab at an answer: you can run the same pixel through both a legacy (theme code) implementation and new custom pixel implementation and they will both submit data, but then you will be double-tracking that data. If you are manipulating a cookie from both sides you will likely end up with a race condition. I would strongly advise against using both implementations of a single pixel.
8. If they are in a cookie, you can read that cookie, but I would recommend looking at Shopify’s Customer Privacy API, which provides this hookup out of the box. You can use their cookie consent banner or another 3P that is integrated with this API without having to set up any complex conditions (just set the type of pixel within the pixel settings).
9. I cannot speak to the platform as a whole, but at Domaine we’ve moved about 95% of our clients fully off of checkout.liquid.
10. Again, I cannot speak for Shopify, but I would say that this decision was not about adding another layer of security around payment, but instead it is a move to protect a shop’s data from potential bad actors in that pool of 3P integrations. By limiting their access to data, DOM scraping, etc, and placing them within an iframe, they are no longer able to inject code or grab on-site information, which in the worst cases, could be malicious.
11. App pixels are slightly different in that they are run off the main thread using web workers. This doesn’t change anything with regards to their access to data, but it does mean they will make your shop more performant if you have a lot running on your checkout.

[jkennedy]

Thanks for doing this @CMunro ! I’ve set up two custom pixels for our store - one for AvantLink and one for Google Ads - but my confusion is around the Customer Privacy section. Not sure if this dabbles too much into legal advice or outside the scope of custom pixels, but thought it was worth asking in case! Of course I won’t take anything as legal advice

We don’t currently show a cookie banner/preferences to US users (most of our traffic and sales are US). Shopify says in this case it probably doesn’t matte much if we set Permission to Required or Not Required. Do you have a recommendation for this?

Re: data sale, I’ve just set up the data sale opt out on our site for recommended regions, but I can’t quite tell what qualifies as data sale. Do Google Ads and/or AvantLink tools qualify as data sale? And if so, is the “Data collected qualifies as data sale” the more conservative/safe option to choose, or is “Data collected qualifies as data sale and supports limited data use” the way to go? Shopify said the second one is more conservative but I’m still confused and can’t find good support docs for it.

Any insights would be super appreciated! We upgraded our checkout yesterday and so far it’s been seamless, yay!

[Sasank]

Thanks for the reply, Connor.

The setting you mentioned doesn’t seem to be available in newly created stores. I can see it stores we created a while back. Would you know if there is any other way?

[Wayne_Foster]

Thanks for the detailed response - much appreciated. A couple of follow on refinements if I may…

#7 - We’ll need to prove to the business that the new Custom Pixel is working in line with the existing one - so was hoping to be able to run two GA4 pixels at the same time - one within the Custom Pixel - the other as it is today in theme & checkout.liquid. Can you see any issue here with conflicting cookie read / writes ? Have you done this to achieve a sense of readiness?

#1 & #11 - App pixels vs Custom pixels - what permissions do each have within the DOM / cookies - I thought I read somewhere that their permissions were different?

I think we’ll want to see some logging feature for errors - if that is where some users here have seen things fall through the cracks. Did you mention an expectation of when this feature may land?

Thanks for all the info - found out more here than all other articles put together. Great job.

[CMunro]

Hmm, sometimes Shopify is able to toggle a flag via their backend to enable/disable features on specific storefronts, so I would recommend reaching out to their support team with this request to see if that is a possibility.

[CMunro]

Hey Epats,

I’ve been able to find out the following: the checkout does not wait for the order to be created before showing the Thank You page (this trade off was made to increase the speed of the checkout). I wouldn’t think that this also applies to the customer object, but I could be wrong. I’ll try to flag this further with Shopify, but would encourage you to also seek out assistance from their support team. It may be helpful to note that I’ve also learned that Shopify is working on introducing a new field, isFirstOrder which will be more reliably used for new customer flows.

[CMunro]

7. On the projects I’ve worked through this on, we’ve had a separate development storefront for testing, so I haven’t done what you are contemplating. Have you considered spinning up a new GTM container (or similar), and testing them side by side, but delivering to separate destinations? This could help you avoid any clashes/muddying of the current “production” instance, while still having them in the same Shopify shop.

8. & 11. To be honest, my experience so far has only been in building custom pixels. I would refer you to this high-level documentation, which provides an overview of some of the differences. I would also say that given custom pixels use iframes and app pixels use web workers, neither will have any access to the DOM. It is probably worth noting here that there are DOM events that you can tap into (documentation).

Unfortunately, I do not have a timeline on when Shopify will be releasing the runtime error reporting functionality—sorry!