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.

This question separates analysts who start from business questions from those who start by tracking every click. Structure the answer so the interviewer sees a chain from objectives to KPIs to events to reports.

1. Objectives — describe the meetings you held with stakeholders to agree what success looks like, for example “increase completed job applications from mobile users by 20%”.
2. KPIs and questions — turn each objective into a small number of metrics and the questions they must answer: application completion rate, drop-off by step, and applications by acquisition channel.
3. Event design — map each question to events and parameters. Use Google's recommended events where they fit (sign_up, generate_lead, purchase) and a consistent snake_case naming convention for custom ones, such as application_step with a step_name parameter.
4. Documentation — a tracking specification listing each event, its trigger, parameters, example values, dataLayer push, key event status and owner. Engineers build from it and QA tests against it.
5. Implementation and QA — Google Tag Manager with dataLayer pushes from the application, tested in Preview mode and DebugView on staging before release.
6. Reporting — custom dimensions registered, key events marked, and a dashboard or exploration ready on launch day so there was a baseline from the start.

What to emphasise: the things you deliberately chose not to track, how you handled consent and personal data (no emails or phone numbers in parameters), and how the plan was versioned as the product changed.

Result example: “The funnel showed 38% of mobile users dropping at the resume upload step. The product team added a LinkedIn import option, and completion rose from 41% to 55% within a month.”

Note: Interviewers often follow up with “how did you know the data was right?” Have an answer ready about comparing GA4 counts with backend records during the first week.

Most analysts lived through this migration, so interviewers use it to test planning, technical judgement and expectation management. A strong answer covers what you rebuilt, what you rethought and how you explained the differences.

• Audit first — list which UA reports, goals, custom dimensions, filters and integrations were actually used. Many properties had years of unused configuration, and the migration was a chance to leave it behind.
• Rebuild, not copy — map UA category, action and label events to meaningful GA4 event names with parameters; recreate goals as key events; register custom dimensions; re-link Google Ads and Search Console; and set data retention to the maximum on day one.
• Run in parallel — ideally both properties collected data for several months before UA stopped processing in July 2023, which gave a period for comparison.
• Explain the differences — sessions, users and conversion counts do not match between the two because the data models differ. Bounce rate means something different in GA4, sessions no longer restart at midnight or when the campaign changes, and attribution defaults changed. Document these so that nobody treats the gap as a tracking error.
• Preserve history — export key UA reports to BigQuery, Sheets or a warehouse before the UA interface was shut down, so year-on-year comparisons remained possible.
• Train people — short sessions on the new reports and Explorations, plus a Looker Studio dashboard so executives had a familiar view.

Example: “We started dual-tagging eight months before the cut-off. I published a one-page guide on why GA4 showed 12% fewer sessions, and we reported trends within each tool rather than comparing absolute numbers across tools for the transition year.”

Note: If you joined after the migration, answer with a similar project, such as auditing an inherited GA4 setup. Show the same pattern: audit, rebuild, validate and communicate.

Attribution disputes are common because budgets depend on them. The interviewer wants to see that you stay neutral, explain the limitations of each model, and move the discussion towards decisions rather than arguments.

• Situation — describe the conflict. For example: paid social claimed a large share of sign-ups in Meta's own reporting, while GA4 credited paid search and organic, and the two teams' totals added up to far more than the real number of sign-ups.
• Explain why the numbers differ — each ad platform counts conversions it touched using its own rules, including view-through conversions, so platform totals overlap. GA4 uses one model across channels, typically data-driven attribution, and only sees clicks it can measure.
• Show multiple views — compare data-driven and last-click attribution in the GA4 Model comparison report, and use the conversion paths report to show how often social appeared early in journeys that ended with search.
• Agree a single source of truth — for example, GA4 data-driven attribution for cross-channel budget discussions, with each platform's own reporting used only for optimisation inside that platform.
• Test incrementality — propose a geo holdout or a brand-lift or conversion-lift study to measure what each channel adds, which no attribution model can prove on its own.

Result example: “The holdout test showed paid social drove roughly 9% incremental sign-ups, far less than the platform claimed but more than last-click suggested. We reallocated 15% of the budget and kept total sign-ups flat at lower cost.”

Note: Avoid declaring one team right. The strongest answers show you built shared understanding and a testing habit, so the next disagreement could be settled with evidence.

This is a chance to show the full analytics loop: a question, an insight, a recommendation, and measured impact. Use STAR, but give most of your time to the analysis and the proof.

• Situation — the business context and the metric at stake, for example: “Checkout conversion on mobile was half the desktop rate.”
• Analysis — name the GA4 tools you used and what each showed. A funnel exploration broken down by device located the drop at the payment step. Path exploration showed users returning to the cart repeatedly. A custom event capturing form errors revealed that one error message (“invalid PIN code”) fired on 22% of mobile attempts.
• Root cause — combine data with qualitative evidence: session recordings, a quick usability test, or a check with customer support. In this example, the PIN code field rejected codes with spaces pasted from address autofill.
• Recommendation and change — a small fix to the validation, prioritised because the analysis quantified the lost revenue.
• Proof — ideally an A/B test. If that is not possible, a before-and-after comparison with a control segment (desktop users, who were unaffected) and a long enough window to cover weekly cycles, with seasonality and campaign changes noted.

Result example: “Mobile checkout completion rose from 31% to 38% over four weeks while desktop stayed flat, worth an estimated 14 lakh rupees a month in additional revenue.”

Note: Mention what you did with the learning afterwards, such as adding form-error tracking to every form. It shows you turn one-off wins into better measurement.

This tests governance and stakeholder management. Without a process, a GA4 property fills with inconsistent event names, unused custom dimensions and duplicate tags until nobody trusts it. Describe a process you actually ran.

• A single intake route — a short request form asking what business question the data will answer, who will use it, how often, and what decision it will change. Many requests shrink or disappear at this stage.
• Check what already exists — often the answer is already available through an existing event with a different parameter, or in BigQuery.
• Prioritise openly — score requests on business impact, effort and urgency such as a campaign launch date, and share the backlog so teams can see the trade-offs.
• Naming and design standards — a documented convention (snake_case, recommended events first, a controlled list of parameter names) and one tracking specification that is the source of truth.
• Protect limited resources — GA4 limits the number of custom dimensions and metrics per property, so each new one needs a clear owner and use. Review and archive unused ones periodically.
• Change control — separate GTM workspaces, peer review before publishing, descriptive version notes, testing on staging, and an annotation or changelog for every release so trend changes can be explained later.
• Access management — limited edit and publish rights in GA4 and GTM, and viewer access for most users.

