Discussions

The Cart page applies a Content Security Policy (CSP) that is more restrictive than the rest of the site. This CSP blocks our Google Tag Manager (GTM) container from loading, which prevents us from tracking form submissions as part of the final checkout step on the only page where this interaction can be captured.

Note: this appears to only occur on logged-in sessions. When browsing the same Cart page anonymously, GTM loads as expected — the stricter CSP only seems to be applied once the user is authenticated.

What we are seeing

• Across the rest of the site, the GTM script (https://www.googletagmanager.com/gtm.js?id=GTM-MJMVRPF) loads successfully and tracking works as expected.
• On the Cart page (logged-in), the request to googletagmanager.com is blocked. The browser DevTools Network panel shows the gtm.js request failing, and the Console reports a CSP violation refusing to load the script.
• Because GTM does not load on this page, no downstream tags fire — including the form-submission event we need to track completion of the final checkout step.

Impact

We cannot record checkout form submissions or attribute conversions to marketing activity. This is a blocker for the analytics and advertising setup we are rolling out for Shop! ANZ.

What we are asking

1. Confirm where the CSP for the Cart page (Cart_Home.aspx) is configured within iMIS, and why it differs from the policy applied on other pages.
2. Update the CSP applied to the Cart page so that scripts from the following hosts are permitted (these are the standard Google Tag Manager / Google Analytics endpoints):
   • https://www.googletagmanager.com
   • https://www.google-analytics.com
   • https://*.analytics.google.com
   • https://*.googletagmanager.com
3. Ideally, align the Cart page CSP with the policy used elsewhere on the site so behaviour is consistent across the user journey.

If a CSP change is not possible, please advise whether there is a supported way to inject GTM (or a server-side equivalent) into the Cart_Home.aspx template for logged-in users, or any iMIS-native mechanism for emitting a checkout form-submission event that we could hook into instead.

I have a screenshot of the issue too, but unable to paste here.