Web analytics vs. Google Analytics 4 – what you should know?

Web analytics and Google Analytics 4 are often lumped together, although in practice they mean two different things. Web analytics is an approach to working with data: from defining goals, through implementing measurement, to analysis and making changes to the website or campaigns. GA4 is one of the tools that makes it easier to collect and analyse this data. The most important thing is that implementing GA4 on its own does not yet give you useful analytics if you do not know what to measure and why. For this reason, many companies have reports and yet still do not get clear answers to questions about the business. For data to genuinely support decisions, goals, events, implementation quality and subsequent optimisation actions need to be aligned.

Differences between Web Analytics and Google Analytics 4 in practice

Web Analytics covers the whole process of planning and using data, whereas Google Analytics 4 is a tool for collecting and analysing a slice of that information. This difference matters in day-to-day work, because you can have GA4 set up correctly and still not be doing analytics in an organised way. In such a situation, the data does reach the system, but it does not help assess the effectiveness of campaigns, forms or the purchase journey.

Web analytics starts with business questions. You need to determine which user actions are actually key: a purchase, form submission, registration, contact by phone, downloading an offer or moving to a specific step. If there are no clearly defined goals, reports quickly turn into a set of numbers with no decision-making value.

GA4 is primarily responsible for the technical layer of measurement. It records events, assigns parameters to them, provides reports and makes it possible to combine data with other Google tools, for example Google Ads. That is a major benefit, but it does not cover topics such as the sensible selection of conversions, campaign tagging quality, compliance with privacy policy or the correct interpretation of results.

In practice, web analytics also includes elements that are not immediately visible in the GA4 interface itself. This includes, among other things, data validation, excluding internal traffic, separating the test environment from production, checking for duplicate events and ensuring consistent consent logic. It is data quality that most often determines whether the conclusions drawn from reports are reliable.

It is also worth remembering that GA4 is not the only source of truth about the business. Sales data, CRM, order management systems or the backend often show a different slice of reality than the analytics tool. Discrepancies between systems are natural when users, sessions or conversions are counted differently, or when different filters and traffic source attribution rules are in operation.

Put simply, web analytics answers the question of what to measure, why to measure it and what decisions should follow from that, while GA4 helps you collect and analyse that data from a technical perspective. For this reason, well-implemented analytics does not end with setting up tags. It is only complete when the data translates into a concrete change in a campaign, content, UX or the sales process.

How the event-based model works in GA4

The event-based model in GA4 works so that every significant user interaction is sent to the system as an event supplemented with additional parameters. An event can be a page view, click, scroll, form start, purchase or moving to the next checkout step. Parameters make the context more precise, for example the form name, transaction value, product category or click location.

This approach moves away from the older way of thinking, where the weight of reporting rested mainly on sessions and page views. In GA4, sessions still exist, but they stop being the only point of reference. This makes it easier to measure user behaviour in a more flexible way, especially when the path is not linear and involves many interactions before conversion.

In practice, everything starts with translating a business goal into a measurement plan. If a company wants to measure leads, it needs to define which event will count as a genuine lead acquisition, which parameters are worth recording and when to mark that event as a conversion. The most common mistake is collecting a very large number of interactions without any clarity about which of them really matter to the business.

The implementation itself is most often carried out through Google Tag Manager and properly configured tags. At this stage, basic events, more detailed interactions and, if relevant, measurement of e-commerce, forms and cross-domain journeys are set up. If the website has custom elements, a dataLayer is often needed, because without it some key data will not be available in a stable, repeatable way.

After implementation, validation is essential. It is worth checking in debug mode whether events trigger at the right moment, whether they are duplicated after refreshing the page, whether parameters have the correct values and whether conversions are not marked too broadly. Problems often only become apparent after a change to the form, checkout or site structure, which is why checking should not be a one-off task.

In the end, what matters is not the event catalogue itself, but how it is used in analysis. Events make it possible to assess where valuable traffic comes from, where users drop off, which landing pages engage users, and which merely generate visits without any effect. GA4 has the greatest value when events are tied to regular analysis and concrete optimisation decisions, rather than being limited to reporting alone.

Key steps in implementing and configuring Google Analytics 4

Proper GA4 implementation comes down to setting up measurement that collects data aligned with the company’s goals and is genuinely suitable for later analysis. In practice, the process starts with determining what should be measured, and only then moves on to configuring the tool. If this stage is skipped, GA4 will register plenty of technical events, but few of them will support the assessment of marketing, sales or UX. The most common mistake is to start with tags instead of a measurement plan.

The foundation is a measurement plan, i.e. a document that links business goals with events, parameters and conversions. It is where event names, the rules for triggering them, the required parameters, and which user actions should be assigned conversion status are defined. A well-prepared plan organises reports and streamlines further work in GTM, GA4 and dashboards.