Example: “I introduced a fortnightly tracking review. Within a quarter we cut duplicate events from 140 to 60 names, freed 12 custom dimension slots, and the average turnaround for approved requests dropped to one sprint.”

Note: Show empathy for the requesting teams. Saying no to everything is not governance. The aim is fast delivery of useful data on a foundation that stays reliable.

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.

GA4 records everything as events, but they come from four sources that differ in how much work they need and how they appear in reports.

• Automatically collected events — sent by the Google tag or Firebase SDK with no configuration, for example first_visit, session_start and user_engagement on the web, and first_open and app_update in apps. You cannot turn these off individually; they underpin core metrics such as users, sessions and engagement.
• Enhanced measurement events — web interactions enabled with toggles in the data stream settings: page_view, scroll, outbound click, view_search_results, file_download, video engagement for embedded YouTube, and form interactions. Google's documentation groups these with automatically collected events, but each can be switched off. They are ideal as a baseline, but check their accuracy; form tracking in particular can fire when a form was not really submitted.
• Recommended events — events Google has defined names and parameters for, but which you must implement: login, sign_up, generate_lead, add_to_cart, begin_checkout, purchase and many more. Use them whenever your action matches, with the exact name and parameters, because they unlock built-in reports (such as e-commerce reports), predictive features and future functionality.
• Custom events — names you define for actions no recommended event covers, such as resume_uploaded or mock_interview_started. Use them sparingly and consistently, and register their parameters as custom dimensions if you need them in reports.

Order of preference: check whether the action is already collected automatically, then whether a recommended event fits, and only then create a custom event. This keeps the property consistent and compatible with Google's reports.

Note: Event names are case-sensitive, so “Sign_Up” and “sign_up” become two different events. Agree a naming convention before implementation, because renaming after launch splits your historical data.

• Event parameters — extra details sent with an event, such as page_location on a page view or value and currency on a purchase. They describe that one event.
• User properties — attributes describing the user, which then apply to all of that user's subsequent events, such as membership_tier, preferred_language or customer_type.
• Custom dimensions and metrics — the reporting layer. Collected parameters and user properties do not appear in standard reports or Explorations until you register them in Admin under Custom definitions. Registration is how you tell GA4 to process them.

Scope defines what a dimension value applies to:

Session-level information comes from built-in dimensions such as session source and landing page rather than from custom dimensions.

Practical rules:

• Registration is not retroactive — reports show values only from the time the dimension was registered, so register important dimensions before launch. The raw parameters are still available in BigQuery.
• Choose scope by the question — a value that describes the person (their plan) should be a user property; a value that describes an action (which article was read) should be an event parameter.
• Mixing scopes gives odd results — combining a user-scoped dimension with an event-scoped metric can produce (not set) rows or confusing totals.
• Quotas — each property has a limited number of custom dimensions and metrics per scope, so avoid registering one-off parameters.
• Never send personal data such as emails or phone numbers in parameters or user properties; this breaks Google's policies.

Note: Avoid high-cardinality values such as timestamps or order IDs as custom dimensions. They consume quota, trigger (other) rows in reports, and are better analysed in BigQuery.

In 2024 Google renamed what GA4 used to call “conversions” to key events, and reserved the word conversion for actions used in Google Ads measurement and bidding. The distinction clarifies which data is used for analysis and which is used for advertising.

• Key events — any GA4 event you mark as important to the business, such as purchase, generate_lead or sign_up. They appear in GA4 reports, attribution reports and Explorations, and can be used in audiences. You mark an existing event as a key event in Admin, or create a new event from an existing one (for example, a page_view where the page location contains /thank-you) and mark that.
• Conversions — actions that Google Ads counts and can optimise bidding towards. A GA4 key event becomes a Google Ads conversion when you import it into a linked Google Ads account. Ads can also track conversions with its own tag, independently of GA4.

Settings worth knowing:

• Counting method — a key event can be counted once per event (every occurrence, suitable for purchases) or once per session (suitable for leads, so one user submitting a form three times counts once).
• Value — send value and currency parameters, or set a default value, so reports can show revenue rather than just counts.
• Not retroactive — marking an event as a key event applies from that point onwards.

Why numbers differ between GA4 and Google Ads: different attribution models and lookback windows, Ads crediting conversions to the date of the ad click while GA4 reports them on the date they happened, view-through and cross-device conversions in Ads, and consent-mode modelling applied differently.

Note: Keep the list of key events short. If everything is a key event, attribution and key event rate lose their meaning. Mark only the outcomes that represent real business value, and track micro-interactions as ordinary events.

Session — a group of interactions by one user within a period of activity. GA4 fires a session_start event and assigns a session ID when a user opens the app or arrives on the site with no active session. The session ends after 30 minutes of inactivity by default, and the timeout can be changed in the web stream's tag settings.

Differences from Universal Analytics: a GA4 session does not restart at midnight or when the traffic source changes partway through, so GA4 usually reports fewer sessions than UA did for the same traffic.

Engaged session — a session that meets at least one of these conditions:

• it lasted longer than 10 seconds (adjustable up to 60 seconds in the stream settings),
• it included at least one key event, or
• it included two or more page views or screen views.

Related metrics:

• Engagement rate = engaged sessions ÷ sessions. If there were 10,000 sessions and 6,200 were engaged, the engagement rate is 62%.
• Bounce rate in GA4 is the inverse: the percentage of sessions that were not engaged, so 38% in this example. This differs from UA, where a single-page session was a bounce however long the visit lasted.
• Engaged sessions per user and average engagement time — engagement time counts only the time the page or app was in the foreground, which is more meaningful than the UA session duration based on timestamps between hits.

How to use them: compare engagement rate by channel and landing page to find traffic that arrives but does not engage, for example a display campaign with a 20% engagement rate against 65% for organic search.

Note: If you change the engaged-session timer to suit long-form content, document it. Engagement rates are then not comparable with other properties or with periods before the change.

A data stream is a source of data flowing into a GA4 property. There are three types:

• Web — identified by a Measurement ID (starting with G-) and collected by the Google tag, either directly or through Google Tag Manager.
• iOS app and Android app — collected with the Google Analytics for Firebase SDK.

