We’ve observed that Open edX currently lacks support for Google Tag Manager (GTM), which limits the flexibility of integrating analytics and marketing tools across platforms. Although custom theming or direct template overrides are possible, they’re not ideal for long-term maintainability or multi-tenant setups.
To address this, we’ve implemented native GTM support in our deployment - modeled after the existing GA4 integration. It’s:
Configurable via settings or site configuration, no code changes required.
Non-intrusive, with GTM disabled by default.
We’re preparing to contribute this upstream and would like your input:
Dear @Ihor_Romaniuk
We use GTM and integrate JavaScript logic to ensure that the Google Tag Manager (GTM) snippet executes only after the user has given consent for cookies.
I recommend reviewing both the GTM implementation and the cookie consent logic to ensure everything is aligned and functioning as intended.
As @Ihor_Romaniuk mentioned, we’re working on improving support for Google Tag Manager (GTM), and we’d like to share our proposed solutions. There are two pull requests related to this — please take a look and share your feedback. We’d really appreciate your feedback!
Hello, Stefania Trabucchi! Thank you for you response.
Currently there is no function to reject or consent for cookies.
The cookie banner on the edX platform serves a purely informative function.
It notifies the user about the website’s use of cookies and tracking technologies.
This also applies to GA4 (Google Analytics 4); its usage doesn’t require explicit user consent, but rather the information about its implementation is provided within the relevant policy (cookie or privacy policy).
When the user closes the banner (by clicking the “Close” button), the system interprets this as an acknowledgment that the banner has been viewed. Subsequently, the system stores this information to prevent the banner from reappearing for the same user.
What I want to highlight is the possibility to have custom GTM environments. This is important when you have to manage a complex configuration on GTM. Like test it before on DEV/STAGE environments before publishing to production. Just view our implementation and be inspired by it!
About the Google Tag Manager (GTM) and its integration with cookie consent.
IMO you shouldn’t depend the execution of GTM when you give cookie consent.
GTM has a built-in support for managing consent quite good. You can use a third party consent management tool that support “Google Consent Mode v2”, there are different solutions. You can view some of the possible solutions in this page: Tag Manager consent mode support - Tag Manager Help
We have different trackers that start when you give consent on our platform that are installed directly via GTM. So we don’t have to install them on every UI technology that we have, including Open edX.
For example we use GTM to start other tags, that are injected on RichieCMS and Open edX Django and MFE screens:
Google Analytics v4
Cookie Consent
Browser upgrade
Facebook tracking
Linkedin tracking
Support Widget
Maintenance banner
We also use custom dimensions on Google Analytics. On my last iteration on GTM, I moved that code to be calculated inside the GTM using a small JS, it parses the course id ex: course-v1:FCT+TPag+2024_T3 from the URLs, process and passes them to Google Analytics. With this you can have your Google Analytics metrics divided by Organization, Course code and edition. I also have a similar implementation on our marketing site.
As I mentioned in the frontend-platform PR, I don’t think it’s maintainable for us to support an arbitrary list of vendor script loaders - at least not in frontend land. It would be much better if, instead, we allowed operators to insert arbitrary javascript at build time.
In other words, we would love a PR that adds this configurability, but at the moment don’t think it’s a good idea to add support for vendor-specific scripts.
Hi @IvoBranco, thank you for your proposal and feedback!
In our GTM use cases, we’ve found the GOOGLE_TAG_MANAGER_ID field sufficient. It allows us to pass either a simple ID like GTM-XXXXXXX, or a full configuration string such as GTM-XXXXXXX>m_auth=abc>m_preview=env-1>m_cookies_win=x
for different environments via site configuration.
To keep the codebase clean, we decided to stick with this minimal implementation for now. However, if the community expresses the need for additional parameters or flexibility, we’re open to expanding support!