The implementation itself is most often carried out through Google Tag Manager, because it provides greater control over tag logic and change testing. You need to configure the basic events correctly, such as page_view, clicks, forms, e-commerce actions or cross-domain transitions, if the site operates on several domains or uses an external checkout. Without cross-domain measurement, user paths are very often distorted and the assessment of traffic sources becomes inaccurate.

The quality of the site’s technical layer is also highly important. If the required data are not available in the code or in the dataLayer, measurement can end up incomplete or rely on ad hoc workarounds that fall apart easily after changes to the site. It is also worth setting up internal traffic exclusion straight away, separating test environments from production, and using consistent event and parameter naming.

Configuration does not end with publishing the GTM container. After implementation, the data need to be verified in debug view, parameter transfer confirmed, event duplication caught, and it should be checked whether conversions fire exactly where they should. Most problems in GA4 result not from the tool itself, but from a lack of validation after changes to the site, the form or the checkout.

Privacy and consent logic is a separate topic. The scope of data in GA4 depends on when tags can fire, how the consent banner works, and whether the consent mode implementation matches the actual behaviour of the site. If this element is configured inconsistently, the reports may look correct, but time comparisons and campaign assessment will be subject to error.

The importance of correctly mapping business goals to events in GA4

Correctly mapping business goals to events in GA4 determines whether the data will genuinely support decisions or merely feed reports with technical signals. GA4 records events, but the tool itself does not recognise which of them matter for sales, leads or customer service. This needs to be established in advance and turned into a concrete measurement logic. If it is not clear what decision is meant to result from a given event, it is usually not worth implementing.

In practice, mapping starts with business questions. The company wants to determine which campaigns deliver valuable leads, at which step of the form users drop off, which landing pages support sales and how the purchase path behaves on different devices. Only such needs give rise to the events, parameters, segments and conversions required in GA4.

Good mapping separates micro-interactions from actions that are truly valuable. Clicking a button, scrolling or opening a form can be a useful diagnostic signal, but it should not always be counted as a conversion. A conversion should be something with a business rationale, for example submitting a form, making a purchase, registering, booking a call or moving to a key stage in the process.

• business goal: online sales → events: view_item, add_to_cart, begin_checkout, purchase, together with product parameters and transaction value,
• business goal: lead generation → events: start_form, form_error, generate_lead or a correctly measured form submission,
• business goal: assessing the quality of traffic from campaigns → events and data: key conversions, UTM tags, traffic source, landing page and subsequent user steps.

Poorly mapped goals can produce seemingly rich reports, yet still lead to inaccurate conclusions. A common issue is setting too many conversions that do not carry real business value, which makes campaigns look good only on paper. Another mistake is the lack of parameters, without which later it is impossible to break down results by form type, product category, offer variant or stage of the journey.

Correct mapping also matters for data comparability over time. When event names and the conditions for triggering them change without control, trend analysis becomes risky, because it is not clear whether user behaviour has changed, or merely the implementation. Consistent naming and clear event documentation are just as important as the implementation itself.

The best results come from a minimal but precise approach. It is better to measure a few events closely linked to the company’s goal than dozens of interactions with no business owner and no plan for use. Such order makes it easier to interpret the data, build reports and later optimise campaigns, content and the user journey.

The most common mistakes during GA4 implementation and how to avoid them

The most common pitfalls in GA4 implementation include the lack of a measurement plan, duplicated events, incorrectly configured conversions, consent issues and skipping testing after deployments. In practice, most difficulties result not from the tool itself, but from an inconsistent implementation approach. GA4 then begins to collect a lot of technical data, but it is difficult to turn it into useful insights. When it is not clear why the data are being collected, reports quickly turn into a set of random metrics.

A very common mistake is marking as conversions actions that do not bring real business value. An example is counting every button click, visit to the contact page or page scroll as a success. This kind of measurement artificially inflates channel performance and makes it harder to assess traffic quality. It is wiser to limit conversions to actions that genuinely move you closer to a sale, a lead or another important goal.

Another issue is duplicate events. This happens when the same event is sent in parallel by the site code, Google Tag Manager and additional plugins. The effect is simple: the number of forms, purchases or clicks looks better than it really is. Each key event is worth verifying in debug view and comparing with the real user behaviour, step by step.

Large distortions are also caused by incorrect handling of consent, internal traffic and test environments. If tags fire differently from what the consent banner indicates, the data will be incomplete or inconsistent. When traffic from employees, developers or testers ends up in reports, campaign analysis and user paths stop being reliable. The same is true when tests carried out on staging or a development version are recorded in the same property as production traffic.

A separate group of errors consists of attribution and traffic source issues. These most often stem from a lack of correct UTM parameters, an unset cross-domain setup or an inconsistent journey between domains and external systems, for example checkout. As a result, a user starts a visit from a campaign, but the conversion gets attributed to direct traffic or to another source. If a company operates across multiple domains, correct cross-domain tracking is not an add-on, but a prerequisite for meaningful analysis.

