Web Analytics:
What It Is and How to Use It

Web analytics is the collection and analysis of website activity to understand where visitors come from, which pages and actions they use, and whether they complete a website’s goals. As Adobe’s explanation of website analytics describes, it covers traffic sources, pageviews, navigation paths, interactions, and conversions. These measurements help identify what to improve in a website’s content, navigation, and completion paths.

What web analytics is used for#

Web analytics connects three parts of website performance: acquisition, behavior, and outcomes. Acquisition describes how visits arrive. Behavior describes activity within the site. Outcomes describe completed goals, including purchases, registrations, and submitted forms, within the scope of Adobe’s website analytics guide.

Read those parts together when deciding where to focus an improvement. For acquisition, compare traffic sources against completed goals. For content, examine the pages people visit and the actions associated with them. For navigation, examine the route to a goal and the steps where recorded activity stops. Choose the report around the question being investigated rather than starting with every available metric.

How web analytics collects data#

A common collection method places a JavaScript tracking tag on website pages. The tag sends activity to an analytics service, which processes it into reports. Matomo’s architecture documentation describes this sequence: its browser tracker sends data to a tracking API, data is stored, and an archiving process aggregates it for reporting.

Google Analytics 4, usually shortened to GA4, organizes measurement around events. An event records an interaction; parameters supply details about that interaction. Google’s event documentation covers page loads, link clicks, and purchases, and distinguishes automatically collected, enhanced measurement, recommended, and custom events. Installing a tag starts collection, while the event configuration determines which additional actions are recorded.

Collection also affects visitor counts. In its default website implementation, GA4 uses a client ID stored in a first-party cookie to distinguish users and sessions; it does not store that client ID when analytics storage is deactivated through consent mode. Read a reported user count with its identifier and consent settings in mind. Treating it as an exact count of distinct people would go beyond what that collection method establishes.

The main web analytics metrics#

Metric names need their product definitions. The table below uses GA4 definitions where specified, so the same label in another tool needs a separate check.

GA4’s default engaged-session criteria are a session lasting longer than 10 seconds, containing a key event, or containing at least two page or screen views, according to Google’s engagement and bounce-rate definitions. Its bounce rate therefore measures failure to meet those criteria. A single-page visit can still qualify as engaged. Check this definition before comparing a GA4 bounce rate with a tool that uses a different rule.

Conversion rates need a defined denominator#

A conversion is completion of a selected goal. In GA4 reporting, the important action is called a key event; Google’s key-event documentation separately explains how a key event can be used to create a Google Ads conversion. Keep that product terminology visible when naming a report.

For a session-based rate, GA4’s session key event rate uses this calculation:

Sessions containing a key event ÷ total sessions × 100.

Select the particular key event being evaluated, then use the same date range and filters for both parts of the calculation. Count a session containing that event once in the numerator. Dividing the total number of repeated event occurrences by sessions answers a different question: events per session.

For a page-specific analysis, define the eligible population as well: sessions landing on that page, sessions visiting it anywhere in the journey, or another explicitly named group. Display the completion count, eligible-session count, and resulting rate together. This makes the scale of the activity visible alongside the percentage.

How to read traffic, pages, and results#

Start with traffic sources#

GA4’s Traffic acquisition report describes session sources and channels for new and returning visitors. Its User acquisition report focuses on how new users were acquired. Choose the report that matches the question: the origin of visits during the selected period or the acquisition of new users.

For campaign links, Google’s custom-URL guidance explains how utm_source, utm_medium, and utm_campaign identify the referrer, marketing medium, and campaign. Use a consistent naming convention. Google treats parameter values as case-sensitive, so inconsistent spelling and capitalization can split one campaign across separate rows.

Compare sources using both traffic volume and the selected completion metric. Keep page, device, date-range, and event filters aligned. Review the sample size behind a percentage before prioritizing a channel, and use completed goals to assess whether its recorded traffic serves the website’s purpose.

Examine landing pages and navigation#

GA4’s Pages and screens report includes pages visited anywhere in a session. The Landing page report identifies the first page, while path exploration examines pages visited before or after a selected page. These answer different questions about entry points and movement within the site.

Use landing-page analysis to compare entry points against the same goal. Use page analysis to inspect individual content and its associated actions. Use a sequence of defined steps to examine progress toward completion. Keep the starting population and counting unit consistent throughout that sequence; mixing users, sessions, and event occurrences prevents the steps from describing a coherent path.

Treat a drop-off as a place to investigate. Inspect the content, links, form validation, and confirmation behavior at the relevant step. Recorded counts establish how much measured activity reached each step; determining why it stopped requires examining the experience itself.

Read attribution with its model#

Attribution assigns credit for an important action to preceding touchpoints. Google’s attribution documentation explains that a model uses rules or a data-driven algorithm to distribute that credit. State the model when comparing attributed results across channels.

Use attribution to understand how the reporting system allocates credit. Evaluate claims about the effect of a campaign or website change with evidence appropriate to the claim. Record concurrent changes to content, campaigns, and measurement before interpreting a before-and-after difference as an improvement caused by one change.

How to set up useful measurement#

Start with a short list of completed goals and the actions needed to measure them. The following sequence keeps setup connected to the reports it must support.

1. Define each completion. Write down its event name, trigger, and relevant page or form. For submission measurement, specify successful acceptance as the completion point and track attempts separately when needed.
2. Configure collection. Review the actions already collected and those needing additional setup. Google’s event setup guide distinguishes automatic collection from recommended and custom events requiring implementation.
3. Select the important outcomes. In GA4, mark the corresponding events as key events so they appear as important actions in reporting.
4. Verify the implementation. GA4’s DebugView displays collected events and their parameters in real time after debug mode is enabled. Perform the action and check its name, timing, parameters, and repeat behavior against the written definition.
5. Create a focused review. Track the chosen completion count and rate, then break the results down by source and page. Document changes to the site and measurement, and repeat verification after modifying a tracked interaction.

Keep confirmed website actions separate from later records such as accepted requests or completed orders. Compare analytics counts with the system that records those outcomes using aligned definitions and dates. Investigate discrepancies before using an analytics event as the basis for a business-result claim.

Privacy and measurement limits#

Consent choices affect collection. Google’s consent-mode overview distinguishes basic mode, which blocks tags until consent, from advanced mode, which can send measurements without cookies while consent is denied. Consent mode adjusts tag behavior; obtaining and communicating the visitor’s choice is a separate responsibility.

Record changes to consent settings alongside traffic trends. Those settings affect the data available for comparison, so investigate collection changes as well as changes in website use. During testing, Google warns that client-side privacy controls and ungranted Analytics-cookie consent can prevent events from appearing in DebugView.

Google’s data safeguards guidance prohibits sending personally identifiable information to Google Analytics. Review event parameters and page URLs for personal details before sending them. Use analytics fields to describe interactions and keep contact information in the system intended to handle it.

Choosing a web analytics tool#

Google Analytics is one tool for doing web analytics; the term refers to the broader practice. Compare tools against the reports, collection approach, and hosting arrangements the website needs.

Before selecting a tool, list the essential goals, report breakdowns, history, exports, and maintenance responsibilities. Check those requirements against the product documentation. Then verify collection and the main completion path before relying on its reports for website decisions.