Checkout Extensibility Upgrade AMA: Custom Web Pixels with Domaine

[Jacqui]

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 [email protected]. Also, check out out these additional resources from Domaine about the Checkout Extensibility upgrade:

• Blog post
• White paper

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.
  

Check out our other Checkout Extensibility AMA's

[ns]

Thanks for this, here are our questions:

1. 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?

2. 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.

[CMunro]

Hey Ns,

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.

[balaj]

Hi Team, 

     Thanks for the above info, 
How can I access the below liquid tag or alternative

{% if first_time_accessed %}
  // Conversion scripts you want to run only once
{% endif %}

in the custom web pixels ? kindly please help with the same.

thank you,
balaji

[CMunro]

Hey Balaji,

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.

[JGTAOS]

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.

[CMunro]

Hey JGTAOS,

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!

[j-dubya]

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:

products: [
  {
      id: "",
      name: "",
      category: "",
      brand: "",
      variant: "",
      coupon: "",
      price: ,
      quantity:
  }
]

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';

Any assistance would be much appreciated.

Thanks

[CMunro]

Hey J-Dubya,

The product object can be found by drilling down into the data object and iterating over the checkout line items:

const products = data.checkout.lineItems.map(item => item.variant.product);

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.

[CMunro]

Sorry J-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). 🙂 

[dscnex]

Hi!

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.

Thanks!

[CMunro]

Hey Dscnex,

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.

[rossvor]

Hello,

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.

There are few threads about this:

How do we install Google Merhcant Center Opt-In Script now that "checkout scripts" is Depr...

Google Product Reviews Survey Opt-In Module Code for Order Conf page

Checkout Extensibility & Checkout UI Extension issue to load js script instead of additional scr...

Thanks

[CMunro]

Hey Rossvor,

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). 🙂 

[bansavagemyntr]

Hey thanks for reading my Qs!

So my understanding is each Web Pixel loads as its own <iframe> in the main browser document.

1. Is `event.context.window` the literal window of the iframe?
-OR- is the browser window that is holding the <iframe>, along with rest of theme code?
see: https://shopify.dev/docs/api/web-pixels-api/standard-events/checkout_completed

2. If GTM loads within a Web Pixel, would tags that interact with the DOM fail because of the <iframe> ?

3. Is it best practice to load 3rd party marketing scripts via Custom Pixels OR GTM?

4. Is there a benefit to loading GTM in a custom pixel vs in theme.liquid?

[CMunro]

Hey Bansavagemyntr,

1. The data provided by context.window is provided by the top-level frame of the browser, not the specific pixel iframe.
2. That is correct, you cannot interact with the DOM through a web pixel.
3. 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.
4. 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).

[alazortakoy]

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.

1. 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?
2. 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?
3. 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?
4. Do you know there is a plan to provide a Customer Event for the review and processing steps?
5. 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?
6. 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.)?

Thanks again,
Alaz Ortaköy

[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.

[Epats]

Hi and thank you for sharing your experience!

Have you encountered an issue when using init.data.customer.OrdersCount endpoint that it always returns 0?

I've tried several variations on several shops and it always returns zero, even though the account has a lot of orders.

Thank you in advance for your feedback!

[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. 🙂 

[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 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.

[Epats]

Hi Connor,

Thank you so much for your reply!

We've already tried to report this issue to Shopify support, but they only suggested to hire a Shopify expert to set it up. It is good to know that there will be a new endpoint that should fix this problem, so I guess we'll just need to wait till it will be rolled out.

Thanks again for all your help!

[nicoladepoli]

Hi!

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?

[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.

[balaj]

Hi Team, thanks for the answers,
               regarding the google GTM pixel or any other custom pixel,
reference gtm - https://help.shopify.com/en/manual/promoting-marketing/pixels/custom-pixels/gtm-tutorial 

when I add the example below code and test the pixel, it raise an error in console and pixel fails to send data.

error : Uncaught TypeError: Failed to construct 'URL': Invalid URL
kindly help me to mitigate the same . 

(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer', 'GTM-XXX')

Thank you.
balaji

[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.

[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.

[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.

[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?

[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. 

[Kenza_Iraki]

Hey @Sasank, Kenza from the Customer Accounts team at Shopify. Would love to better understand your use case behind firing off Pixels in the Order Status Page, would you be able to share more context?

To clarify, the new Order Status Page cannot be on the same domain as Checkout, this isn't something we're going to support moving forward. This is regardless of whether Classic or New customer accounts is selected in the settings.

We do plan to add support for Pixels in the Order Status Page within New customer accounts, but we're looking to get more context on the use cases here first.

[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:

<script src='https://{OUR-ID-HERE}.cloudfront.net/pobox_checker.js'></script>​

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

[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).

[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 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.

[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]

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.

1. & 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! 

[Wayne_Foster]

Yes - I think that could be our next steps.  We parallel ran GA4 and UA for 18 months - to serve a 12 month YoY comparison - so had lots of time to compare the metrics.  I'll look at doing the same here - setup a new GTM container as you say - then implement a separate GA4 account to see how attribution and conversion are aligning with the current liquid implementation.  If the GA4 cookies dropped are siloed to the domain of the iFrame - there should be no polution to the liquid version.  I'll look to pull through hostname, referer & document location - and explicitly set these on the GA4 tags - any other bits we need?

[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?

[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!

[Jacqui · Accepted solution]

AMA CLOSED

Thank you to all who participated in this AMA for Checkout Extensibility! No new questions will be accepted moving forward. 

The Domaine team will continue to respond to questions already asked as they are able, but some questions might not be answered. If your question goes unanswered you're welcome to post on our Shopify Plus board or our one of our other discussion boards.

Make sure you check out our Checkout Extensibility Upgrade board which has many FAQs and docs to help your business with the August 13th upgrade deadline.