How can the risk of such errors be reduced. It is worth implementing the minimum viable measurement, maintaining consistent naming of events and parameters, and testing every change on the site, in forms, checkout and GTM. It is also a good habit to compare data from GA4 with CRM, the sales system or the backend, because only then can you see whether the measurement reflects the real process. GA4 should be regularly validated after implementation, not just switched on once and left unchecked.

What business questions are worth asking before implementing GA4

Before implementing GA4, it is worth asking yourself a few questions that will clarify what decisions are meant to come from the data, what we actually count as a conversion, and how measurement is supposed to support sales, marketing or lead generation. This is where the sense of the entire implementation is decided. Without such organisation, it is easy to end up with reports that show traffic, but do not make it easier to choose a budget, improve a form, or assess campaign quality.

The first question is: what decisions do we want to make based on GA4 data? For one company it will be checking the effectiveness of advertising channels, for another analysing form abandonment, and for an online store identifying the stages at which users drop off. Only after answering this question do you know which events are essential and which merely cloud the picture and burden the reports. First define the decisions, and only then the metrics.

The second important question concerns how we understand success. It needs to be stated unambiguously whether a conversion is a purchase, a form submission, a qualified lead, a registration, a call, a brochure download or moving to a specific step in the process. When that definition remains blurred, marketing and sales start looking at different numbers and drawing different conclusions from the same data.

Next, it is worth identifying the stages of the user journey that carry the most weight. This refers to the moments when a user moves from an advert to a landing page, starts a form, reaches the basket, chooses a delivery method or finalises contact. Such a breakdown later makes it possible to see not only how many conversions there were, but also where losses occur and what needs refining.

Questions about the technical side and how activities are organised are also needed. Does the company operate on one domain, several subdomains or many separate websites? Does part of the journey happen outside the main site, for example in an external payment system, booking system or CRM? Is there a dataLayer, who manages GTM and who will be responsible for testing after changes? The answers to these questions often determine the scope of implementation to a greater extent than the choice of reports itself.

Privacy and data quality also cannot be overlooked. It is necessary to know how the consent banner works, when tags fire, which traffic should be excluded and what differences between systems the company is prepared to live with. GA4 will not show exactly the same as CRM, an advertising platform or the backend, because each system may count the user, session or conversion differently. The key is not for the numbers to be identical, but for them to be understandable and useful in decision-making.

Finally, it is worth establishing who owns the data and what the rhythm of work with analysis should be. Who checks the reports, who interprets anomalies, who raises recommendations and who implements changes? Without assigning responsibility, even correctly configured GA4 becomes merely a data archive. The greatest value comes not from collecting data alone, but from regularly translating it into concrete optimisation actions.

The importance of integrating GA4 with other analytics and advertising tools

Integrating GA4 with other tools is needed so that data translates into real advertising, sales and analytical decisions, rather than ending at simply viewing reports. GA4 alone describes user behaviour well, but usually does not show the full picture of lead quality, post-transaction revenue or the impact of campaigns on business performance. The greatest value appears when GA4 functions as part of the whole data system, not as a standalone tool.

The most practical solution is often connecting it with advertising systems, especially Google Ads. This makes it possible to import conversions, create audiences and optimise campaigns more accurately for actions that really matter. This is particularly important when a company does not want to structure its budget around clicks or visits, but around a purchase, a lead or progress to a key stage in the journey.

On the analytics side, linking GA4 with reporting tools and a database is highly significant. Looker Studio makes it easier to build dashboards for marketing and management, while BigQuery allows you to work with more detailed data than that available in standard GA4 reports. A dashboard answers the question of what is happening, but only combining data from different sources helps explain why it is happening.

If a company generates leads, integration with a CRM or another sales system becomes crucial. A form submitted on the site alone does not yet show whether the lead was valuable, whether a salesperson contacted them, and whether the case ended in a sale. Without connecting GA4 with a CRM, it is easy to overvalue channels that generate lots of contacts but few real customers.

In practice, a proven setup looks like this: GA4 records behaviour and conversions on the site, the advertising platform uses these signals to optimise campaigns, the CRM verifies lead quality, and the reporting layer pulls everything together into one coherent picture. This model reduces guesswork and makes it faster to determine whether the problem lies in the traffic source, landing page content, the form or later sales follow-up. This is especially important in lead generation campaigns, where the number of conversions and the quality of conversions are not the same thing.

It is also worth remembering that after integration the numbers still do not have to be identical across all systems. Discrepancies arise from different definitions of the user, session, conversion, attribution windows, traffic filtering and consent settings. Tools are not compared on whether they show the same numbers, but on whether their data is definitionally consistent and decision-useful.

The most common problems stem from poor campaign tagging, a lack of cross-domain tracking, mistakes in consent mode and inconsistent event naming. When traffic sources are tagged incorrectly and conversions are not properly mapped between systems, the integration technically works, but from a business perspective it adds very little. For this reason, before connecting the tools, it is worth agreeing shared definitions: what we consider a lead, what we treat as a sale, at what point we count a conversion and which source we attribute the result to.