Tracking Logins in Google Analytics (GA4)

Authentication Analytics Whitepaper:
Track passkey adoption & impact on revenue.

Get Whitepaper

The authentication layer is a critical juncture in the user lifecycle: the boundary where anonymous traffic transforms into identifiable, high-value users. While Identity Providers (IdPs) and CIAM systems provide security infrastructure, they often operate as "black boxes" regarding user behavior. They confirm who logged in, but rarely show how the user arrived at that decision or the friction they encountered.

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 and can bridge pre-login acquisition data with post-login retention metrics. This allows organizations to correlate authentication performance with business outcomes like AOV and CLV.

This article analyzes how GA4 can be used for login tracking, examines its strengths and limitations for authentication analytics and provides implementation guidance for teams considering this approach.

Before implementing login tracking in GA4, it's essential 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.

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 - something CIAM logs cannot do. 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 auth) 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 or infrastructure. The standard GA4 property (free tier) supports custom events, making it accessible for teams with limited budgets who want basic authentication visibility.

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

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

GA4 data has 24-48 hour processing latency for standard reports and explorations. If your SMS OTP provider goes down or a deployment breaks passkey authentication, 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. This creates confusion when analyzing "logged-in user" behavior and inflates session counts.

GA4's free tier applies data sampling when query results exceed thresholds (typically 10M events). For high-traffic sites, this means login analytics may be based on sampled data rather than complete records. GA4 360 (paid) increases thresholds but doesn't eliminate sampling entirely.

GA4 offers Custom Insights that can send email notifications when metrics cross thresholds or anomalies are detected. You can also create calculated metrics (e.g. login / login_started for Login Success Rate) and monitor them via Custom Insights. However, practical limitations exist: the number of calculated metrics per property is capped, not all custom dimensions work with insights, condition complexity is restricted and notification frequency is limited. For real-time alerting with sub-minute response times, teams typically still need dedicated monitoring tools.

GA4 retains event-level data for 2-14 months depending on settings (standard properties max at 14 months). Historical analysis beyond this window requires BigQuery export, which incurs storage and query costs. Long-term authentication trend analysis becomes expensive.

Authentication flows often span domains (main site -> auth provider -> callback) or use iframes (social login popups). GA4's cross-domain tracking requires careful configuration, and iframe-based flows may break session continuity. Misconfigurations result in inflated user counts and broken funnels.

Ad blockers and privacy tools frequently block GA4's gtag.js, causing underreporting of login events. In regions with strict consent requirements (GDPR), users who decline tracking are invisible to GA4 entirely. Your actual login success rate may differ significantly from what GA4 reports.

GA4 provides no built-in authentication dashboards, success rate calculations or error categorization. Everything must be custom-built: events, parameters, explorations and calculated metrics. Teams unfamiliar with GA4's data model face a steep learning curve.

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 (Password, Passkey, Social, SSO)?
3. Outcome: Did the attempt succeed or fail?
4. Causality: If it failed, what was the categorized reason?

1. login_started

• Trigger: When the user clicks "Sign In" or the login modal renders.
• Purpose: Establishes "Top of Funnel" - the denominator for calculating Login Success Rate.
• Passkey context: For passkey-first flows, fire when conditional UI (autofill) triggers.

2. login_succeeded (or standard login)

• 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.
• Standardization: Use the event name login for compatibility with built-in features.

3. login_failed

• Trigger: When the auth provider returns an error or client-side validation fails.
• Purpose: Critical for CRO. A spike in login_failed relative to login_started indicates friction.
• Granularity: Track client-side validation errors too - password complexity confusion is a UX failure.

Parameters must be registered as Custom Dimensions in GA4.

Method Parameter Strategy:

In multi-step flows (Identifier First), method might not be known at login_started. Send method: unknown initially, or method: google immediately if the user clicks "Sign in with Google." For passkeys, distinguish passkey_autofill vs passkey_modal to understand discovery patterns.

Error Code Taxonomy Example:

• AuthError-5001 (Database timeout) -> server_error
• AuthError-401 (Bad credentials) -> bad_credentials
• WebAuthnError-NotAllowed -> biometric_cancelled

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

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'
});

GTM Configuration:

1. Triggers: Custom Event Trigger for auth_interaction.
2. Variables: Data Layer Variables for auth_action, auth_method, error_category, user_id, c_device_support.
3. Tags: GA4 Event tag with Lookup Table mapping auth_action to event names (start -> login_started, success -> login, failure -> login_failed).

A funnel exploration visualizes completion rates and identifies where users abandon the process.

1. New vs. returning Users:

• New: First session date in selected range.
• Returning: First session date before selected range.
• Low returning user success rate indicates "Remember Me" or session persistence issues.

2. Acquisition Channel:

• Segment by Session source/medium.
• High failure rates from Email traffic may indicate broken Magic Link or Reset Password flows.

3. "Passkey ready" Cohort:

