Web analytics and conversion tracking implementation
Web analytics today is far more than reporting. It is the foundation the algorithms learn from when they decide who sees your ad, and when.
I implement measurement on any store platform. The platform only changes how the data layer is integrated, the measurement schema stays the same.
Four faultsthat pass for working measurement
Over 90% of the accounts I audit have at least one of them. The problem is rarely that there is no analytics at all — a store has a pixel from a plugin, events from GA4 and a panel where something is being counted.
A GA4 tag firing from several places at once: from GTM, from a plugin and from the template. The same purchase reaches the reports more than once.
An old gtag hard-coded into the template of a module nobody remembers any more.
A pixel from a plugin that never sees the page paid traffic lands on.
Ad tags firing past the consent gate.
„For years we had problems with data analytics in our online store. Different specialists, different plugins, code, methods… Mateusz rebuilt our entire analytics from scratch, put everything in order, and it finally works the way it should!”
Three levels of measurement,from the foundation to the server
Foundation: Data Layer and GTM
Tags have one place to be managed instead of code scattered across store templates. The Data Layer hands them the full picture of an event, and GTM distributes it to GA4 and the ad panels.
Configuration: GA4 and advertising pixels
Events and parameters matched to your business model, and conversions defined deliberately rather than inherited from a plugin.
The server layer
Server-Side Tagging: measurement stops being a browser script. Events are sent to the platforms from your own server, with a full set of user identifiers. You can also enrich them with first-party data.
Working principles,the same in every implementation
We agree the scope of work together, but the standard of implementation is always the same.
No black boxes
I never leave behind a configuration that cannot be inspected and understood. Every tag, trigger and variable has a description and a reason to exist.
Everything through GTM
The work happens in GTM and on the measurement server, not in your store code. When something stops working, you look in one place.
Standardised naming
Tags, events and parameters follow one naming convention. The name alone tells you what an element covers and what it fires.
Order in the container
Paused tags from years ago, dead triggers and duplicate pixels get removed during implementation. Only what genuinely works stays.
Consent verified in practice
Configuring a cookie banner does not by itself guarantee that tags respect the user’s choice. That is why I wire every tag to the banner’s decision. It fires only within the scope the consent allows.
Verification before publication
Every change goes through a working version of the container and test orders. Only what has been verified reaches production traffic.
GA4Meta PixelGoogle Ads conversionsMeta CAPITikTok PixelConsent Mode v2
GA4
Meta Pixel
Google Ads conversions
Meta CAPI
TikTok Pixel
Consent Mode v2
- GA4
- Meta Pixel
- Google Ads conversions
- Meta CAPI
- TikTok Pixel
- Consent Mode v2
The list is not closed. I implement and clean up the tags your store actually uses.
// CASE STUDY
E-commerce store,EMQ 9.3/10.
WooCommerce. The same GA4 tag installed in three places at once: in GTM, in a plugin and in code from a developer. One purchase reached the reports several times. The ad budget was based on numbers with no cover in sales.
CHALLENGE
A soup of tags
- A hidden gtag in the template of the "multi-pack" module, findable only by reading the code
- Meta Pixel from a black box plugin: it never saw events on the page paid traffic landed on
- TikTok Pixel loaded outside GTM ignored consent
- Cookies written in the browser expired in Safari after seven days
- The same purchase counted several times: ad algorithms learned on inflated conversions
SOLUTION
One source of truth + SST
- The stack cleaned down to a single source: GTM
- A custom Data Layer script for the "multi-pack" module
- Server-Side Tagging in a same-origin architecture
- GA4, Meta CAPI, Google Ads and TikTok through the server, all behind one consent gate
- Contact data normalised for each ad system's requirements
- Cookies set from the server, with no seven-day cap
RESULT
EMQ 9.3/10 and clean data
- 41.2% of transactions recovered
- One purchase, one event in GA4
- Event Match Quality 9.3/10 for the Purchase event in Meta
- A full set of user parameters on every purchase
- All tags fire in line with consent
- First-party cookies from the server, with no seven-day Safari cap
How a measurementimplementation runs
We set the scope after the audit. It depends on how many ad platforms you actually use, whether the server layer comes into play, whether the store runs non-standard modules and configurations, and what state your measurement is in today.
Step 01: Audit
GTM, GA4, pixels, consent and duplicate transactions. I establish the starting point and the list of faults before I change anything.
Step 02: Plan
A data layer schema, an event map and the order of work for your store.
Step 03: Implementation
Tags, variables and rules are built in a working version of the GTM container. Nothing reaches the live site without passing verification.
Step 04: Verification
GA4 DebugView, the server preview and test orders. I check that every event arrives with the right parameters before the working version is published.
Step 05: Documentation
A detailed description of the implementation, documentation of the configuration and an operating manual for the measurement setup. Any specialist who comes next will pick it up without guessing.
Step 06: Ongoing care
Rebuilding the store, new features or new analytical needs all call for the event schema to be extended. Within the agreed scope of care, I grow the measurement setup along with the store.
Ready for datayou can trust?
We start with a free audit. You know what is broken before you implement anything.
