Google analytics Interview Questions

Note: Analytics interviews reward people who start from a business question. Anyone can read a report; the value is in knowing which question to ask.

Cover:

• The business context. E-commerce, lead generation, a content site, or an app — each has completely different key metrics and a different definition of success.
• The question. Something specific: why checkout conversion dropped, which acquisition channels produce customers who actually stay, where users abandon a signup flow, or which content drives eventual conversions.
• What you did. Configured events and conversions, built explorations, segmented, connected it to Google Ads or BigQuery, or fixed tracking that was wrong.
• What changed as a result. A page rewritten, a step removed from a form, budget reallocated between channels. An analysis nobody acted on is not a result.

If you found that the tracking itself was wrong, that is a strong story — it is extremely common and few people check.

The skill is deciding what to leave out.

• Lead with the finding and the recommendation, not the methodology. "We should move the phone number above the fold — 40% of mobile users scroll past it" is the headline; the data supports it.
• Give context to every number. A 3% conversion rate means nothing alone. Compared to last quarter, to another channel, or to a target, it becomes a finding.
• Separate observation from interpretation. Say clearly which is which. Traffic falling is an observation; blaming the redesign is a hypothesis that needs testing.
• Be honest about confidence. Small samples, short timeframes, and seasonal effects all limit what you can conclude, and stating that protects your credibility when a trend reverses.
• Keep detail in an appendix. Nobody wants twelve charts; they want the one that matters plus access to the rest.

Note: Being willing to say "the data does not tell us this" is a genuine differentiator. Stakeholders push for causal answers from correlational data constantly, and giving them one you cannot support is how analysts lose trust.

These are the most valuable analyses, and the hardest to land politically.

Structure it as:

• The belief and where it came from. Usually an assumption nobody had tested, or a conclusion drawn from an earlier report read incorrectly.
• What the data actually showed. Good examples: a channel everyone considered wasteful was driving assisted conversions; a popular page had the highest exit rate; mobile traffic was large but converting at a fraction of desktop; or a big traffic increase was bot traffic.
• How you verified before presenting. This is the important part. Check the tracking, check the date range, check for filters and bots, and see whether the pattern holds across segments. Presenting a surprising finding that turns out to be a measurement artefact is costly.
• How you presented it, and how people reacted.

Note: If the finding was resisted, say so and describe how you handled it — usually by proposing a small test rather than demanding the belief be abandoned. Letting the data settle it is far more effective than arguing.

Show that you audit rather than assume, since most analytics problems are measurement problems.

• Verify the tracking works. Use DebugView and the Tag Assistant, and complete a real conversion yourself to confirm it registers correctly. Do this after every site release — deployments break tags constantly.
• Check for duplicate tags. Two GA4 tags on a page inflates everything and is common after a migration or a theme change.
• Exclude internal and developer traffic, and enable bot filtering.
• Configure cross-domain tracking if the journey spans domains, or you will see your own site as a referrer and every conversion attributed wrongly.
• Check referral exclusions for payment gateways, which otherwise break session attribution at the moment of purchase.
• Reconcile against a source of truth. Compare GA4 transactions against the actual order database. They will never match exactly — consent, ad blockers, and attribution windows all cause gaps — but the size of the gap should be stable and explainable.

Note: Documenting a measurement plan — every event, its parameters, and what it means — before implementation is the practice that prevents most of these problems. Mentioning it signals real experience.

How you keep up: Google's release notes and the Analytics help documentation for platform changes, plus practitioner sources such as Simo Ahava for the implementation depth that official documentation omits. Most usefully, actually implementing changes in a test property before they are required.

On privacy — the substantive part of this question:

