DC-474: fix missing analytics events on login pages

[adbergen]

🔗 Jira ticket

https://codeforamerica.atlassian.net/browse/DC-474

✍️ Description

On both DC and CO login pages, the domain-level "user initiated auth" event was missing — only the generic cta_click was firing. This left a gap in the auth funnel: analytics could see which button was pressed but not how many users entered the auth flow.

• DC (/login, email + OTP): LoginForm now fires otp_request immediately after client-side email validation passes and before the API call. Mirrors the existing pattern in VerifyOtpForm (which fires otp_request on resend, plus otp_challenge / otp_result).
• CO (/login, OIDC redirect to MyColorado): COLoginPage now fires a new oidc_start event the moment the user clicks either auth button. Naming is distinct from otp_request because the flows are mechanically different (OIDC handoff to an external IdP vs. portal-owned OTP) and analytics needs to compare the funnels independently. Confirmed in #DC-474 thread (Morgan: "No, I was saying in addition" — both cta_click and oidc_start should fire).
• Both CO buttons now carry data-analytics-cta (login_cta for the primary / current-language button, login_cta_alt_lang for the secondary / other-language button) so the existing global CTA delegation also picks them up.
• New OIDC_START constant added to packages/analytics/src/events.ts under the Authentication section.

🔗 Links to related PRs

None.

✅ Completion tasks

• Added relevant tests
• Meets acceptance criteria in ticket
• Configuration changes:
  • If new environment variables are added, update in Tofu (none added)
  • If new environment secrets are added, update in Tofu and set in AWS Secret Manager (none added)
  • If you're adding an appsetting, add it to the requisite example file, and update it in the AWS AppConfig (none added)
  • If appsetttings are changed, update in AWS AppConfig (none changed)

[adbergen]

QA Summary — feature/DC-474-login-page-events

What Changed

Added missing analytics events to the login pages for both DC and CO so the auth funnel can be measured end-to-end. Previously, only generic CTA-click tracking fired when users initiated sign-in; the domain-level "user started auth" event was missing in both states.

• DC /login — clicking Continue with a valid email now fires an otp_request event in addition to the existing cta_click.
• CO /login — clicking either of the two MyColorado log-in buttons now fires a new oidc_start event in addition to a cta_click. The two buttons are now distinctly tagged so analytics can tell English-language vs other-language clicks apart.

No UI changes are visible to users. The changes are purely instrumentation, observable in the browser's DevTools console and the analytics vendor (Mixpanel) Network requests.

Affected Areas

• DC sign-in landing page (email entry, "Continue" button)
• CO sign-in landing page (MyColorado log-in buttons, English and Spanish)
• Analytics event stream (Mixpanel, Amplitude, Google Analytics — whichever the environment has configured)

Test Cases

Happy Path — DC

1. Open dev DC sign-in page in a fresh browser session
2. Open DevTools → Console and run:

   document.addEventListener('digitalData:EventTracked', e => console.log('EVENT:', e.detail.eventName, e.detail.eventData))
   document.addEventListener('digitalData:PageViewed', e => console.log('PAGE:', e.detail.data?.name))

3. Enter a valid test email and click Continue
4. Expected console output, in order:
   • PAGE: Login
   • EVENT: cta_click { cta_id: "login_cta", cta_target: "Continue" }
   • EVENT: otp_request
   • PAGE: Verify OTP
5. Open the Network tab and filter for mixpanel (or whichever vendor is wired up). Confirm an additional track/ request fires between the cta_click and the /login/verify page load, with the event name otp_request in its decoded payload.

Happy Path — CO

1. Open dev CO sign-in page in a fresh browser session
2. Open DevTools → Console and paste the same two listener snippets from the DC test above
3. Click the primary MyColorado log-in button (the one in the user's current language)
4. Expected console output, in order:
   • PAGE: Login
   • EVENT: cta_click { cta_id: "login_cta", cta_target: "Log in with myColorado™" } (label depends on UI language)
   • EVENT: oidc_start
5. The browser then redirects to MyColorado — that part is unchanged.
6. Repeat from step 1, but click the secondary MyColorado button (the "other language" one)
7. Expected console output:
   • PAGE: Login
   • EVENT: cta_click { cta_id: "login_cta_alt_lang", cta_target: "..." }
   • EVENT: oidc_start
8. Confirm in the Mixpanel Network requests that oidc_start appears in the payload of one of the track/ calls after each button click.

Edge Cases

1. DC — submit Continue with an invalid email: Validation should fail before the submit. cta_click may still fire (it's a click), but otp_request should not fire because the form bails before the trackEvent call.
2. DC — submit Continue with a valid email when the API is rate-limited or down: otp_request should still fire (it's tracked before the API call). The error alert renders inline as before — no new analytics behavior on the error path.
3. CO — switch UI language mid-session, then click each button: The cta_id should remain login_cta for the primary button (current-language) and login_cta_alt_lang for the secondary button regardless of which language the user is in. The cta_target label should match the visible button text.

Regression Checks

1. DC — full sign-in flow still works: enter email → receive OTP → submit OTP → land on dashboard. No change to behavior, navigation, or error handling.
2. CO — full sign-in flow still works: click MyColorado button → land on PingOne → authenticate → return through /callback → land on dashboard. The redirect URL and language query param are unchanged.
3. Resend OTP on /login/verify — should still fire otp_request (already wired up before this change; verifying no regression).
4. All other CTA-tagged buttons throughout the app — generic cta_click event should continue to fire as before.

Test Credentials

• DC test persona (verified household) — sebt.dc+verified@codeforamerica.org — OTP delivered via the dev email pipeline. Any valid-format email works for testing the analytics event itself (the otp_request event fires before the API responds, so even a non-seeded address triggers it).
• CO test persona — sign-in happens through MyColorado (PingOne), not OTP. Use whatever MyColorado test account is provisioned for the CO dev environment. For analytics-only testing (this PR), the click itself fires the event before any redirect — no MyColorado account needed.

Environment Notes

• Test on dev DC and dev CO environments — these are the targets where analytics vendor tokens are wired up.
• Local dev (pnpm dev) typically has empty NEXT_PUBLIC_MIXPANEL_TOKEN / NEXT_PUBLIC_AMPLITUDE_API_KEY / NEXT_PUBLIC_SITEIMPROVE_ID, so vendor SDKs do not load and no Network requests fire. The console listener snippets above still work locally because they observe the data layer before the vendor bridges.
• If no track/ requests appear in the Network tab on a deployed environment, verify the corresponding NEXT_PUBLIC_* token is configured for that build.