GA4 Enhanced Measurement:
What to Enable, What to Turn Off

Fires on every page load, including history-change events in single-page applications. This is what powers session counts and the acquisition reports.

SPAs need attention here. If your site uses client-side routing (React, Vue, Angular), GA4 attempts to detect URL changes and fire additional page_view events. Whether it does this correctly depends on how your routing is implemented — some frameworks use methods GA4 doesn't detect, resulting in either missing page views or duplicate ones.

Fires a single scroll event when a user reaches 90% of the page depth. Only fires once per page per session.

The 90% threshold is fixed and cannot be customized through enhanced measurement. If you need multiple scroll depth milestones (25%, 50%, 75%, 90%), you'll need a GTM-based implementation. Leaving enhanced measurement scroll on at the same time as a custom implementation creates duplicate events.

Short pages distort this data. If your site has many short pages where 90% depth is reached almost immediately (sidebars, category pages with few items), the scroll event fires for almost every session and loses its signal value.

Fires when a user clicks a link that leaves your domain. Captures the destination URL as the link_url parameter.

This is generally useful and low-risk. The main issue is volume: high-traffic sites with many outbound links will generate a large number of click events, which can affect the hit limit and make the Events report harder to read if you're also using custom click events.

Check for social share buttons and affiliate links — these generate outbound click events that may look like user intent signals but are often incidental interactions.

Fires when GA4 detects a URL containing a search query parameter. By default, it looks for common parameter names (q, s, search, query, etc.) and captures the search term as the search_term parameter.

This is the most commonly misconfigured enhanced measurement setting. Two problems appear regularly:

First, if your URL-based filtering or faceted navigation uses query parameters that match GA4's detection list, every filter interaction gets logged as a site search event — inflating search data with non-search behavior. For example, a product filter that adds ?q=red+shoes&color=red to the URL will fire a search event for every color selection.

Second, if your site search uses a different parameter name (like keyword or term), the enhanced measurement setting won't pick it up. You can customize the parameter names in the advanced settings — click the gear icon next to Site search.

Fires three events (video_start, video_progress at 10%, 25%, 50%, 75%, and video_complete) for YouTube videos embedded on your site. Requires the YouTube iframe API to be enabled on the embed, which happens automatically when using standard embed code.

This only works for YouTube embeds, not native HTML5 video or other video platforms (Vimeo, Wistia, Loom, etc.). If you're measuring those, you need a separate implementation.

Also check: if your marketing site has a product demo video in the hero section, these events will fire heavily for users who don't consciously choose to watch it — autoplaying or prominent videos skew video engagement data toward accidental views.

Fires when a user clicks a link to a file with a recognized extension: PDF, CSV, DOCX, XLSX, ZIP, PPT, and others. Captures the file name and extension.

This is straightforward and useful for most sites — but be aware that it fires for any matching file extension, including files users might not consciously be downloading (inline PDFs that open in the browser, for example). If you have product spec sheets or menus that open inline and you want to distinguish between downloads and inline views, enhanced measurement won't make that distinction.

Fires form_start when a user first interacts with a form field, and form_submit when a form is submitted. This is the most problematic setting in enhanced measurement for many sites.

Form_submit does not confirm the form was submitted successfully. It fires when the submit button is clicked or the form's submit event is triggered — regardless of whether validation passed, whether the server returned a success, or whether the user actually converted. Sites that use inline validation will see form_submit fire even when the form has errors and submission was blocked.

If you're using form_submit as a conversion event, you should replace it with a custom event that fires only after server-side confirmation of success — typically on the thank-you page load or after a successful API response. Relying on form_submit for conversion counting routinely overstates conversions.

Form_start is similarly noisy on sites with search bars, newsletter signup widgets, or chat windows — anything with an input field fires this event, whether or not users intended to complete a form.