Settings that live at stream level (for web streams): enhanced measurement toggles, cross-domain configuration, internal traffic definitions, unwanted referrals, session timeout and the engaged-session timer, and the Measurement Protocol API secrets.

Why a single property with several streams is usually better when the web and apps belong to one product:

• A unified user view — with User-ID, one person using the app and the website can be counted as one user, and journeys that cross platforms can be analysed.
• Shared configuration — key events, audiences, custom dimensions and Google Ads links are set up once.
• Cross-platform reporting — compare platforms in one report with the Stream name or Platform dimension, or filter to one when needed.

When separate properties make sense: genuinely separate businesses or brands with different audiences, different teams and access needs, different data retention or legal requirements, or when one site's volume would dominate the other's reporting. GA4 has no views, so separate properties (or subproperties and roll-up properties for GA4 360 customers) take the place of the old UA practice of creating filtered views.

Common mistakes: creating a separate web stream for each subdomain of the same site (one web stream per site is recommended, and subdomains share cookies automatically), deleting and recreating streams, which breaks continuity, and putting staging and production traffic into the same property without filtering.

Note: Use one web stream per website. Splitting one site across several streams in a property causes duplicate counting and messy session attribution, and it is one of the most common setup errors in audits.

The problem it solves: the GA4 client ID lives in a first-party cookie, and browsers do not share cookies between different domains. When a user moves from jobaaj.com to a separate booking or payment domain, GA4 would otherwise count a new user, start a new session, and credit the second domain's key events to a self-referral instead of the original campaign.

Setup in GA4:

1. Use the same GA4 property and Measurement ID on every domain involved.
2. In Admin, open the web data stream, go to Configure tag settings, then Configure your domains, and add each domain with a match condition such as “contains” or “exactly matches”.
3. The Google tag then decorates links (and form submissions) that point to the listed domains with a _gl URL parameter carrying the client ID and session information. The destination page reads it and reuses the same identifiers.
4. Add third-party domains that you do not control and that send users back, such as payment gateways, to List unwanted referrals, so returning users do not start a new session attributed to the gateway.

You do not need cross-domain tracking for subdomains of the same domain, such as www.example.com and blog.example.com, because the Google tag sets its cookie at the highest-level domain by default.

How to verify:

• Click a link to the other domain and confirm the URL contains _gl=. If the destination redirects and strips query parameters, the linker fails, so check redirects carefully.
• In DebugView or GTM Preview, confirm the client ID is identical on both domains and no new session_start fires.
• After a few days, check the traffic acquisition report for your own domains appearing as referrals. Their disappearance is the best sign of success.

Note: Links created by JavaScript after page load, iframes and server-side redirects are the usual failure points. They may need manual decoration or a different approach, so test every real path users take between the domains.

A lookback window is how far back in time GA4 looks for touchpoints that can receive credit for a key event. A touchpoint that happened before the window starts gets no credit, even if it genuinely influenced the user.

The two settings, found in Admin under Attribution settings:

• Acquisition key events (first_visit and first_open) — 7 or 30 days, with 30 days as the default.
• All other key events — 30, 60 or 90 days, with 90 days as the default.

How the window changes the results: imagine a user who clicks a paid social ad on day 1, returns through organic search on day 40, and buys through an email link on day 45.

• With a 90-day window, all three touchpoints are within range, so data-driven attribution can share credit between paid social, organic search and email.
• With a 30-day window, the day-1 social click falls outside, so social receives nothing and email and organic share the credit.

Choosing the right window:

• Match the window to your real consideration cycle. An impulse purchase might convert within days, while B2B software, education courses or property purchases can take months.
• Look at the time-to-convert pattern in path data before choosing.
• Keep the window consistent across periods you compare, and record any change as an annotation.

Related settings: the reporting attribution model (data-driven by default; paid and organic last click and Google-paid-channels last click are the alternatives) is set in the same place, and it affects advertising and attribution reports and key events imported into Google Ads.

Note: When comparing GA4 with Google Ads, remember that each Ads conversion action has its own click-through and view-through windows set inside Google Ads. Mismatched windows are one of the most common reasons the two tools disagree.

Both reports show where traffic comes from, but they answer different questions because they use differently scoped dimensions.

Worked example: a user first arrives through a paid search ad, comes back twice through an email newsletter, and buys on the third visit.

• In user acquisition, the user and the purchase appear under Paid Search, because the dimension describes how the user was first acquired.
• In traffic acquisition, there is one Paid Search session and two Email sessions, and the purchase appears under Email, the source of the session in which it happened.
• In the Advertising section, the purchase is shared out according to the reporting attribution model, for example data-driven attribution across both channels.

When to use which:

• User acquisition — evaluating which channels bring in new users who go on to have value, such as comparing lifetime revenue by first-user channel.
• Traffic acquisition — understanding day-to-day visit sources, campaign performance per session, and engagement by channel.
• Advertising and attribution reports — deciding budgets across channels that share credit for key events.

Note: A common interview trap is asking why a channel's revenue differs across these reports. The answer is scope: each report credits revenue using a different rule, so the numbers are all correct but answer different questions. Always state which scope you are reporting.

Data retention controls how long GA4 keeps user-level and event-level data tied to cookies, user IDs and advertising identifiers before it is deleted. It is set in Admin under Data collection and modification, then Data retention.

• Standard GA4 properties: 2 months or 14 months. The default is 2 months, which is why changing it to 14 months is one of the first steps in any new setup.
• GA4 360 properties: longer options are available, up to 50 months.
• Reset user data on new activity: when this is on, the retention period for a user restarts every time they return, so active users' data is kept longer.

What it affects:

• Explorations — funnel, path, free-form, segment overlap and cohort explorations query event-level data. With 2-month retention, you cannot build a funnel exploration for a period more than two months ago.
• Any analysis that needs individual user or event detail over long periods.

What it does not affect:

• Standard reports such as Acquisition, Engagement and Monetization use aggregated data, which is kept regardless of this setting. You can still compare year on year in these reports.
• BigQuery export — exported data stays in your BigQuery project for as long as you keep it, which makes BigQuery the real long-term archive.

Other points worth knowing:

• Increasing retention is not retroactive: data already deleted cannot be recovered.
• Choose a period that matches your privacy policy and legal requirements; longer is not automatically better if your policy promises less.
• User deletion requests and the data deletion tool are separate mechanisms from the retention setting.