• Third-party cookies are gone or going, and browser restrictions such as ITP already limit first-party cookie lifetimes. Cross-site tracking and long attribution windows are no longer reliable.
• Consent is a legal requirement under GDPR and increasingly elsewhere, and consent mode changes what is collected before consent is given. Data will be incomplete by design.
• The consequences for analysis: modelled data fills gaps, so numbers are estimates rather than counts. Attribution is less certain. This should change how confidently you present figures.
• The direction of travel is towards first-party data, server-side tagging, and aggregate rather than individual-level measurement.

Note: Treating privacy compliance as a design constraint rather than an obstacle is the right framing. Saying you would collect less data and be clearer about why is both legally safer and increasingly what users expect.

They use fundamentally different data models — GA4 is not an upgrade of Universal Analytics but a replacement built on a different foundation.

• The measurement model. Universal Analytics was session-based: hits grouped into sessions, with pageviews, events, and transactions as distinct hit types. GA4 is event-based: everything is an event with parameters, including pageviews. This is the core difference and everything else follows from it.
• Cross-platform. GA4 measures web and app in one property; Universal Analytics could not.
• Identity. GA4 uses a blended approach — user ID, Google signals, device ID, and modelling — rather than relying solely on cookies.
• Metrics changed. Bounce rate was replaced by engagement rate, its inverse: a session is engaged if it lasts over ten seconds, has a conversion, or has two or more pageviews. This is a genuinely better measure, because a user reading one page for three minutes was counted as a bounce before.
• Reporting. Fewer standard reports, with the Explore section providing free-form analysis, funnels, and path exploration.
• BigQuery export is free in GA4, which was a paid 360 feature before. This is a major change for anyone doing serious analysis.

Note: Universal Analytics stopped processing data in July 2023, so GA4 is the only option. Historical UA data does not migrate, which is why year-over-year comparison across the transition is genuinely difficult.

In GA4 everything is an event. A pageview is an event, a click is an event, a purchase is an event. Each carries parameters giving context.

There are four categories:

• Automatically collected — first_visit, session_start, user_engagement. No configuration needed.
• Enhanced measurement — toggled on in the data stream: page_view, scroll, click on outbound links, file_download, video_start, and site search. Considerable value for no implementation work.
• Recommended events — predefined names and parameters Google expects for common actions, such as purchase, add_to_cart, login, and sign_up. Use these names exactly, because reports and integrations depend on them; a custom event called purchase_complete will not populate e-commerce reports.
• Custom events — your own, for anything specific to your business.

Conversions (now called key events) are simply events you mark as important. Any event can be flagged, which is far more flexible than Universal Analytics goals.

Note: Two practical limits worth knowing. Custom parameters must be registered as custom dimensions or metrics to appear in reports — a very common reason data appears missing. And there are caps: 50 custom dimensions and 50 custom metrics per property, and 25 parameters per event, so a measurement plan matters rather than tracking everything.

Acquisition:

• Users — unique visitors. GA4 defaults to active users, meaning those with an engaged session, which is not the same as total users.
• Sessions — a group of interactions. In GA4 a session ends after 30 minutes of inactivity but, unlike Universal Analytics, does not restart at midnight or on a campaign change.
• New versus returning users.

Engagement:

• Engaged sessions — over ten seconds, or with a conversion, or with two or more pageviews.
• Engagement rate — engaged sessions divided by total sessions. The replacement for bounce rate, and a better measure.
• Average engagement time — time the page was actually in focus, which is more meaningful than Universal Analytics' time on page, since that could not measure the final page of a visit at all.
• Views per session and event count.

Outcome:

• Conversions / key events, conversion rate, revenue, and average order value.

Note: The interview point is which metrics matter. Traffic volume is rarely the answer — a site can double its users and earn less. Conversion rate by channel, and revenue per user, tell you whether growth is worth having. Being able to say that engagement rate is a diagnostic and revenue is the goal shows the right instincts.

Google Tag Manager (GTM) is a tag management system. You place one container snippet on the site, then deploy and modify all other tracking through the GTM interface without touching site code or waiting for a developer release.

The three building blocks:

