Tracking Logins in Google Analytics (GA4)

The authentication layer is a critical point in the user lifecycle. It's the moment where anonymous traffic transforms into identifiable, high-value users. While Identity Providers (IdPs) and CIAM systems confirm who logged in, they rarely show how the user arrived at that decision or the friction they encountered.

Authentication Analytics Whitepaper. Practical guidance, rollout patterns and KPIs for passkey programs.

Get Whitepaper

Google Analytics 4 (GA4) is widely adopted for event-based analytics and many teams consider using it to track authentication flows. As outlined in Google's recommended events documentation, GA4 includes a standard login event that bridges pre-login acquisition data with post-login metrics, correlating authentication performance with business outcomes like AOV and CLV.

This article analyzes GA4's strengths and limitations for authentication analytics and provides implementation guidance.

Before implementing login tracking in GA4, it's important to understand what GA4 does well and where it falls short. GA4 is not a replacement for security audit logs or dedicated authentication analytics. It's a general-purpose behavioral analytics tool with specific trade-offs.

Let's start with the aspects where Google Analytics is really good at.

GA4's User-ID handling stitches together disparate sessions into a cohesive user profile. When a user authenticates, assigning their database ID to the user_id field lets GA4 retroactively associate pre-login browsing behavior with the signed-in user. This is something that most CIAM logs cannot do. Also, this enables questions like "Do users who browse more than five pages before logging in convert better?"

GA4's funnel exploration allows building ad-hoc funnels with segmentation after the fact. These can be broken down by browser version, device category or traffic source, revealing issues like a specific Chrome version causing social login failures.

GA4 facilitates dynamic audiences based on event sequences. A "High-Intent Users who failed Login" audience (e.g. users who added items to cart but abandoned the login) can be exported to Google Ads for re-engagement campaigns. This transforms login failure into a marketing opportunity.

GA4 connects authentication events to traffic sources, campaigns and user journeys. You can answer questions like "Which acquisition channels have the highest login success rates?" or "Do users from paid search struggle more with authentication than organic visitors?" This marketing context is absent from server-side auth logs.

For teams already using GA4, adding login events requires no additional licensing. The standard GA4 property (free tier) supports custom events, making it accessible for teams with limited budgets who want basic authentication visibility.

Besides these benefits, there are also some disadvantages of GA4 for login tracking.

GA4's cardinality limits (500 unique values per dimension) make tracking granular data problematic. Authentication systems can generate hundreds of distinct error codes, device fingerprints or user agents. Once the limit is hit, GA4 aggregates overflow values into "(other)", making root cause analysis impossible without schema simplification.

GA4 strictly prohibits PII collection (emails, usernames, phone numbers) in event parameters. You cannot look up "why did john.doe@example.com fail to log in?" in GA4. Individual user troubleshooting requires a separate system. Violating this policy risks account termination.

GA4 data has 24-48 hour processing latency for standard reports. If your SMS OTP provider goes down, GA4 won't surface the issue until the next day. Real-time incident response requires dedicated monitoring.

GA4's session timeout (default 30 minutes of inactivity) doesn't align with authentication sessions. As Simo Ahava explains, a user with a valid refresh token (technically "logged in" for days/weeks) appears as starting new sessions in GA4, inflating session counts.

GA4's free tier applies data sampling when queries exceed ~10M events. For high-traffic sites, login analytics may be based on sampled data. GA4 360 (paid) increases thresholds but doesn't eliminate sampling entirely.

GA4 offers Custom Insights for threshold alerts and calculated metrics. However, the number of calculated metrics is capped, not all custom dimensions work with insights and notification frequency is limited. Real-time alerting requires dedicated monitoring tools.

GA4 retains event-level data for 2-14 months (standard properties for max. 14 months). Historical analysis beyond this requires BigQuery export with storage and query costs.

Authentication flows spanning domains (e.g. from the main site to a social login provider and a callback) or using iframes for social login require careful GA4 cross-domain configuration. Misconfigurations result in inflated user counts and broken funnels.

Ad blockers frequently block GA4's gtag.js, causing underreporting. In GDPR regions, users who decline tracking are invisible to GA4. Your actual login success rate may differ from what GA4 reports.

GA4 provides no built-in authentication dashboards or success rate calculations out-of-the-box. Everything must be custom-built: events, parameters, explorations and calculated metrics.

Given GA4's constraints, a well-designed schema is essential. It must answer four questions:

1. Intent: Did the user attempt to enter the authentication flow?
2. Selection: What method did they choose (e.g. password, passkey, social login or SSO)?
3. Outcome: Did the login attempt succeed or fail?
4. Causality: If it failed, what was the categorized reason?

