Website Analytics Explained: GA4, Search Console and a Practical Improvement Workflow
Published:
Last Updated:
Category: Web Analytics
Authors: Shusaku Yosa
Website analytics measures activity and uses it to make improvement decisions. The starting point is not “How many visits did we get?” but a question such as “Where do intended visitors struggle to reach the consultation form?”
Terms such as web analytics and the Japanese term access analysis can overlap in practice. This guide focuses on measuring and analysing website behaviour, while separating collection methods from the later work of implementing improvements.
Start with a decision, not a dashboard
Choose one question that could change what the team does. “Improve the website” is too broad to define a useful measure. If the question concerns organic visitors reaching a form, keep the organic-entry population consistent throughout the investigation.
Question | Useful data | Important limit |
|---|---|---|
Are we visible in search? | Search Console pages, queries, impressions and clicks | Search-result measures; not all queries are visible |
Do visitors progress? | GA4 landing pages, session channels and engagement | Match host, language and period |
Where does the form fail? | Starts, errors and accepted submissions | Validate event conditions and duplicates |
Did a business outcome occur? | Validated success and business records | Events are not automatically registered people or sales |
This mapping keeps unrelated fluctuations from taking over the analysis. Next, establish whether the required data is actually available and fit for the question.
GA4, Search Console and server logs answer different questions
GA4 describes collected website or app events. Search Console describes visibility and clicks in Google Search. Server logs record requests and processing. Their observation points and conditions differ, so none should be treated as a complete record of every visitor action and outcome.
Search Console clicks and GA4 Organic Search landing sessions do not have to match. Check collection, consent, blocking, time zones and canonical-URL aggregation. Visible queries can also exclude anonymised information, so their totals may differ from page totals. Do not invent the hidden queries.
A missing search-performance row does not establish that a URL is currently unindexed. Inspect its indexing status separately when that is the question. Google documents the report in Search performance help.
A metric dictionary for users, sessions and events
Write down units and denominators before comparing numbers. Calling users, sessions and events “traffic” can hide important differences.
Measure | Unit or definition | Interpretation limit |
|---|---|---|
Total users | Unique users who triggered an event in the period | Not a verified census or the same as Active users |
Sessions | Groups of activity | A user can have several |
Views | Page or screen displays | Includes repeats; check web/app scope |
Engagement rate | Proportion of engaged sessions | Check the applicable conditions |
Bounce rate | Proportion of sessions that were not engaged | Not simply immediate exits |
Event count | Recorded occurrences | Not automatically unique successes or people |
By default, an engaged GA4 session lasts longer than 10 seconds, has a key event, or has at least two page or screen views. Check the actual settings. The definitions are in Google’s guides to engagement and bounce rate, users and sessions.
Engagement time reflects browser focus or an app being in the foreground. It does not prove reading or comprehension. Per-user and per-session averages have different denominators, so inspect the actual metric label. See User engagement.
Check data quality and outcome definitions first
When a chart changes, distinguish a behavioural change from a collection change. Production/test traffic, missing tags and repeated events can all affect the interpretation.
- Confirm the property and production hostname.
- Document landing pages, language, channel, dates and time zone.
- Test representative actions for missing or duplicate events.
- Check coverage under consent and browser conditions.
- Inspect required arrivals and successes after authentication or domain changes.
- Validate the success condition and its relationship to business records.
A button click is not proof of registration. Check that a submission was accepted, that reloads do not inflate the relevant measure, and that business records support any claimed people or customer count. If this is unverified, mark outcomes as unmeasured. Zero recorded key events does not establish that no real outcomes occurred.
Google documents consent-state updates in its implementation guide. Its PII guidance also explains why URLs and input fields need review before data is sent.
Analyse the journey from landing page to verified outcome
With the conditions established, follow entry, engagement, the next action and validated success. Keep all-channel traffic separate from Organic Search when the question is about search. Segment further only when it helps answer the question and the available data supports it.
Stage | Observation | Next check |
|---|---|---|
Entry | Target landing sessions | Are these the intended visits? |
Engagement | Relevant engagement and actions | Is collection complete, and does the page fulfil the entry promise? |
Next action | Form start or arrival at a relevant feature page | Is the next step understandable? |
Success | Validated acceptance or completion | Are errors, duplicates or record mismatches present? |
A short time or low rate does not establish that the text is poor. A quickly completed task, measurement problem or audience mismatch may explain it. List plausible explanations and select a specific observation or change that could distinguish them.
Compare matched periods and record alternative explanations
This fictional comparison uses two 28-day periods, the production host, one language and Organic Search landing sessions. The success measure is deduplicated sessions containing a verified success, not registered people.
Measure | Before: 28 days | After: 28 days |
|---|---|---|
Landing sessions | 100 | 120 |
Sessions with verified success | 5 | 6 |
Share containing success | 5 ÷ 100 = 5% | 6 ÷ 120 = 5% |
The absolute counts increased, but the rate remained 5%. Do not claim a rate improvement. A before/after difference also does not isolate a rewrite’s effect if seasonality, demand, advertising or other site changes occurred. Small outcome counts require particular care.
Keep a record of the hypothesis, change and publication date, target URLs, comparison conditions, other changes, unmeasured fields and next check. If success is not yet validated, do not calculate this outcome comparison. Resolve that gap first, then choose one improvement with a clear evaluation plan.
