Identify PostHog persons by Keycloak global_id, not Django pk

[ChristopherChudzicki]

What are the relevant tickets?

Part of https://github.com/mitodl/hq/issues/12601 (step 3)

Description (What does it do?)

Identifies PostHog persons by the Keycloak global_id instead of the Django user pk, so identities are globally unique across the MIT applications sharing a PostHog project.

How can this be tested?

1. I recommend adding a little client-side logging, here: (Posthog requests are encoded so hard to see)

   Add some logging

   diff --git a/frontend/public/src/store/posthogIdentify.js b/frontend/public/src/store/posthogIdentify.js
   index 2f55ff15..bd5a0609 100644
   --- a/frontend/public/src/store/posthogIdentify.js
   +++ b/frontend/public/src/store/posthogIdentify.js
   @@ -38,6 +38,7 @@ const posthogIdentifyMiddleware = () => (next: Function) => (action: any) => {
       // is an authenticated user who simply has no global id.
       if (currentUser && currentUser.is_anonymous) {
       if (posthog.get_property("$user_state") !== "anonymous") {
   +        console.log("Posthog resetting")
           posthog.reset()
       }
       } else if (currentUser && currentUser.global_id) {
   @@ -45,6 +46,7 @@ const posthogIdentifyMiddleware = () => (next: Function) => (action: any) => {
           environment: SETTINGS.environment,
           user_id:     currentUser.global_id
       })
   +      console.log("Posthog identifying as", currentUser.global_id)
       }
   }

2. Load pretty much any page... If you're logged in, you should see a "Posthog Identifying GUID" call using your users keycloak GUID

   • This includes /cart with ?ecom-service, which is a page Learn definitely cares about
   • Posthog does NOT currently work (before or after this PR) on financial aid pages.

3. If you log out in the same browser, you should see it "reset".

Additional Context

Identify moved out of Header.js into a redux-query store middleware (store/posthogIdentify.js) keyed on a successful /api/v0/users/current_user/ response, so it fires wherever that data loads regardless of which webpack bundle triggered it. Header.js was the wrong layer — it's suppressed on cart, orders, records, and anything with ?ecom-service, so those pages never identified even though App.js already fetched the user there. base.html wraps only {% block headercontent %} in the suppression conditional and index.html renders the root bundle inside {% block content %}, so /cart?ecom-service keeps identifying.

global_id is now also used for the feature-flag person properties (TopBar, CourseProductDetailEnroll) and for server-side flag evaluation (CheckoutInterstitialView, HomePage) — ol-django's _get_person_properties derives user_id from opt_unique_id, so client identify, client flag overrides, and server-side person_properties now agree on one value.

The email/name person properties the old DashboardPage identify sent are dropped deliberately; we don't set them anywhere else.

Still uncovered: pages where the template suppresses the header and only the django bundle loads (/certificate/*, /checkout/*, Wagtail pages with ?ecom-service). That bundle never reaches posthog.init() — a module side effect in lib/util.js — and each webpack entry gets its own posthog instance, so identify() there is a no-op regardless of the caller. Not worth closing: certificate pages moved to the Next.js site, /checkout/ is a transient redirect, and the financial-aid form is rare.

Companion xPro PR for step 4: mitodl/mitxpro#4025

[github-actions]

OpenAPI Changes

Show/hide changes

## Changes for v0.yaml:
No changes detected

## Changes for v1.yaml:
No changes detected

## Changes for v2.yaml:
No changes detected

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

[ChristopherChudzicki]

This is the only use of the user var above. It's for checking a feature flag.

[gumaerc]

👍