There are 3 basic events in GA4 related to authentication tracking.

• Trigger: When the user clicks "Sign In" or the login modal appears.
• Purpose: Establishes the "Top of Funnel". It's the denominator for calculating the Login Success Rate.

For passkey-first flows, fire when conditional UI (autofill) triggers or when the user clicks to start a regular passkey authentication flow.

• Trigger: Only when the backend returns success and a valid session token is issued.
• Purpose: The "Conversion." Mark as a "Key Event" in GA4 settings.

• Trigger: When the authentication provider returns an error or client-side validation fails.
• Purpose: This is critical for conversion rate optimization. A spike in login_failed relative to login_started indicates friction or a buggy implementation.
• Granularity: Track client-side validation errors too. Password complexity confusion is a UX failure.

Parameters must be registered as Custom Dimensions in GA4.

Google Tag Manager (GTM) decouples analytics from application code. Push semantic events to the dataLayer. GTM handles transformation and routing to GA4.

In the following, you'll find 3 code examples for pushing events to the dataLayer.

Login Start:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
    event: "auth_interaction",
    auth_action: "start",
    auth_location: "top_nav",
    c_device_support: "passkey_ready",
});

Login Success:

window.dataLayer.push({
    event: "auth_interaction",
    auth_action: "success",
    auth_method: "passkey",
    user_id: "uid_12345ABC",
});

Login Failure:

window.dataLayer.push({
    event: "auth_interaction",
    auth_action: "failure",
    auth_method: "password",
    error_category: "credential_mismatch",
    error_code: "401",
});

Build a weekly "Login Health" dashboard in GA4 Explorations focusing on these KPIs:

For comprehensive authentication dashboards beyond GA4's capabilities, see our authentication analytics playbook.

Four of GA4's limits survive any amount of schema design: the processing delay, the cardinality cap, the PII ban and the absence of built-in login reporting. No custom dimension gets you past them. Corbado Observe covers those four, and GA4 keeps the acquisition work it is genuinely good at.

The login event schema in section 3 exists because GA4 has no opinion about authentication. Observe arrives with one: a flow is modelled as subflows and steps across passkey, password, OTP, social and fallback, which is the four-question model of intent, selection, outcome and causality already answered.

Getting the data back out is a CSV export on Funnel, Friction and Passkey Errors, plus a data-export API against a project API key that returns one user's records by external ID for GDPR subject requests. For the weekly ritual, Executive Reporting mails a board view with its filters and time window to a project member on a weekly or monthly schedule.

The two tools split cleanly: GA4 owns attribution, audiences and the cross-device marketing journey, Observe owns the login itself.

GA4 is a useful starting point for login tracking. It provides marketing context (traffic sources, cross-device journeys, audience retargeting) that dedicated auth tools lack, and teams already using GA4 can add login events without additional cost.

However, the limitations covered in section 2.2 mean GA4 shouldn't be your only source of authentication visibility. The 24-48h latency, cardinality constraints and lack of real-time alerting make it unsuitable for operational monitoring.

Recommendations:

1. Design for cardinality from the start. Map internal error codes to simplified categories (section 3.2) before hitting GA4's limits.
2. Use GA4 for what it does well. Marketing attribution, funnel exploration and audience building for retargeting campaigns.
3. Pair with dedicated tools for operations. Real-time monitoring, granular error tracking and session debugging require purpose-built authentication analytics.
4. Export to BigQuery for advanced analysis. Time-to-Auth calculations and historical trends beyond GA4's 14-month retention window.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →

The login event is a recommended event in GA4 that fires when a user signs in successfully. It accepts a method parameter (e.g. "Google", "password", "passkey"). Most teams add custom events (login_started, login_failed) to build complete sign-in funnels.

Push events to the dataLayer via GTM or fire directly with gtag.js. Implement three events: login_started (user initiates auth), login (success) and login_failed (error). Include parameters like method, error_code and is_checkout.

Common causes:

1. Events not registered as Custom Dimensions
2. 24-48h processing delay
3. Ad blockers blocking gtag.js
4. Page redirects before event sends

Yes. Create a login_failed event with an error_code parameter using categorized failure reasons (e.g. bad_credentials, timeout). Avoid raw error strings to prevent hitting cardinality limits.

Formula: login events / login_started events. Build in GA4 Explorations using a funnel report or export to BigQuery.

Use both. GA4 provides behavioral context (e.g. traffic sources, cross-device journeys). Auth analytics tools provide real-time monitoring and granular error tracking. Together they provide complete visibility.