Note: If someone says “GA4 only keeps two months of data,” correct them politely: aggregated reports keep history, and only event-level Explorations are limited. Linking BigQuery early is the recommended way to keep full raw history.

The BigQuery export sends the raw, event-level data of a GA4 property into a Google BigQuery project, where you can query it with SQL. Linking is available at no charge for standard properties; you pay only for BigQuery storage and queries, and the BigQuery sandbox allows small-scale use without a billing account, with some limits.

Export options:

• Daily — one table per day, named events_YYYYMMDD. Standard properties have a daily export limit (around one million events per day); larger properties need GA4 360 or streaming.
• Streaming — near-real-time intraday tables (events_intraday_YYYYMMDD), billed by BigQuery.
• User data export — tables with user-level attributes, such as predictive metrics and audiences.

What each row contains: one event, with its name and timestamp, user_pseudo_id (the client ID), user_id if set, a nested and repeated event_params field, user properties, device, geography, app or web stream information, traffic source fields, and e-commerce and items data.

When to use it:

• Escaping interface limits — no sampling, no thresholding, no (other) rows and no retention limit once the data is in BigQuery.
• Joining with other data — CRM records, order databases, ad cost data or offline sales, for true customer-level ROI and lifetime value.
• Custom modelling — your own attribution models, churn prediction, or custom session and funnel definitions.
• Reliable dashboards — Looker Studio or other BI tools reading summary tables built from BigQuery instead of hitting GA4 API quotas.

Limitations: the export is not retroactive and starts from the day you link it; it contains no consent-mode modelled data; data-driven attribution results are not included in the raw data; and totals will not exactly match the interface because GA4 uses estimation for some user counts and applies thresholding.

Note: Link BigQuery on day one of any serious GA4 setup, even if nobody queries it yet. Every day without the export is raw history you can never recover.

In the GA4 export, each row is one event, and all of the event's parameters are stored in event_params, a repeated record of key and value pairs. Each value sits in a typed field such as string_value, int_value or double_value. You cannot select a parameter as a normal column; you have to unnest the array and pick the key you want, usually with a scalar subquery.

Example: page views by page for August 2026

SELECT
  (SELECT value.string_value FROM UNNEST(event_params)
   WHERE key = 'page_location') AS page,
  COUNT(*) AS page_views,
  COUNT(DISTINCT user_pseudo_id) AS users
