Checkout completed and account created GTM events

[dsubak]

Description (What does it do?)

Adds an account created and checkout completed GTM event. Both events have analogs tracked serverside (in a middleware and in hubspot mitxonline tracking code, respectively) but since we can't easily fire GTM events outside of the browser, we needed another approach. I did a bit of poking around Learn+the codebase and a bit of prompting to try and see if there were any more obvious and better approaches, but ultimately figured I'd be better off just sending a PR to folks to validate my thinking.

For account creation, this attempts to hook into onboarding since in testing after registering a new user I got kicked over to the onboarding flow. We use a bit in the session to track whether or not you've already been tracked since it's a multistep process.

For checkout completed, we hook into the enrollment redirect. Here we check a few things about the request and receipt (namely that they're paid and the order isn't pending) and then track the event - there's a useRef to attempt to keep it from firing multiple times, but I'm not entirely sure if it's necessary or if that's a reasonable thing to use.

How can this be tested?

It's a pain! You'll need access to the google tag manager account and to have the GTM values from prod in frontend.local.env for a full-fat test. See gtm.md for the values you need.

If you're not already set up, I recommend the alternative tests laid out. They're not perfect, but they are good enough to validate that it doesn't break anything and that it does fire the event.

Account Created

For either version of the test you'll want to use a fresh incognito browser since we store a bit in the session to keep the event from firing more than once during an onboarding flow.

Full Test

• Visit https://tagmanager.google.com/?authuser=1#/container/accounts/6351372910/containers/250259136/workspaces/19. Click Preview and enter whatever hostname you use for your local machine (i.e. http://learn.odl.local:9080).
• Visit your local, hit the Log In button and go through the Keycloak registration redirection and flow. You should be returned to the Onboarding wizard once you successfully complete the registration process.
• The Google Tag Assistant tab should have an account-created event for the second pageload:

Test w/o GTM setup or account:

• Visit your local, open the console and enter window.dataLayer - it should NOT show an account-created event.
• Hit the Log In button and go through the Keycloak registration redirection and flow. You should be returned to the Onboarding wizard once you successfully complete the registration process.
• Open your console again and examine window.dataLayer. It should now have an additional entry for the account-created event. This is as good an analog as you'll be able to get without a full setup.

Checkout Completed

Test w/o GTM setup or account

This is slightly scuffed, but should be representative.

• Ensure you've got a paid order for a user you're logged in as.
• Visit your local, open the console and enter window.dataLayer - it should NOT show an checkout-completed event.
• Next, visit http://learn.odl.local:9080/dashboard?order_status=fulfilled&order_id=<order_pk>
• Open the console and enter window.dataLayer, it should now show an checkout-completed with values corresponding to the order you specified.

In theory, it should be testable if you have a full e2e checkout workflow set up between learn and mitxonline but I've yet to verify it in tag assistant.

[github-actions]

OpenAPI Changes

No changes detected

View full changelog

Unexpected changes? Ensure your branch is up-to-date with main (consider rebasing).

[cp-at-mit]

Seems good to me

[Copilot]

Pull request overview

Adds GTM tracking for account creation and completed paid checkouts.

Changes:

• Adds and tests two GTM event helpers.
• Triggers account-created tracking during onboarding.
• Triggers checkout-completed tracking after enrollment redirects.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
frontends/main/src/common/analytics/gtm.ts	Defines the new GTM events.
frontends/main/src/common/analytics/gtm.test.ts	Tests event payload generation.
frontends/main/src/app-pages/OnboardingPage/OnboardingPage.tsx	Emits account-created during onboarding.
frontends/main/src/app-pages/OnboardingPage/OnboardingPage.test.tsx	Tests onboarding event deduplication.
frontends/main/src/app-pages/DashboardPage/EnrollmentRedirectAlert.tsx	Emits checkout-completed from receipt data.
frontends/main/src/app-pages/DashboardPage/EnrollmentRedirectAlert.test.tsx	Tests checkout event behavior.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[daniellefrappier18]

this effect will fire trackAccountCreated() whenever /onboarding renders with a loaded profile and the sessionStorage key isn't already set but it has no "this account was just created" signal so it fire for existing users.

Screen.Recording.2026-08-27.at.2.37.06.PM.mov

[dsubak]

Good callout - I was operating on the assumption that the main way folks are gonna encounter /onboarding is via redirection after account creation and that afterwards you're pretty unlikely to go to that page, but I'll double check that.

If it turns out we actually get a lot of return visitors to that path this is gonna need something a bit more involved to get right

[daniellefrappier18]

You could have he backend pass an explicit signal through the redirect e.g. append ?new=1 alongside next in CustomLoginView.get (mirroring the existing skip_onboarding=1 pattern) and gate trackAccountCreated() on that param instead of relying on sessionStorage alone. Keep the session-storage check only to prevent re-firing within a single legitimate new-account flow, not as the sole gate for "is this a new account" at all.

[daniellefrappier18]

I was operating on the assumption that the main way folks are gonna encounter /onboarding is via redirection after account creation

You are probably correct and this edge case is not likely which is why I approved the PR to come up. I just wanted to call it to you attention.

[dsubak]

Ah, I didn't realize we already have a has_logged_in bit on the backend that appears correct - I'll get a query param piped in based on that and that ought to address the issue.

[daniellefrappier18]

I was able to verify the testing path w/o GTM setup

But something you should probably look at before merging is account-created fires for existing users, not just new account. See my comment above