Tracking a modal-only OIDC login flow without polluting your funnels

If your OIDC login flow renders inside a modal rather than a route, your analytics platform's default view tracking is already lying to you, and its default action naming is about to. Fix both before you trust a single funnel built on this flow.

Why the default instrumentation fails

Most web analytics — including SAP CDC's own event hooks in a lot of default integrations — infer a "page view" from a URL change and infer an "action name" from the visible text on whatever was clicked. A modal-hosted login flow breaks both assumptions on purpose, because that's the point of a modal: no navigation, no new URL, same page underneath.

View tracking. Screen 1 (email entry), screen 2 (password), screen 3 (MFA challenge) and screen 4 (success) all render at the same URL. Standard view tracking logs one page view for the entire flow, no matter how many screens the customer actually saw. You cannot build a step-by-step funnel out of a single event.

Action naming. A sign-in button auto-named from its visible text becomes a different action in every locale — "Sign in", "Se connecter", "Anmelden" — even though it's the same interaction. Ten locales turns one button into ten funnel steps that never roll up.

What to instrument instead

• Per-screen virtual views, fired on screen transition inside the modal, not on URL change — view: login_step, with a step property (email, password, mfa, success) rather than relying on the platform's automatic pageview.
• Locale-independent action names, keyed on a stable identifier (action_id: login_submit) rather than the button's rendered label, with the visible text passed as a separate property if you need it for debugging.
• A funnel built on the step property, not on distinct page URLs — this is the part most implementations skip, because it requires the funnel tool to support in-page steps rather than assuming one funnel step per URL.

Before and after

	Default instrumentation	Fixed instrumentation
View granularity	One view per modal open	One view per screen transition
Action naming	Auto-captured button text	Explicit action_id, locale-independent
Funnel built from	Distinct URLs	step property on a shared event
Cross-locale rollup	Fails — 10 languages, 10 actions	Works — 10 languages, 1 action

None of this requires changing the login flow itself, only what you point the analytics SDK at. It's the same fix that shows up whenever a critical flow is built as a component rather than a route — booking widgets and checkout modals have the exact same failure mode.

This sits at the Identify stage of the lifecycle: the login flow is where the profile becomes verified, and if you can't see where customers drop out of it, you can't improve identifier-first conversion at all.