• Tags — the code that fires, such as a GA4 event, a Google Ads conversion, or a Meta pixel.
• Triggers — when it fires: a pageview, a click matching a selector, a form submission, a scroll depth, or a custom event pushed to the data layer.
• Variables — the values passed, such as the page path, a clicked element's text, or a value read from the data layer.

The data layer is the important concept. It is a JavaScript object the site populates with structured information — order value, product details, user type — that GTM reads. Relying on scraping values from the DOM is fragile and breaks whenever the site's markup changes; a data layer is a deliberate contract with the developers.

The relationship to GA4: GTM is the delivery mechanism, GA4 is the destination. You can install GA4 directly, but GTM gives you version control, a preview mode for testing before publishing, rollback to previous versions, and one place managing every marketing tag rather than a page full of scripts.

Note: Always use Preview mode before publishing, and mention server-side tagging as the modern direction — it improves data quality against ad blockers and gives control over what is shared with third parties.

Attribution decides which marketing touchpoint gets credit for a conversion. It matters because users rarely convert on first contact — they might arrive via organic search, return through a social post, then convert on a branded search.

The models:

• Last click — all credit to the final touchpoint. Simple, and systematically over-credits branded search and remarketing, which sit at the end of every journey.
• First click — all credit to the first. Over-credits discovery channels and ignores what closed the sale.
• Linear — credit split evenly across all touchpoints.
• Time decay — more credit to touchpoints closer to conversion.
• Position-based — typically 40% first, 40% last, 20% distributed among the middle.
• Data-driven — GA4's default. It uses machine learning on your own conversion paths, comparing those that converted with those that did not, to assign fractional credit. It is the most defensible model because it is derived from your data rather than an assumption.

Note: Two important caveats. First, GA4 removed the rule-based models from reporting in favour of data-driven and last click, so options are narrower than they were. Second — and this is what interviewers want — no attribution model is truth. They are different lenses on incomplete data, and cross-device, cookie restrictions, and offline touchpoints mean parts of the journey are invisible. The practical use of attribution is comparing channels consistently over time, not calculating exact contribution.

All three isolate a subset of data, but they behave differently.

• Comparisons — applied in standard reports to view side by side, such as mobile against desktop, or one country against another. Quick, temporary, and limited in complexity.
• Segments — built in Explore, and far more powerful. Three types: user segments (everyone who ever purchased), session segments (sessions from paid search), and event segments (specific events matching conditions). Segments can use sequences — users who viewed a product then added to cart within an hour — which is where the real analytical value is.
• Audiences — segments made persistent and exportable. Once defined, GA4 starts collecting members going forward, and they can be pushed to Google Ads for remarketing. Crucially, audiences are not retroactive: they only populate from creation, which is why you should define them early.

How to use them analytically: aggregate numbers hide almost everything interesting. A 2% overall conversion rate might be 5% on desktop and 0.4% on mobile — the average tells you nothing actionable, and the segmentation tells you exactly where to work. Comparing converters against non-converters to see what behaviour differs is the single most productive analysis pattern.

Note: The 5 concurrent segments per exploration limit is worth knowing, as is the fact that audience membership counts towards remarketing only after the audience exists.

Conversions (key events): any event can be marked as a conversion in Admin, or from the Events report with a toggle. Because GA4 is event-based, this is far more flexible than Universal Analytics goals — but it also means the event must exist and fire correctly first.

E-commerce tracking requires specific recommended events with specific parameters, pushed to the data layer and picked up by GTM:

• view_item_list, view_item, select_item
• add_to_cart, remove_from_cart, view_cart
• begin_checkout, add_shipping_info, add_payment_info
• purchase — with transaction_id, value, currency, and an items array

The names and parameter structure must match Google's specification exactly. Renaming them means the e-commerce reports stay empty, and this is the most common implementation failure.

Essential checks:

