Web analytics should answer business questions
A busy dashboard is not the same as useful analytics. The goal is to understand what people do, where they struggle and which actions contribute to revenue. Reliable measurement starts with a short list of decisions the business needs to make.
For a lead generation website, that might mean knowing which campaigns produce qualified enquiries. For ecommerce, it could mean understanding product discovery, checkout completion and repeat purchases. The events and reports should follow those questions, not the other way around.
Start with a measurement plan
Before adding tags, write down the customer journey and the actions that matter. A practical measurement plan includes:
Business questions the data must answer
Primary conversions such as purchases, booked calls or submitted applications
Supporting actions such as pricing-page views, product comparisons and form starts
Required properties such as campaign, plan, product, order value and customer type
Where each event originates and which system owns the source data
Who uses each report and how often it informs a decision
Keep the plan small enough to maintain. Tracking every click usually creates noise. Track actions because they explain progress, friction or commercial value.
Use a stable event and data layer design
Your website, tag manager and analytics tools should share a consistent vocabulary. Use names such as form_start, form_submit and purchase rather than letting each tool invent its own version of the same action.
For React and other single-page applications, important events should be emitted by application code when the action actually succeeds. A click on a submit button is not the same as a successful form submission. Route changes, virtual page views and asynchronous checkout steps also need explicit handling.
A well-designed data layer separates product behavior from vendor tags. The application sends a meaningful event once, and Google Analytics, Google Ads, Meta or another destination can consume it without filling the product code with vendor-specific logic.
Choose client-side or server-side tracking deliberately
Client-side tracking
Client-side tracking runs in the visitor's browser. It is straightforward to implement and is often enough for basic page views, content engagement and simple conversions. It is also affected by browser restrictions, consent choices, ad blockers, network failures and JavaScript errors.
Server-side tracking
Server-side tracking routes selected events through infrastructure you control before forwarding them to analytics or advertising platforms. It can improve control over the payload, reduce browser work and make validation easier. It does not remove the need for consent, clear data governance or careful event design.
Do not introduce server-side tracking just because it sounds more advanced. Use it when the commercial value, data quality requirements and maintenance budget justify the additional system.
Configure GA4 around meaningful events
GA4 reports are only as trustworthy as the events they receive. Define key events for actions that matter to the business, pass stable parameters and make sure transaction identifiers prevent duplicate purchases.
Useful checks include:
Only one page_view is recorded for each real page view
Conversions fire after success, not on an attempted click
Revenue, currency and transaction IDs are present and correctly formatted
Internal traffic and test environments are handled intentionally
Referral exclusions and cross-domain measurement match the real customer journey
Campaign parameters survive redirects and checkout handoffs
Personally identifiable information is not sent where it is not permitted
Treat consent and privacy as part of the implementation
Consent is not a banner added after tracking is finished. It changes when tags may load, which storage they can use and what data can be sent. Map every tag to a purpose and consent category, then test both accepted and rejected states.
Privacy requirements vary by market and implementation. Product, legal and engineering teams should agree on what is collected, why it is needed, how long it is retained and who can access it.
Validate data before building reports
Use browser developer tools, tag-manager preview modes and platform debugging tools to confirm that each event fires once with the expected values. Test real journeys across browsers, devices, consent states and campaign entry points.
Then compare systems. Analytics, advertising platforms, a CRM and an order database will not always match exactly because they use different attribution rules and processing windows. Large or unexplained gaps are still a warning sign. Document the expected differences so teams know which source to use for each decision.
Build reports people will actually use
A useful report starts with an audience and a recurring decision. A growth team may need acquisition quality by campaign. A product team may need funnel completion by device. Leadership may need qualified pipeline and revenue rather than page views.
Give every metric a clear definition
Show trends and meaningful segments rather than isolated totals
Pair conversion data with acquisition cost or commercial value
Annotate launches, campaign changes and known tracking incidents
Assign an owner who reviews data quality regularly
Common signs your analytics need engineering work
Teams cannot explain why GA4, Google Ads, Meta and the CRM disagree
Conversions fire twice or disappear during client-side navigation
Every website release breaks tags
Marketing scripts noticeably slow down the website
Consent behavior differs across pages or markets
The tracking setup depends on undocumented custom JavaScript
No one knows which events are still used
These are system problems, not reporting problems. A tracking audit should identify the cause, establish a shared event model and leave the team with tests and documentation.
Turn data into dependable decisions
Start with the questions, implement the smallest reliable event set and verify it continuously. Once the foundations are trustworthy, attribution, experimentation and optimization become far more useful.
If your team needs help untangling analytics, GTM, advertising tags or website performance, our Web Performance & Growth Engineering service combines measurement work with the engineering needed to fix the underlying implementation.