--- url: 'https://www.corbado.com/blog/tracking-logins-google-analytics-ga4' title: 'Tracking Logins in Google Analytics (GA4)' description: 'Model and track login events in Google Analytics GA4 so you can build a clear sign-in funnel, cohorts and experiments for authentication flows.' lang: 'en' author: 'Vincent Delitz' date: '2026-01-02T13:51:49.305Z' lastModified: '2026-08-25T14:00:46.912Z' keywords: 'ga4 login event, track login in ga4, google analytics, ga4, sign-in funnel ga4, login analytics ga4' category: 'Authentication' --- # Tracking Logins in Google Analytics (GA4) ## Key Facts - **GA4** includes a standard **`login` event** that bridges **pre-login acquisition data** with **post-login retention metrics** - It provides **marketing context** like **traffic sources** and **cross-device user journeys** that dedicated auth tools lack - **GA4** has significant limitations including **24-48 hour processing latency**, **cardinality constraints** and **PII restrictions** - Complete **sign-in funnels** require **custom events** (`login_started`, `login_failed`) beyond the standard login event - **GA4** works best when paired with **dedicated authentication analytics tools** for **real-time monitoring** ## 1. Introduction: Using GA4 to track Login Events 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. 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](https://support.google.com/analytics/answer/9267735?hl=en), 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](https://www.corbado.com/blog/authentication-analytics-playbook) and provides implementation guidance. ## 2. Strengths and Limitations of GA4 for Login Tracking 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](https://www.corbado.com/blog/authentication-analytics-playbook). It's a general-purpose behavioral analytics tool with specific trade-offs. ### 2.1 Strengths of GA4 for Login Tracking Let's start with the aspects where Google Analytics is really good at. #### 2.1.1 GA4 User-ID for Cross-device Tracking 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](https://data.ga4spy.com/ga4-events-parameters) 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?" #### 2.1.2 GA4 Funnel Exploration for Login Analysis GA4's [funnel exploration](https://support.google.com/analytics/answer/9327974?hl=en) 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](https://www.corbado.com/glossary/social-login) failures. #### 2.1.3 Audience Triggering and Retargeting 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. #### 2.1.4 Marketing Attribution Context 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. #### 2.1.5 No Additional Tooling Cost 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. ### 2.2 Limitations of GA4 for Login Tracking Besides these benefits, there are also some disadvantages of GA4 for login tracking. #### 2.2.1 GA4 Cardinality Limits and Error Codes 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. #### 2.2.2 PII Restrictions in GA4 Event Parameters GA4 strictly prohibits PII collection (emails, usernames, phone numbers) in event parameters. You cannot look up "why did [john.doe@example.com](mailto:john.doe@example.com) fail to log in?" in GA4. Individual user troubleshooting requires a separate system. Violating this policy risks account termination. #### 2.2.3 GA4 Processing Latency (24-48 Hours) GA4 data has [24-48 hour processing latency](https://analytify.io/ga4-custom-events-not-showing-up-in-reports/) 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. #### 2.2.4 GA4 Session Timeout vs Auth Token Lifecycle GA4's session timeout (default 30 minutes of inactivity) doesn't align with authentication sessions. As [Simo Ahava explains](https://www.simoahava.com/analytics/implementation-guide-events-google-analytics-4/), a user with a valid refresh token (technically "logged in" for days/weeks) appears as starting new sessions in GA4, inflating session counts. #### 2.2.5 GA4 Data Sampling 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. #### 2.2.6 Limited Alerting Capabilities GA4 offers [Custom Insights](https://support.google.com/analytics/answer/9443595) for threshold alerts and [calculated metrics](https://support.google.com/analytics/answer/10250459). 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. #### 2.2.7 GA4 Data Retention Limits 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. #### 2.2.8 Cross-domain and Iframe Tracking Issues Authentication flows spanning domains (e.g. from the main site to a [social login](https://www.corbado.com/glossary/social-login) provider and a callback) or using [iframes](https://www.corbado.com/blog/iframe-passkeys-webauthn) for [social login](https://www.corbado.com/glossary/social-login) require careful GA4 cross-domain configuration. Misconfigurations result in inflated user counts and broken funnels. #### 2.2.9 Ad Blocker Impact on GA4 Login Events 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](https://www.corbado.com/blog/authentication-observability) may differ from what GA4 reports. #### 2.2.10 No Built-in Authentication Dashboards 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. ## 3. Designing a Login Event Schema for GA4 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](https://www.corbado.com/blog/passkeys-single-sign-on-sso))? 3. **Outcome:** Did the login attempt succeed or fail? 4. **Causality:** If it failed, what was the categorized reason? ### 3.1 Core Events: login_started, login_succeeded, login_failed There are 3 basic events in GA4 related to authentication tracking. #### 3.1.1 Login started - **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](https://www.corbado.com/blog/authentication-observability). For passkey-first flows, fire when [conditional UI](https://www.corbado.com/glossary/conditional-ui) (autofill) triggers or when the user clicks to start a regular passkey authentication flow. #### 3.1.2 Login succeeded - **Trigger:** Only when the backend returns success and a valid session token is issued. - **Purpose:** The "Conversion." [Mark as a "Key Event"](https://www.analyticsmania.com/post/google-analytics-4-key-events-not-working/) in GA4 settings. #### 3.1.3 Login failed - **Trigger:** When the authentication provider returns an error or client-side validation fails. - **Purpose:** This is critical for [conversion rate](https://www.corbado.com/blog/logins-impact-checkout-conversion) optimization. A spike in `login_failed` relative to `login_started` indicates friction or a buggy implementation. - **Granularity:** [Track client-side validation errors too](https://www.analyticsmania.com/post/how-to-track-events-with-google-analytics-4-and-google-tag-manager/). Password complexity confusion is a UX failure. ### 3.2 GA4 Custom Dimensions for Login Events Parameters must be [registered as Custom Dimensions](https://developers.google.com/analytics/devguides/collection/ga4/event-parameters) in GA4. | **Parameter** | **Type** | **Example Values** | **Purpose** | | ---------------- | -------- | --------------------------------------- | ----------------------------------------------------------------------------------------- | | method | String | password, passkey, google, sso | Compare the success rates by authentication method | | error_code | String | wrong_password, timeout, biometric_fail | Categorize the failure reason | | is_checkout | Boolean | true, false | Indicates whether this login is within the checkout flow (see e-commerce funnel analysis) | | user_type | String | new, returning | Indidcates if it's a first-time sign-up vs. a repeat login | | c_device_support | String | passkey_ready, legacy | Device passkey/biometric capability | | login_location | String | header, checkout, sidebar | UI component where login initiated | ## 4. Implementing Login Events: GTM and dataLayer Push Google Tag Manager (GTM) decouples analytics from application code. Push semantic events to the [dataLayer](https://www.analyticsmania.com/post/data-layer-variable/). GTM handles transformation and routing to GA4. In the following, you'll find 3 code examples for pushing events to the dataLayer. **Login Start:** ```javascript window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: "auth_interaction", auth_action: "start", auth_location: "top_nav", c_device_support: "passkey_ready", }); ``` **Login Success:** ```javascript window.dataLayer.push({ event: "auth_interaction", auth_action: "success", auth_method: "passkey", user_id: "uid_12345ABC", }); ``` **Login Failure:** ```javascript window.dataLayer.push({ event: "auth_interaction", auth_action: "failure", auth_method: "password", error_category: "credential_mismatch", error_code: "401", }); ``` ## 5. GA4 Login Dashboard: Key Metrics to Monitor Build a weekly "Login Health" dashboard in GA4 Explorations focusing on these KPIs: | KPI | Formula | Benchmark | | ---------------------------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------------- | | **Login Success Rate (LSR)** | `login` / `login_started` | Password: 50-60%, Passkeys: >93% | | **Failure Distribution** | `login_failed` by error_code | Alert if a system error enters the top-3 errors | | **Time-to-Auth (TTA)** | Requires [BigQuery export](https://datajournal.datakyu.co/flatten-ga4-bigquery-export-schema/) | Passkeys: \~8s vs Password: \~30s | For comprehensive authentication dashboards beyond GA4's capabilities, see our [authentication analytics](https://www.corbado.com/blog/authentication-analytics-playbook) playbook. ## 6. How Corbado can help 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](https://www.corbado.com/observe) covers those four, and GA4 keeps the acquisition work it is genuinely good at. [Video: Login overview](https://www.corbado.com/videos/features/login-overview.mp4) ([See Login Overview in Corbado Observe](https://www.corbado.com/observe/login-overview)) | GA4 Limitation | What Corbado Observe gives you | | -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | 24-48h latency (section 2.2.3) | The Events page polls its own ingest stats every 60 seconds, so a deploy that stopped sending events is visible while you watch | | 500-value cardinality cap (section 2.2.1) | Passkey Errors groups failed ceremonies into flavours keyed on subflow type, step name, error name, message, code, spec type, trigger and a duration bucket | | No PII lookup (section 2.2.2) | User Search replays one user's journey from opaque IDs: a user ID, your own external ID, a flow ID or a security-key serial number | | No built-in auth dashboards (section 2.2.10) | Login Overview, Funnel, Friction and Login Methods are shipped pages, so the schema work in section 3 is not yours to design | 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. ## 7. Conclusion 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. ## FAQ ### What is the GA4 Login Event? The `login` event is a [recommended event](https://support.google.com/analytics/answer/9267735?hl=en) 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. ### How do I track Login Events in GA4? 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`. ### Why aren't my GA4 Login Events showing up? 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 ### Can I track failed Logins in GA4? 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. ### How do I calculate Login Success Rate in GA4? Formula: `login` events / `login_started` events. Build in GA4 Explorations using a funnel report or export to BigQuery. ### GA4 vs dedicated Auth Analytics: Which should I use? 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.