• transaction_id must be unique per order — it is what deduplicates purchases if a user refreshes the confirmation page. Without it, revenue inflates.
• Exclude your payment gateway as a referral, or the session will break at checkout and attribute the sale to the gateway.
• Verify in DebugView and by completing a real test purchase, then reconcile totals against the order system.

Note: Currency must be a valid ISO code and consistent, or values are misinterpreted. And mark only genuinely meaningful actions as conversions — flagging every event makes the concept meaningless.

Dimensions are attributes; metrics are numbers. A dimension describes what — country, device category, page path, source, medium. A metric measures how much — users, sessions, conversions, revenue. Every report is metrics broken down by dimensions.

Custom dimensions and metrics let you register your own event or user parameters so they appear in reports. Event-scoped for something varying per event, user-scoped for a persistent attribute such as membership tier. Registering them is required — an unregistered parameter is collected but not reportable.

Data sampling means GA4 analyses a subset and extrapolates when a query exceeds a processing limit. Standard reports are unsampled; Explorations can be sampled on large properties or long date ranges. GA4 shows a sampling indicator, and you should check it before drawing conclusions — a sampled report on a small segment can be badly imprecise.

Data thresholding is different and catches people out. GA4 withholds rows when they could identify individuals — typically when Google signals is enabled and the underlying user count is small. The row simply disappears rather than showing zero, so totals appear not to add up.

Note: The practical answers: widen the date range or narrow the query to reduce sampling; and to avoid thresholding, either disable Google signals in reporting identity or use the free BigQuery export, which contains the raw unsampled, unthresholded event data. Naming BigQuery as the escape hatch is the answer that demonstrates real depth.

Work from measurement outwards, because the most common cause is not a real drop.

First, is it real?

• Check the tracking. A site release that broke a tag, a duplicated GTM container, or a consent banner change will all look exactly like a conversion collapse. Verify with DebugView and a real test conversion, and reconcile against the order or CRM system. This must be step one — investigating a measurement artefact wastes days.
• Check the date range and comparison period for seasonality, holidays, and day-of-week effects.

If it is real, isolate where:

• Is it traffic or conversion rate? Fewer users converting at the same rate is an acquisition problem; the same users converting less is a site or offer problem. This one split directs everything.
• Segment by channel — a single channel falling points at a campaign change, a ranking loss, or a budget exhaustion.
• Segment by device and browser. A drop confined to one browser or to mobile almost always means something broke.
• Segment by geography and landing page.
• Build a funnel exploration to find which step lost people. A step that suddenly leaks is usually a bug or a form validation change.

Then check what changed: deployments, price changes, campaign edits, or a competitor's move.

Note: Say explicitly that correlation with a release is a hypothesis to test, not proof — and that the fastest confirmation is often to walk the funnel yourself on the affected device.

UTM parameters are tags appended to a URL that tell Analytics where a visitor came from. Without them, traffic from an email or a social post often lands in Direct or an unhelpful referral bucket.

The five parameters:

• utm_source (required) — the specific origin: newsletter, linkedin, google.
• utm_medium (required) — the channel type: email, cpc, social, referral. This is what drives channel grouping, so consistency here matters most.
• utm_campaign — the campaign name: diwali_sale_2026.
• utm_term — the keyword, mainly for manually tagged paid search.
• utm_content — to distinguish variants, such as two buttons in the same email.

The rules that make or break it:

• Agree a naming convention and document it. Facebook, facebook, and FB become three separate sources, fragmenting every report. Values are case-sensitive.
• Use standard medium values, or traffic falls into "Unassigned" instead of the right channel group.
• Never tag internal links. Tagging a link between your own pages starts a new session and destroys the original attribution — a genuinely common and damaging mistake.
• Do not manually tag Google Ads; use auto-tagging with the gclid instead, which carries far more detail.

Note: Keep a shared UTM builder spreadsheet so everyone generates links the same way. It is unglamorous and it is what makes campaign reporting usable.