Compare "Passkey Capable Devices" (c_device_support = passkey_ready) against legacy devices to demonstrate passkey efficacy before full rollout.

A "Login Health" dashboard should be reviewed weekly to ensure authentication isn't bleeding revenue.

KPI 1: Login Success Rate (LSR)

• Formula: login events / login_started events.
• Benchmark: Password flows: 50-60%. Passkey flows: >93%.
• Visualization: Time-series line chart. Watch for dips correlating with deployments or API outages.

KPI 2: Failure Pareto

• Horizontal bar chart of login_failed by error_code.
• If "System Error" or "Timeout" enters top 3, trigger P0 engineering ticket.

KPI 3: Time-to-Auth (TTA)

• Requires BigQuery export to calculate timestamp difference.
• Passkeys reduce TTA from ~30s to ~8s.

GA4 has limitations in sampling, reporting delay and PII handling. Pair it with a specialized authentication analytics layer for complete visibility.

While GA4 provides valuable behavioral insights, it lacks the depth required for real-time authentication observability. Corbado's telemetry SDK fills this gap by capturing authentication events at the source - regardless of method (passkeys, passwords, social login, magic links or OTP).

Corbado automatically instruments every authentication touchpoint:

• Real-time success/failure rates by method, device and browser - no manual event schema required.
• Error categorization with full context (WebAuthn error codes, API response times, credential validation failures).
• Funnel visualization from session start through authentication completion, with automatic drop-off detection.
• Latency percentiles (p50, p95, p99) for each authentication step, enabling SLA monitoring.

Corbado's analytics layer addresses GA4's core limitations:

• No cardinality limits: Track granular error codes and device fingerprints without hitting dimension caps.
• Sub-second latency: Real-time dashboards and alerting for immediate incident response.
• PII-safe user lookup: Troubleshoot individual authentication sessions without exposing sensitive data in GA4.
• Token lifecycle tracking: Monitor refresh token usage, session expiration patterns and silent re-authentication flows.

Corbado's telemetry integrates with your analytics infrastructure:

• GA4 Measurement Protocol: Push aggregated auth health metrics to GA4 for unified reporting.
• Webhook events: Stream authentication events to your data warehouse (BigQuery, Snowflake, Redshift).
• Alerting: Configure Slack, PagerDuty or email alerts for anomaly detection (sudden LSR drops, error spikes).

By combining GA4's behavioral context with Corbado's authentication-specific observability, teams gain complete visibility into the sign-in funnel - from marketing attribution through successful conversion.

GA4 can be a useful tool for login tracking, but it's important to understand its trade-offs. It excels at behavioral context - cross-device tracking, funnel exploration and audience retargeting - but has significant limitations for authentication-specific use cases.

Key takeaways:

• GA4 provides marketing context: Traffic sources, user journeys and audience building capabilities that dedicated auth tools lack.
• GA4 has significant limitations: Cardinality constraints, 24-48 hour latency, no native alerting, data sampling and PII restrictions make it unsuitable as a sole authentication analytics solution.
• Schema design is critical: Map internal error codes to simplified categories and design parameters around GA4's cardinality limits from the start.
• Consider pairing with specialized tools: For real-time monitoring, granular error tracking and individual session troubleshooting, dedicated authentication analytics complements GA4's strengths.

GA4 works best as one component of an authentication analytics strategy - providing behavioral and marketing context while purpose-built tools handle operational monitoring and debugging.

The login event is a recommended event in GA4 that fires when a user successfully signs in. It accepts a method parameter (e.g. "Google," "password," "passkey") to identify the authentication type. While GA4 provides this standard event, most teams implement additional custom events (login_started, login_failed) to build complete sign-in funnels.

Push events to the dataLayer via Google Tag Manager or fire them directly with gtag.js. For a complete funnel, implement three events: login_started (when the user initiates auth), login (on success) and login_failed (on error). Include parameters like method, error_code and is_checkout for segmentation.

Common causes include: (1) Events not registered as Custom Dimensions in GA4 Admin, (2) 24-48 hour processing delay for standard reports, (3) ad blockers preventing gtag.js from firing, (4) race conditions where page redirects before the event sends. Use GA4 DebugView or Real-time reports to verify events are received.

Yes. Create a custom login_failed event that fires when authentication returns an error. Include an error_code parameter with categorized failure reasons (e.g. "bad_credentials," "timeout," "biometric_cancelled"). Avoid raw error strings to prevent hitting GA4's cardinality limits.

Calculate Login Success Rate (LSR) as: login events / login_started events. Build this in GA4 Explorations using a funnel report or export to BigQuery for precise calculations. Benchmark: password flows typically achieve 50-60% LSR; passkey flows exceed 93%.

Consider using both. GA4 provides behavioral context (traffic sources, cross-device journeys, audience building) that auth-specific tools lack. Dedicated auth analytics (like Corbado) provide real-time monitoring, granular error tracking and PII-safe troubleshooting that GA4 can't offer. Together, they provide complete visibility.