FROM `my-project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260831'
  AND event_name = 'page_view'
GROUP BY page
ORDER BY page_views DESC;

Key techniques:

• Wildcard tables and _TABLE_SUFFIX — query a date range across daily tables, and always filter on the suffix to limit the data scanned and the cost.
• Building sessions — there is no session table. A session is identified by combining user_pseudo_id with the ga_session_id event parameter (an integer value), then counting distinct combinations.
• Choosing the right value type — a parameter may arrive as a string on one event and an integer on another, so use COALESCE across value fields when unsure.
• Items — e-commerce products live in the repeated items field and need CROSS JOIN UNNEST(items) to analyse revenue per product.
• Timestamps — event_timestamp is in microseconds UTC, so convert it to your reporting time zone before grouping by hour or date.

Why numbers differ from the GA4 interface: the interface uses estimated counts for users, applies thresholding and includes modelled data, while BigQuery gives exact counts of raw events. Small differences are expected; large ones point to a query or filtering error.

Note: Build a cleaned, flattened sessions or events table on a schedule and point dashboards at it. Querying the raw nested tables for every chart is slow and expensive.

Consent Mode lets Google tags adjust their behaviour according to the user's consent choices, which are collected by a consent management platform (CMP) or cookie banner. Consent Mode version 2 uses four main consent types:

• analytics_storage — whether analytics cookies may be used.
• ad_storage — whether advertising cookies may be used.
• ad_user_data — whether user data may be sent to Google for advertising purposes.
• ad_personalization — whether data may be used for personalised advertising such as remarketing.

The two ad data and personalisation signals were added for version 2, and Google requires them for advertisers who serve users in the European Economic Area and want to keep using features such as audiences and conversion measurement.

Behavioural modelling estimates the behaviour of users who declined, using patterns from similar users who consented. It requires advanced mode, the Blended reporting identity, and minimum volumes of both consented and unconsented traffic over recent days, as documented by Google.

Implementation points: set the default consent state before any Google tag fires (GTM has a Consent Initialization trigger for this), update it when the user makes a choice, and use Tag Assistant to check the consent state on every page.

Note: The choice between basic and advanced is partly a legal decision, because advanced mode sends cookieless pings even when users decline. Present the measurement trade-off clearly and let the legal or privacy team decide.

The dataLayer is a JavaScript array on the page that acts as a structured message queue between the website and Google Tag Manager. The site pushes objects describing what happened and the relevant values; GTM listens, updates its internal data model, and uses the values in triggers and variables. It separates tracking from page layout, so a design change does not break analytics.

Example: a job application submitted

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'application_submitted',
  job_category: 'data-analytics',
  experience_level: 'fresher',
  application_method: 'resume_upload'
});

How it becomes a GA4 event in GTM:

1. Variables — create Data Layer Variables for job_category, experience_level and application_method.
2. Trigger — create a Custom Event trigger with the event name application_submitted. The event key is what makes GTM evaluate triggers; a push without it only updates values.
3. Tag — a GA4 Event tag with your Measurement ID, the event name, and parameters mapped to the variables.
4. Reporting — register the parameters as custom dimensions in GA4 and mark the event as a key event if appropriate.

Best practices:

• Push from the application code at the moment the action is confirmed, for example after the server accepts the form, not on the button click.
• Declare page-level values, such as page type or login state, in a push before the GTM container snippet so they are available to the first tags.
• For e-commerce, push { ecommerce: null } before each e-commerce event so values from a previous event are not merged into the next one.
• Keep names consistent with the tracking specification and never push personal data such as names, emails or phone numbers.

Note: The first line creates the array only if it does not already exist, so the code is safe whether or not GTM has loaded. Overwriting the array with a new empty one would break GTM's listener.

In GTM, a tag fires when its trigger conditions are met, and variables supply the values that triggers check and tags send.

Trigger types:

• Page view family — Consent Initialization (for setting default consent before anything else), Initialization, Page View, DOM Ready and Window Loaded. Choose the earliest one at which the data you need is available.
• Clicks — All Elements or Just Links, filtered by variables such as Click URL, Click Classes or Click Text.
• User engagement — Form Submission, Scroll Depth, Element Visibility (fires when an element enters the viewport) and YouTube Video.
• Other — Custom Event (fires on a dataLayer event name and is the most reliable choice), History Change (for single-page apps), Timer, JavaScript Error and Trigger Group (fires once all included triggers have fired).

Variables:

• Built-in variables — Page URL, Page Path, Referrer, Click and Form variables, and others. Many must be enabled before use.
• User-defined variables — Data Layer Variable, URL (to extract a query parameter), First-Party Cookie, DOM Element, JavaScript Variable, Custom JavaScript, Constant (such as a Measurement ID), Lookup Table and RegEx Table (to map values, for example hostnames to environments), and the Google tag configuration settings variables for shared parameters.

How to choose:

• Prefer Custom Event triggers with dataLayer variables for important actions. Click and form triggers depend on CSS classes and page structure, which change when the site is redesigned.
• Use click triggers for simple cases such as outbound links or downloads, but test them after each release.
• Use trigger exceptions (blocking triggers) to stop tags firing in certain conditions, for example on internal pages or before consent is granted.
• Use lookup tables instead of duplicating tags per environment or country.

Note: Naming conventions matter as much in GTM as in GA4. Names such as “GA4 - Event - application_submitted” and “CE - application_submitted” keep a large container maintainable when several people work on it.

Debugging works in layers: confirm the website sends the right data to GTM, that GTM fires the right tags, and that GA4 receives and processes the events correctly.

1. GTM Preview mode (Tag Assistant) — connect to the site and step through each message in the dataLayer. For every event, check which tags fired and which did not, the trigger conditions that passed or failed, and the value of every variable at that moment. This is where most problems are found.
2. GA4 DebugView — found under Admin. Events from a debug session appear in real time with all their parameters and user properties. Preview mode enables debug mode automatically; otherwise use the debug_mode parameter or the Google Analytics debugger extension.
3. Browser developer tools — in the Network tab, filter for collect requests to see exactly what is sent to GA4: the Measurement ID, the event name and the parameters. This catches duplicate requests from a hard-coded tag and a GTM tag running at the same time.
4. Consent checks — Tag Assistant shows the consent state for each event. Tags that are blocked because consent is denied look like broken tags if you forget to check.
5. Realtime report — a final check after publishing that events are arriving from real users.

After publishing:

• Compare key event counts with the source of truth, such as orders or applications in the database, over the first few days.
• Check reports for (not set) values that indicate missing parameters, and review the event list for unexpected names.
• If BigQuery is linked, query the intraday table for exact detail on individual events.

Good process: test on a staging environment using GTM environments, write version notes for each publish, and keep the previous container version ready to restore if something breaks.

Note: Remember that standard GA4 reports take time to process, often up to a day or more. Use DebugView and Realtime for verification, and do not panic when a new event is missing from standard reports an hour after release.

In a single-page application (SPA) built with frameworks such as React, Angular or Vue, the browser loads the page once and then changes routes with JavaScript. No full page load happens, so a basic tag setup records only the first page view and attributes the whole visit to the landing page.

Option 1: enhanced measurement history events. In the web stream's enhanced measurement settings, page views include an advanced option, “Page changes based on browser history events”. When the app updates the URL with the History API, GA4 sends a page_view automatically. This is quick, but check for:

• Stale titles — the page view may fire before the app updates the document title, so reports show the previous page's title.
• Duplicates — some routers replace the URL several times per navigation, or query parameter changes trigger extra page views.
• Missing views — routes that do not change the URL are not counted.

Option 2: manual virtual page views (more control). Turn off the history-based option, then have the router push a dataLayer event after each route change has finished rendering:

window.dataLayer.push({
  event: 'virtual_page_view',
  page_location: window.location.href,
  page_title: document.title,
  page_type: 'job_listing'
});

In GTM, a Custom Event trigger on virtual_page_view fires a GA4 event tag that sends page_view with these parameters. The Google tag in GTM should not send its own automatic page view on route changes, so you do not count pages twice.

Other SPA considerations: set page_referrer to the previous in-app URL if you need accurate internal referrers, reset page-specific dataLayer values between routes, and make sure e-commerce and key events fire after the relevant data has loaded.

How to verify: in Preview mode and DebugView, navigate through several routes and confirm exactly one page view per route with the correct location and title.

Note: Agree with developers where the tracking call lives, ideally in one central router hook. Scattering page-view pushes across components is how duplicate and missing page views creep in.

A funnel exploration, found in the Explore section, shows how many users complete each step of a process and where they drop off. Unlike the fixed goal funnels of Universal Analytics, GA4 funnels are built from existing event data, so you can create one today and view historical periods within your data retention window.

Building one:

1. Define up to 10 steps, each based on events, page paths or parameters. For example: view job listing, click Apply, upload resume, submit application.
2. Choose how steps relate: indirectly followed by (other actions may happen in between, which is the default) or directly followed by (the next event must be the very next step).
3. Optionally add a time constraint, such as submission within 30 minutes of clicking Apply.
4. Add a breakdown dimension such as device category or first-user channel, and segments to compare groups.

Open and closed funnels:

• Closed funnel (the default) — users must enter at step 1 to be counted. Use it for linear processes such as checkout, where starting halfway is not meaningful.
• Open funnel — users can enter at any step and are counted from the step where they joined. Use it when users can arrive directly at later steps, for example landing straight on the application form from an email.

Useful features:

• Trended funnel — shows completion rates for each step over time, to confirm whether a fix improved things.
• Elapsed time — the average time between steps.
• Next action — shows what users did instead after dropping out of a step.
• Create segment from step — right-click a drop-off to build a segment or audience of abandoners for deeper analysis or remarketing.

Note: Funnels in GA4 count users, and thresholding may hide small numbers. For exact counts or custom logic, such as session-scoped funnels, replicate the funnel in BigQuery.

A path exploration shows the sequences of events or pages users go through, displayed as a tree diagram. Instead of testing a path you already know about, as a funnel does, it lets you discover the paths users actually take.

How it works:

• Starting point — pick a node such as a page title, page path, screen name or event name, and see what users did in the following steps. Click any node to expand the next step.
• Ending point (backward pathing) — pick an outcome such as purchase or application_submitted and see what users did in the steps before it.
• Node type can be changed at each step, for example page paths first, then events.
• View unique nodes only collapses repeated consecutive steps, such as refreshing the same page, so the diagram stays readable.
• Segments, filters and breakdowns work as in other explorations.

Questions it answers well:

• What do users do after landing on the homepage? Do they search, browse categories, or leave?
• Which pages do users visit just before a purchase or sign-up, so those pages can be improved or promoted?
• Where do users go after an error page, or after abandoning the checkout?
• Are users stuck in loops, such as going back and forth between pricing and features pages?
• How do journeys differ between mobile and desktop users, or new and returning users?

Tips for clean results: event-name paths fill up with automatic events such as session_start, user_engagement and scroll, so filter them out or use page-based nodes. Keep the date range focused, because long ranges produce huge, noisy trees.

Note: Use path exploration to generate hypotheses, then confirm them with a funnel exploration or a test. A striking path involving a handful of users is a lead to investigate, not a finding to present.

Segment overlap exploration compares up to three user segments and shows how they intersect, as a Venn diagram and a table of every combination.

• Example question: how many users who came from paid social also used the mobile app, and how many of those also purchased?
• Typical uses: checking whether audiences for different campaigns overlap before splitting budgets; finding the most valuable intersection, such as newsletter subscribers who are also mobile app users, to target them; and validating an audience definition before building it.
• Each segment's size and the size of every overlap can be shown with any metric, such as key events or revenue, and any intersection can be saved as a new segment.

Cohort exploration groups users by a shared characteristic, usually when they were first acquired, and tracks how each group behaves over the following days, weeks or months.

• Inclusion criteria — what puts a user into a cohort. By default this is first touch (first visit or first open), but it can be any event, such as the first purchase.
• Return criteria — what counts as coming back: any event, a transaction, or a specific event.
• Granularity — daily, weekly or monthly cohorts.
• Calculation — standard (active in that period), rolling (active in that period and every period before it) or cumulative (running totals, useful for revenue per user).
• Breakdown — compare cohorts by first-user channel or device.

Typical uses of cohorts: measuring retention after a product change (does the March cohort return more than the January cohort?), comparing the long-term value of users acquired from different channels, and spotting when users usually stop returning, which tells you when a re-engagement email should go out.

Note: Cohort analysis is where GA4 data retention matters most. With the default two-month setting you cannot follow cohorts for long, so set retention to 14 months, or use BigQuery for longer retention studies.

GA4 uses machine learning to predict what users are likely to do in the near future, based on their past behaviour. There are three predictive metrics:

• Purchase probability — the likelihood that a user active in the last 28 days will make a purchase in the next 7 days.
• Churn probability — the likelihood that a user active in the last 7 days will not be active in the next 7 days.
• Predicted revenue — the expected revenue from all purchases in the next 28 days by a user active in the last 28 days.

Predictive audiences are built on these metrics. The Audience builder offers ready-made templates, such as likely 7-day purchasers, likely 7-day churning users and predicted 28-day top spenders, and you can also add a predictive condition to a custom audience. Because audiences can be shared with a linked Google Ads account, you can bid more on users likely to buy, or run retention campaigns for users likely to churn, before they leave.

Eligibility requirements (from Google's documentation; check the current version):

• Enough positive and negative examples — a minimum number of returning users (on the order of 1,000) who triggered the relevant condition, such as a purchase, and a similar number who did not, within a recent period.
• Sustained model quality over a period of time; eligibility can be lost if data volume falls.
• The right events — purchase probability and predicted revenue need the recommended purchase event (or in_app_purchase for apps) with value and currency. Custom purchase event names are not used.

The Predictive section of the audience builder shows whether each metric is currently available for the property.

Where you can use them: in the audience builder, as dimensions and metrics in Explorations, and in the BigQuery user data export.

Note: Treat predictions as a targeting aid, not ground truth. Before scaling spend on a predictive audience, compare its actual purchase rate with a control audience over a few weeks to confirm the model is adding value for your business.

Traffic from employees, agencies and developers can inflate sessions, distort conversion rates and pollute funnels, especially on smaller sites. GA4 handles this with data filters, found in Admin under Data collection and modification.

Internal traffic filter:

1. In the web data stream, go to Configure tag settings, then Define internal traffic, and create a rule based on IP addresses (exact match, begins with, ranges and so on). Matching events receive the parameter traffic_type=internal. You can also set this parameter yourself, for example through GTM for remote staff who have a special cookie.
2. Create a data filter of type Internal traffic that excludes events with that traffic_type value.

Developer traffic filter: excludes events sent with debug mode on, such as events from GTM Preview mode or the debug_mode parameter, so testing does not appear in reports but remains visible in DebugView.

Filter states:

• Testing — the filter is evaluated, and matching data is labelled with a “Test data filter name” dimension instead of being excluded. Use this to confirm the filter catches the right traffic.
• Active — matching data is permanently excluded from processing.
• Inactive — the filter is not applied.

Risks and limitations:

• Exclusion is permanent — data excluded by an active filter cannot be recovered, so always run a filter in Testing state first.
• Filters are not retroactive — they apply only to data collected after activation.
• IP rules age badly — office IPs change, remote work uses home broadband, and IPv6 addresses vary. Review the rules regularly.
• There is a limit on the number of data filters per property, so plan them rather than creating one per office.
• Filtering out too much, such as a whole ISP range, removes real customers.

Note: Also configure unwanted referrals for payment gateways and SSO domains. It is a separate setting from data filters, but it solves the related problem of your own infrastructure distorting source attribution.

A channel group sorts traffic into broad categories such as Organic Search, Paid Search, Email, Referral, Organic Social, Paid Social, Display, Affiliates and Direct. GA4 assigns each session to a channel by applying rules, in order, to the source, medium and sometimes the campaign name.

Default channel group: Google-defined rules that use lists of known sources, such as search engines and social networks, together with medium patterns. For example, a session is Email if the source or medium matches “email” or its common variants; it is Paid Search if the source is a known search engine and the medium matches a paid pattern such as cpc or ppc.

Custom channel groups: in Admin under Channel groups, you can copy the default group and edit or reorder its rules, for example adding a “Job Boards” channel for specific referral sources or separating brand and non-brand paid search by campaign name. Custom channel groups apply to historical data as well, which makes them safer to experiment with than filters. Standard properties can create only a small number of them.

Why traffic lands in Unassigned: Unassigned means no rule matched the session.

• Non-standard UTM values — for example utm_source=mailchimp&utm_medium=newsletter may match no rule, because neither value matches the Email pattern, so it falls into Unassigned.
• Inconsistent tagging — values such as “fb-ads”, “paid_social_story” or “whatsapp-share” that the rules do not recognise.
• Measurement Protocol events without session information, which cannot be tied to a session source.
• Events recorded without a session_start, for example after consent is granted partway through a visit.

How to fix it: publish a UTM naming guide with approved lowercase source and medium values that match Google's rules (email, cpc, social, affiliate, display), use a shared URL builder, audit the Unassigned rows by source and medium each month, and add custom channel rules only for genuinely new channels.

Note: Check the current default channel definitions in Google's documentation before writing your UTM guide. The rules use specific source lists and medium patterns, and tagging to match them is far easier than correcting reports later.

Custom definition quotas for a standard GA4 property are, at the time of writing:

Archiving a custom dimension frees the slot, but its data is no longer available in reports, so manage the list deliberately.

Cardinality is the number of unique values a dimension has. A dimension such as article_category with 20 values has low cardinality; one holding order IDs, timestamps, search terms or full URLs with query strings can have millions of values, which is high cardinality.

The (other) row: GA4 processes reports into tables with limits on the number of rows stored per day. When a report's data exceeds those limits, GA4 groups the remaining, less frequent values into a single row labelled (other). High-cardinality custom dimensions are the usual cause, and once a row is grouped into (other), the detail cannot be recovered in that report.

How to avoid or work around it:

• Do not register identifiers as custom dimensions — transaction IDs, session IDs, user IDs and timestamps belong in BigQuery, not in reports.
• Normalise values — strip query parameters from URLs, lowercase text, group search terms or prices into buckets.
• Use Explorations, which query event data and are generally less affected than standard reports, although sampling and thresholding can apply.
• Use BigQuery for detailed analysis of high-cardinality data, where there is no (other) row.
• Narrow the date range or add filters, which can reduce the number of rows a report needs.

Note: Quotas and limits change between product updates, so treat the numbers as reference points and check the current documentation. The underlying principle of registering only low-cardinality, decision-relevant dimensions will not change.

GA4 can recognise the same person using several identity signals, applied in priority order:

• User-ID — your own persistent, non-personal identifier for logged-in users, sent as the user_id parameter. It is the most accurate way to join sessions across devices and platforms.
• Device ID — on the web, the client ID stored in the first-party _ga cookie; in apps, the app instance ID. It identifies a browser or app installation, not a person.
• Modelling — when consent is denied and no identifiers are available, GA4 can estimate behaviour using data from similar consented users, if Consent Mode behavioural modelling is active.

Reporting identity, set in Admin under Data display, decides which signals reports use:

Changing reporting identity does not change data collection. It only changes how existing data is presented, so you can switch it and compare.

Implementing User-ID well: send a stable internal ID after login (never an email address, phone number or anything else that identifies a person directly), stop sending it after logout, disclose its use in your privacy policy, and send it with every event while the user is logged in, not just the login event.

Why it matters: without User-ID, a candidate who browses jobs on mobile and applies on a laptop appears as two users, and the mobile channel that started the journey gets no credit.

Note: Google signals no longer feeds reporting identity, but enabling it can still cause thresholding in some reports that include demographics. If numbers are being withheld, check both the Google signals setting and whether demographic dimensions are in the report.

The Measurement Protocol lets you send events to GA4 directly from a server or other system through HTTPS requests, instead of from the browser or app SDK. It is designed to supplement tag-based collection, not replace it.

How a request looks: a POST to https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXX&api_secret=YOUR_SECRET with a JSON body such as:

{
  "client_id": "1234567890.1712345678",
  "events": [{
    "name": "offline_purchase",
    "params": { "value": 4999, "currency": "INR", "transaction_id": "T1001" }
  }]
}

The API secret is created in the web data stream settings. For app streams, you send app_instance_id and a Firebase app ID instead.

Good use cases:

• Offline and delayed outcomes — a lead that becomes a paying customer in the CRM weeks later, refunds, or subscription renewals.
• Server-confirmed transactions — sending the purchase from the server when payment is confirmed, so ad blockers or users closing the tab before the thank-you page do not cause lost orders.
• Non-browser devices — kiosks, point-of-sale systems or other connected devices.

Limitations and gotchas:

• You must supply the identifiers — to link the event to the right user, store the client_id from the _ga cookie (and user_id if available) at the time of the web visit. A random client ID creates a new, unattributed user.
• Session attribution — include session_id and engagement_time_msec in parameters if the event should join an existing session; otherwise it may appear with no source or as Unassigned.
• No automatic context — browser details such as device and page information are not collected automatically.
• Limited backdating — events can carry a past timestamp only within a short window (currently 72 hours).
• Silent failures — the collection endpoint does not report errors, so validate payloads against the /debug/mp/collect endpoint during development.

Note: Keep the API secret on the server only. Anyone with the Measurement ID and secret can send data into your property, so never expose them in client-side code.

Google Ads link (set up in GA4 Admin under Product links, or from Google Ads):

• Key event import — GA4 key events can be imported into Google Ads as conversions and used for Smart Bidding.
• Audience sharing — GA4 audiences, including predictive audiences, become available for targeting and remarketing in Google Ads, subject to consent and personalised advertising settings.
• Cost and click data in GA4 — Google Ads campaigns, clicks and cost appear in GA4 reports, so cost per key event and return on ad spend can be compared with other channels.
• Cross-channel attribution — data-driven attribution can credit Google Ads alongside other channels, instead of each platform claiming conversions separately.

Search Console link (one web data stream to one Search Console property):

• Adds Google organic search queries and Google organic search traffic reports, showing impressions, clicks, CTR and position next to GA4 engagement and key event data by landing page.
• These reports sit in the Library and must be published into the navigation before most users can see them.
• Query data comes from Search Console and cannot be joined to individual GA4 events, so you cannot see key events per search query, only per landing page.

What to check after linking:

• Auto-tagging is on in Google Ads, and the gclid parameter survives redirects on the landing pages; otherwise paid clicks appear as organic or direct.
• No manual UTMs overriding auto-tagging on Google Ads links.
• No double counting — if both the Google Ads conversion tag and an imported GA4 key event track the same purchase, make only one of them a primary conversion action for bidding.
• Currency and time zone are consistent between the accounts, so revenue and dates reconcile.
• Personalised advertising is enabled where appropriate and consent settings are correct, or audiences will not populate.

Note: Remember that Google Ads and GA4 report conversions differently even when linked, using different attribution models, windows and reporting dates. Set expectations with stakeholders before they compare the two side by side.

The native GA4 connector in Looker Studio is convenient, but it queries the GA4 Data API live every time a chart loads, and that creates several practical problems.

Common limitations:

• API quotas — each property has limits on API tokens per hour and per day. A dashboard with many charts, many viewers or frequent filter changes can exhaust them, and charts then show errors until the quota resets.
• Incompatible fields — some dimensions and metrics cannot be combined, especially across scopes (for example, a user-scoped custom dimension with an event-scoped metric), which causes errors or empty charts.
• Thresholding and (other) — the same privacy thresholds and cardinality limits that apply in the GA4 interface also apply through the API.
• Custom definitions — parameters must be registered as custom dimensions to be available, and only from the registration date.
• Performance — live queries over long date ranges make dashboards slow to load.
• Blending pitfalls — blending GA4 with other sources in Looker Studio is limited and can produce misleading joins if keys and date ranges do not align.

Workarounds:

• BigQuery as the source — build scheduled summary tables from the GA4 export and connect Looker Studio to those. This removes API quotas, thresholding and (other) rows, and makes dashboards fast. It is the standard approach for business-critical reporting.
• Extract Data — Looker Studio's extract connector stores a snapshot of the query results, refreshed on a schedule, reducing API calls.
• Design efficiently — fewer charts per page, shared filters, sensible default date ranges, and caching (data freshness) settings appropriate to how often the data really changes.
• Third-party connectors — some teams use paid connectors that cache data in their own warehouse.
• Credentials — decide deliberately whether the data source uses the owner's credentials or the viewer's, which affects both access and quota usage.

Note: When numbers in Looker Studio do not match GA4, first check the date range, time zone, filters, reporting identity and whether the chart mixes scopes. Most “bugs” turn out to be one of these.

(not set) is a placeholder that GA4 shows when a dimension has no value for the rows in a report. A small amount is normal; a large or growing share points to a tracking or configuration issue. The fix depends on which dimension is affected.

• Landing page (not set) — the session had no page_view event, for example because a new session began after the timeout with a background event such as a timer. Check for tags that fire without page views.
• Session source or medium (not set) — events that could not be tied to a session source, such as Measurement Protocol events sent without session details, events before consent was granted, or data from unusual browsers and bots. Fix by sending session_id and client_id with server-side events and by reviewing the consent implementation.
• Custom dimension (not set) — the parameter was not sent with the event in that row. This often happens when a dimension is combined with events that never carry it (for example, article_category alongside session_start), when the parameter name differs in spelling or case, or for dates before the dimension was registered. Filter to the events that should carry the parameter before judging.
• Page title (not set) — common in single-page apps where the page view fires before the title updates, or on pages without a title element.
• Country or city (not set) — GA4 could not determine a location from the IP address, which happens with some VPNs, proxies and corporate networks.
• Google Ads dimensions (not set) — auto-tagging is off, the gclid is stripped by a redirect, or the Ads account is not linked.

How to investigate: build an exploration with the affected dimension plus event name and page location, look for patterns such as one event or one template, and confirm fixes in DebugView.

Note: Do not confuse (not set) with (other). (not set) means the value is missing; (other) means values exist but were grouped because the report exceeded its row limits.

Knowing these rules prevents events from silently failing or splitting across different names. The main ones, at the time of writing, for standard properties:

Naming rules:

• Event names are case-sensitive: Sign_Up and sign_up are two different events.
• Names must start with a letter and use only letters, numbers and underscores; no spaces or hyphens.
• Certain prefixes such as google_, ga_ and firebase_ are reserved, and names used by automatic events (for example session_start and first_visit) must not be reused for your own events.
• Parameter and user property names follow similar rules and have their own reserved names.

Length and count limits:

App streams also limit the number of distinct event names per app instance. Values that exceed a length limit are truncated, and events that break naming rules can be dropped, often without a visible error.

Practical conventions:

• Use lowercase snake_case throughout, matching Google's recommended events.
• Prefer a small number of general events with descriptive parameters, such as cta_click with a cta_name parameter, over hundreds of specific event names.
• Keep a data dictionary listing every event and parameter, with allowed values.
• Do not put personal data or long free text, such as full search queries with personal details, into parameters.

Note: Quotas differ for GA4 360 and change over time, so quote them as “at the time of writing” in an interview and show that you know where to check. The naming principles are what really prevent problems.

In client-side tagging, the user's browser loads every vendor's script (GA4, Google Ads, Meta and others) and sends data directly to each vendor. In server-side tagging, the browser sends a single stream of data to a GTM server container that you run on your own subdomain, such as data.example.com. The server container then processes the data and forwards it to each vendor.

How it is set up: the server container is hosted on cloud infrastructure (Google Cloud is the default option, and other hosts are supported). The web container, or the Google tag, is configured to send data to your server URL. In the server container, clients receive incoming requests and turn them into event data, and tags send that data to vendors.

Benefits:

• Performance — fewer third-party scripts in the browser, which can improve page speed and INP.
• Data control — you can remove or hash fields, drop IP addresses, and decide exactly what each vendor receives, which supports privacy compliance.
• Data enrichment — add server-side information, such as profit margin or customer tier, before sending it on.
• More durable first-party cookies — cookies set by your own server are less affected by some browser restrictions on cookies set by JavaScript.
• Better conversion APIs — cleaner integration with server-to-server APIs such as Meta's Conversions API.

Trade-offs:

• Cost — you pay for hosting, which grows with traffic, plus monitoring.
• Complexity — more infrastructure, deployment and debugging skills are needed.
• Not a consent workaround — consent rules apply exactly as before. Using server-side tagging to track users who declined, or to evade ad blockers against users' wishes, creates legal and ethical risk.
• Some vendors still need a client-side script for features such as on-page experiments or heatmaps.

Note: A sensible answer recommends server-side tagging for sites with many vendors, strict privacy needs or significant ad spend, and simple client-side tagging for smaller sites where the cost and complexity outweigh the gains.