Google Analytics (GA4) common mistakes
Google Analytics (GA4) · Understand the traps and how to avoid them.
Treating 'sessions' and 'engaged sessions' as interchangeable when interpreting traffic or retention reports, and answering questions as if every session counts toward engagement metrics.
Candidates carry over Universal Analytics habits where bounce rate and session counts were defined differently. In GA4, an engaged session requires 10+ seconds, a conversion event, or 2+ page views, so many sessions are not engaged and the two figures diverge sharply. Exam items deliberately test this distinction.
What to do instead
Memorise the three engagement triggers (10 seconds, conversion event, 2 page views) and the derived metrics: engagement rate = engaged sessions / sessions, and bounce rate = 1 − engagement rate. Before answering any question about traffic quality, ask which denominator the metric uses.
Describing GA4 data as 'sampled' or 'thresholded' by default and choosing answers that assume standard reports use sampled data.
Candidates transfer knowledge from Universal Analytics, where sampling in standard reports was common. GA4 standard reports are not sampled; sampling appears only in certain explorations (for example, some session-scoped techniques) and thresholding applies when demographic or Google Signals data would identify too few users.
What to do instead
Separate the two concepts explicitly: sampling = estimating results from a subset of events in explorations; thresholding = hiding rows to protect identity when demographics or Signals are enabled. Check the report context named in the question before choosing either term.
Confusing 'users', 'active users', and 'total users' and picking whichever sounds closest when a question asks about audience size.
GA4 defines total users as distinct users who triggered any event, while active users are those with an engaged session or a first_visit/first_open event. Candidates who learned UA's 'users' metric assume a single definition and miss the qualifier in the question stem.
What to do instead
Anchor each metric to its definition: total users counts any event; active users requires engagement. When a question mentions 'reached the site' versus 'meaningfully engaged', use that wording to select the metric rather than defaulting to users.
Assuming a user who converts on one device is automatically stitched to their other devices, and answering attribution questions as if cross-device identity is complete.
GA4 uses identity spaces (User-ID, Google Signals, device ID) and reporting identity settings determine how they are combined. Without User-ID implementation or Signals, the same person on phone and laptop is two users, and candidates overestimate GA4's identity resolution.
What to do instead
Learn the reporting identity options (Blended, Observed, Device-based) and what each can stitch. For any question about unique-user counts or cross-device paths, state the identity space in play and whether User-ID was collected.
Treating 'conversions' as identical to 'key events' in every context and selecting answers that describe them as two separate counting systems.
Google renamed the Conversions report to Key events; the underlying event is still marked as a conversion and exported with the conversion flag. Candidates who studied older material or partial documentation think these are parallel mechanisms and pick answers that double-count.
What to do instead
Remember that key events are the current name for events marked as conversions; the is_conversion event parameter and conversions metric still reflect them. When a question uses either term, map it to the same marked-event concept unless it explicitly describes the rename.
Building or evaluating an event-parameter setup that collects personally identifiable information (email, name, phone) in custom parameters and calling it acceptable for reporting.
Candidates focus on getting data into reports and forget the Google Analytics terms and data-redaction rules. PII in event parameters, user properties, or page URLs is prohibited and can trigger data deletion or account issues, so exam items test this as a governance failure.
What to do instead
Apply a PII screen to every proposed parameter: no names, emails, phone numbers, or full addresses. Use hashed or pseudonymous identifiers only where policy allows, and scrub URL query strings before collection. Treat PII collection as a defect, not a design choice.
Choosing 'data-driven attribution' as the default model without checking whether the property has enough conversion volume or whether the question describes a non-Google Ads context.
Data-driven attribution is the default for many new properties and is heavily promoted, so candidates assume it always applies. It requires sufficient data, and some questions describe cross-channel reporting where the model's behaviour differs from last-click assumptions.
What to do instead
Verify the prerequisites: data-driven attribution needs adequate conversion volume and is not available for every conversion type. If a question implies low volume or asks about a specific channel's credit, evaluate last-click, first-click, linear, and position-based before defaulting.
Explaining that a user who leaves the site and returns after 30 minutes starts a new session, but then also claiming the 30-minute timer resets only on page views.
The session timeout resets on any hit or event, not just page views, and the default is 30 minutes of inactivity. Candidates memorise the number but not the reset trigger, so they misanswer questions about session counts for engaged users who trigger events without navigating.
What to do instead
State the rule precisely: a session ends after 30 minutes without any event (configurable in property settings), and any event resets the timer. Apply it to scenarios with video plays, scrolls, or other non-pageview events before counting sessions.
Assuming that because GA4 is event-based, every event automatically appears as a usable dimension or metric in standard reports and explorations.
Only events and parameters registered as custom dimensions or metrics, plus a fixed set of built-in ones, are available for reporting and analysis. Candidates who see raw event data in DebugView or Realtime assume the same fields populate standard reports and answer accordingly.
What to do instead
Distinguish collection from reporting: events stream in regardless, but custom parameters need registration as custom dimensions or metrics (event-scoped or user-scoped) before they can be used in reports or audiences. Check the registration step in any question about segmenting by a parameter.
Confusing 'explorations' techniques (free-form, funnel, path, segment overlap, user explorer) and selecting a funnel exploration for a question that asks about drop-off across steps versus one that asks about the sequence of pages users visit.
The techniques look similar in the interface and candidates skim the descriptions. Funnel exploration measures progression through defined steps, while path exploration shows the sequence of events or pages before or after a starting point; user explorer is for individual journeys.
What to do instead
Match the question's core ask to the technique: defined-step conversion = funnel; open-ended navigation sequence = path; cohort or segment comparison = segment overlap; single-user timeline = user explorer. Write the mapping down before answering.