The session_start event is GA4’s foundational event — it marks the beginning of every session and powers your session counts, engagement rate, average session duration, and traffic source attribution. When it stops firing or fires inconsistently, your GA4 data becomes unreliable at a fundamental level.
Missing or inconsistent session_start events is a pattern we see periodically across client properties, often after a GTM update, GA4 configuration change, or website deployment. This guide covers the most common causes and how to fix each one.
What session_start Is and When It Should Fire
GA4 automatically fires session_start at the beginning of each new session — specifically, when the first event of a session is processed. It’s an automatically collected event: you don’t fire it manually, and you don’t configure it in GTM. GA4’s JavaScript library handles it.
A session in GA4 starts when:
- A user visits your site and the GA4 tag fires for the first time
- A user returns after 30 minutes of inactivity (configurable in GA4 Admin → Data Streams → Session timeout)
- A user returns after midnight (new calendar day)
How to check in DebugView: GA4 Admin → DebugView. Open your site on the test device. Within a few seconds, you should see session_start appear in the event stream (usually as the first or second event, immediately after page_view).
Cause 1: Multiple GA4 Configuration Tags Firing
The most common cause of missing or doubled session_start events is having more than one GA4 Configuration tag (or gtag('config', ...) call) active on the same page.
How it happens: A developer adds a gtag.js snippet directly to the HTML while a GTM-managed GA4 Configuration tag is also running. Or there are two separate GTM workspaces/versions with duplicate GA4 tags. Or a GA4 tag exists in both GTM and a third-party analytics platform that also fires GA4 events.
What it causes: Two competing GA4 instances can interfere with each other’s session management. One instance starts a session; the other creates a conflicting state. The result is missing session_start in one of the streams, doubled page views, or sessions that register as 0 seconds engagement time.
How to diagnose: In Chrome DevTools → Network → filter by google-analytics.com or gtm. Count how many config requests fire on page load. There should be exactly one per GA4 property.
Fix: Remove all duplicate GA4 configuration calls:
- Check your HTML source for any hardcoded
gtag('config', 'G-XXXXXXXX')calls - Check GTM for multiple GA4 Configuration tags (Container → Tags → filter by “Google Analytics: GA4 Configuration”)
- Ensure no third-party tool is also initialising GA4
Keep exactly one GA4 Configuration tag per property.
Cause 2: GA4 Tag Blocked by Consent Mode Before First Event
If you’re using Consent Mode and your GA4 Configuration tag has a consent-based trigger that blocks it until consent is granted, sessions where users don’t interact with the consent banner before navigating away will have no session_start.
How it happens: In Basic Consent Mode, tags are blocked from loading until consent is explicitly given. If a user lands on your site, bounces in 3 seconds without touching the consent banner, the GA4 tag never fires — and session_start is never captured.
What it causes: An undercount of sessions, particularly for high-bounce traffic (paid campaigns, direct visits to deep pages). Your GA4 session count may be 30-50% lower than your actual visits if your consent accept rate is low.
Fix options:
Option A: Switch to Advanced Consent Mode — GA4 fires immediately in cookieless mode, sends a session_start and anonymous pings even without consent, and upgrades to full tracking when consent is given. This recovers the lost sessions.
Option B: If you must use Basic Consent Mode, accept that pre-consent sessions are intentionally not tracked — this is a deliberate choice, not a bug. Document this as a known undercount in your reporting.
See our Consent Mode guide for the full implementation details.
Cause 3: GA4 Configuration Tag Fires After the First Event
The session_start event is generated by the GA4 library when the first event of a session is processed. If the GA4 Configuration tag fires after another event tag (e.g., a custom event fires first due to tag priority), the session initialisation may not happen correctly.
How it happens: A GA4 Event tag has a higher priority number than the GA4 Configuration tag. In GTM, higher priority number = fires first. If an event tag fires before the configuration is loaded, the GA4 library may not have initialised properly.
Fix: Ensure your GA4 Configuration tag has a higher priority than all GA4 Event tags:
- GTM → your GA4 Configuration tag → Advanced Settings → Tag firing priority
- Set to
10(or any number higher than your event tags) - Set all GA4 Event tags to priority
0
Alternatively, use the GA4 Configuration tag as a setup tag for your event tags:
- Event tag → Advanced Settings → Setup Tag → select your GA4 Configuration tag
This forces the Configuration tag to fire before the event tag, regardless of page trigger timing.
Cause 4: SPA (Single-Page Application) Not Re-Initialising Sessions
In a single-page application (React, Vue, Angular), route changes don’t trigger a page reload — so GA4’s automatic session detection doesn’t fire for subsequent “pages.” If the initial page load triggers session_start correctly but subsequent route changes don’t update the session, you can see session fragmentation or missing session_start for users who enter on a non-root route.
How it causes issues: Users who deep-link directly to yoursite.com/product/widget in an SPA may see session_start fire on that route — or not, depending on how your SPA hydrates and when GA4 initialises relative to the JavaScript framework.
Fix: Explicitly fire a page_view event (and by extension, allow GA4 to manage session state) on each route change:
// React Router v6 example
import { useEffect } from 'react';
import { useLocation } from 'react-router-dom';
function GATracker() {
const location = useLocation();
useEffect(() => {
// This allows GA4 to assess session state and fire session_start if needed
if (window.gtag) {
gtag('event', 'page_view', {
page_title: document.title,
page_location: window.location.href,
page_path: location.pathname + location.search
});
}
}, [location]);
return null;
}
Note: Avoid firing the full gtag('config', 'G-XXXXXXXX') on every route change — this reinitialises GA4 and can cause duplicate session_start events. Fire page_view events instead and let GA4 manage session state.
Cause 5: Cookie Restrictions Preventing Session Identification
GA4 uses the _ga cookie (and in some configurations, _ga_XXXXXXXX) to identify sessions across page loads. If cookies are being blocked or cleared between pages, GA4 may create a new session ID on each page — causing either duplicate session_start events (one per page) or apparent missing sessions if the cookie state is inconsistent.
How it happens:
- Safari ITP restricts JavaScript-set cookies to 7 days and may cap them shorter in some contexts
- Browser privacy settings block all cookies except strictly necessary ones
- Your website’s cookie consent implementation incorrectly blocks GA4 cookies before consent, then tries to backfill — causing timing issues
How to diagnose: In Chrome DevTools → Application → Cookies → look for _ga and _ga_XXXXXXXX cookies. They should persist between page reloads. If they’re absent or reset between page visits, cookie-based session identification is broken.
Fix options:
- For Safari ITP: Server-side cookie setting via HTTP headers extends the cookie lifetime beyond what JavaScript-set cookies allow
- For consent-related cookie issues: Review your CMP implementation to ensure GA4 cookies are only set after consent, not cleared and reset incorrectly
- For general cookie blocking: Consider server-side GA4 tracking via Measurement Protocol for the population of users where cookies can’t be reliably set
Diagnosing session_start Issues Systematically
Step 1: DebugView baseline
Connect your browser to GA4 DebugView (visit your site with ?gtm_debug=x or enable GA4 DebugView from Admin → DebugView → add your device). Navigate through your site and confirm session_start appears:
- On the first page load ✓
- Does NOT appear on subsequent page loads within 30 minutes ✓ (it should only fire once per session)
- Does appear when you return after 30+ minutes of inactivity ✓
Step 2: Network inspection
Chrome DevTools → Network → filter google-analytics.com. On page load, you should see:
- A request to load the
gtag.jsscript - A
collectPOST request containingen=session_start(en = event name)
If step 2 is missing, GA4 is loading but session_start isn’t being generated — points to configuration or priority issues.
Step 3: Tag Assistant
Use Google Tag Assistant to record a session on your site. The recording shows every tag that fires and every event generated. Look for:
- GA4 Configuration tag firing ✓
session_startevent generated ✓- No duplicate GA4 Configuration tags ✓
Step 4: BigQuery comparison (if connected)
-- Check session_start count vs expected session count
SELECT
event_date,
COUNTIF(event_name = 'session_start') AS session_starts,
COUNT(DISTINCT CONCAT(user_pseudo_id, CAST(
(SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS STRING
))) AS unique_sessions
FROM `project.analytics_XXXXXXXXXX.events_*`
WHERE _TABLE_SUFFIX >= FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 14 DAY))
GROUP BY 1
ORDER BY 1 DESC;
session_starts and unique_sessions should be approximately equal (within 1–2%). A significant gap indicates session_start events are missing for some sessions.
Reliable session_start tracking is foundational — every engagement metric, every attribution model, and every funnel report in GA4 depends on it being accurate. If you’re seeing unexplained gaps in your session data or your session counts look off versus your server access logs, session_start issues are worth investigating systematically using the steps above.
If you need a GA4 implementation audit to identify and fix tracking issues, book a free consultation.