GA4 Admin Settings Audit:
8 Switches Most Teams Never Check

Controls how long GA4 stores raw event-level data. The default is 2 months. If you want to run custom Explore reports or funnel analyses on data older than 2 months, you need to change this to 14 months — the maximum available in most properties.

Standard reports (Acquisition, Engagement, Monetization) use aggregated data that isn't subject to this retention limit. But the Explore section — funnel explorations, path analysis, cohort analysis, segment overlap — draws from raw event data. If retention is set to 2 months, you can't build an Explore report on anything older than that.

Who gets hurt: anyone trying to analyze long customer journeys, seasonal trends in Explore, or cohort behavior over more than 60 days. This is the most commonly wrong setting in properties audited from setup more than a year ago.

The "Reset user data on new activity" toggle extends the retention window for individual users who keep returning. Leave it on — it ensures active users don't age out of the dataset while they're still engaging.

Controls how GA4 identifies and deduplicates users across sessions and devices. There are three options:

• Blended (default) — uses User-ID if available, then Google Signals, then device/cookie. Google Signals uses Google account data to stitch cross-device sessions, which requires users to be signed into Google and have opted into ad personalization. This can significantly undercount users by merging sessions that aren't actually the same person.
• Observed — uses User-ID if available, then device/cookie. No Google Signals inference. More conservative, more accurate for most properties.
• Device-based — uses only the device cookie. Closest to how Universal Analytics counted sessions.

The problem with Blended: Google Signals stitching is opaque and can produce unexpected user counts. If your GA4 user numbers seem inconsistent with your traffic volume, or if you're seeing anomalous drops when Google Signals data is available, switching to Observed often produces more stable and interpretable numbers.

For properties that have User-ID implemented (authenticated users), Observed is generally the most reliable choice. For unauthenticated sites, the difference between Blended and Observed is mostly whether you trust Google's cross-device inference.

Enables or disables Google Signals, which allows GA4 to use Google account data for cross-device user identification and demographic reporting. When enabled, GA4 can show age and gender estimates in the Demographics reports and stitch cross-device sessions for users signed into Google.

Privacy and compliance implications: Google Signals requires users to have opted into ad personalization in their Google accounts, but it also constitutes a form of data sharing with Google that some organisations' privacy policies or legal interpretations don't permit. If your site serves users in the EU under GDPR, enabling Google Signals without proper disclosure and consent legal basis is a compliance risk.

Additionally, enabling Google Signals triggers data thresholding — GA4 applies sampling to reports when audience sizes are small enough that individuals could be identified. This is the most common cause of the orange triangle warning in GA4 reports. If you're seeing thresholding and you don't critically need demographics data, disabling Google Signals is the fastest fix.

Controls whether GA4 collects precise location data (city-level rather than country/region only) and detailed device information. Enabled by default.

For most sites, city-level location data is useful for local business intelligence, geo-targeted campaign analysis, and understanding regional traffic patterns. But for properties serving users in jurisdictions where precise location constitutes personal data under local privacy law — including much of Europe under GDPR — collecting city-level location data requires a valid legal basis and disclosure.

Audit check: verify whether your privacy policy and consent setup covers city-level location collection. If you're operating under a consent-based model and users in the EU are consenting to analytics but not to precise location, this setting should reflect that. Many properties have it enabled simply because it was on by default at setup.

Controls what data Google uses from your property for its own purposes — improving Google products, benchmarking, technical support, and modelling. These are account-level settings that apply to all properties in the account.

The options include sharing data with Google for product improvement, for industry benchmarking (anonymised aggregate comparisons to similar sites), for technical support access, and for modelling/machine learning. All are enabled by default.

Who needs to review this: organisations with data processing agreements that restrict what can be shared with third parties, organisations in regulated industries where benchmarking data sharing might be a concern, and any property where the legal team has reviewed the GA4 data processing addendum and placed conditions on use.

For most commercial sites, the default settings are reasonable. But for healthcare, financial services, legal, or government-adjacent organisations, these defaults may not align with data governance requirements and should be reviewed explicitly rather than assumed.

Each conversion event in GA4 can be set to count once per session or once per event. The default for most events is once per event — meaning if a user triggers the conversion event five times in one session, GA4 records five conversions.

For most conversion types, once per session is more accurate. If a user views your thank-you page, navigates away, then hits the back button, you probably don't want to count two purchases. The same logic applies to lead form submissions, sign-ups, and most other goal completions.

Where once per event is appropriate: ecommerce transactions with a unique order ID passed as a parameter (GA4 deduplicates these), or for events where multiple occurrences in a session genuinely represent distinct conversion actions.

Check each conversion event's counting method. Properties migrated from Universal Analytics or set up by non-specialists often have all conversions set to once per event, which inflates conversion counts in reports and misleads campaign optimization.

Controls how long a period of inactivity ends a session. Default is 30 minutes of inactivity. An engaged session requires at least 10 seconds of activity, a conversion event, or 2+ page views.

The 30-minute default is suitable for most sites, but consider adjusting for:

• Long-form content or video sites — a user reading a 20-minute article or watching a 45-minute video will trigger a session timeout mid-engagement. Increasing timeout to 60 minutes prevents sessions from being split artificially.
• High-intent research sites — users who open a tab, come back after 35 minutes of comparing competitors, and then convert will have that second segment counted as a new session with direct attribution, losing the original source.
• Short visit sites (tools, calculators, quick-reference content) — the default is appropriate and no change is needed.

Session timeout changes apply going forward only. Historical data was recorded under the previous timeout setting and can't be retroactively recalculated.

Marks traffic from specified IP addresses or IP ranges as internal, allowing you to filter it out of reports using a data filter. This is the mechanism for excluding office traffic, developer traffic, and QA traffic from your analytics data.

Two separate things need to be configured for internal traffic filtering to work:

1. The IP addresses must be defined under Define Internal Traffic in the data stream settings
2. A Data Filter must be created at the property level (Admin → Data Filters) with the filter type set to "Internal traffic" and the state set to "Active"

The most common failure: IP addresses are defined in the data stream, but the data filter is in "Testing" mode or was never created. Internal traffic is tagged with the traffic_type parameter but isn't actually excluded from reports.

Also check: are the IP addresses current? Remote work and VPN usage mean office IPs often change or expand without the GA4 filter being updated. Developer IPs added at project launch may no longer be valid. And dynamic IP addresses — common for home offices — may need a range rather than a single IP.