GA4 and Google Tag Manager implementation
GA4 and Google Tag Manager implementation means designing an event architecture before deploying tags: naming, parameters, conversion definitions, and the cross-domain and booking-platform handoffs where data usually breaks. Kodelytics implements new properties and repairs existing ones that were migrated from Universal Analytics without a design.
Most GA4 properties in use today were not implemented — they were migrated. The default tag went in, enhanced measurement was left on, and events accumulated with inconsistent names and no parameter discipline. The result reports traffic accurately and conversions poorly, which is the opposite of the useful arrangement.
Repair is therefore the more common engagement than greenfield implementation. The work is rarely exotic: an inventory of what currently fires, a designed architecture to replace it, and a controlled cutover that keeps historical continuity where it can be kept and documents where it can't.
Event architecture is the designed set of events, parameters, and conversion definitions a property collects, decided before any tag is deployed. Without one, a property accumulates events per implementer, which is why the same user action often exists under three names.
What's actually wrong
These are the symptoms buyers of this service recognize before they can name the problem.
- Event names in GA4 include three variants of the same action, from three different implementations.
- Key events are counted but carry no parameters, so they can't be segmented by location, service, or value.
- A user who moves from the site to a third-party booking platform appears as a new session from a referral.
- Form submissions are tracked from a thank-you page URL that some forms no longer redirect to.
- Call conversions exist in the call tracking platform and not in GA4, or the reverse.
- GTM contains tags nobody can account for, several of them paused since a previous agency.
What the engagement includes
- A measurement plan: the business questions first, then the events, parameters, and conversion definitions that answer them.
- An event naming and parameter standard, documented so future work stays consistent.
- GTM container build or cleanup — triggers, variables, data layer specification, and removal of orphaned tags.
- Conversion tracking for forms, calls, chat, and bookings, with the platform-side handoff verified rather than assumed.
- Cross-domain measurement, including booking platforms, payment pages, and subdomains.
- Google Ads and Microsoft Advertising conversion imports configured against verified GA4 key events.
- Consent handling appropriate to your jurisdictions, including Consent Mode where applicable.
- Server-side tagging assessment — whether it's warranted for your case, and what it would cost to run.
The measurement plan comes first
A measurement plan starts from decisions, not events: which questions the business needs answered monthly, and which of those require data the site can produce. Only then does it name the events, the parameters each event must carry, and which of them are conversions.
This is where multi-location businesses are made or broken. If location isn't a required parameter on every conversion event, per-location reporting is impossible later without reimplementation — and it will be needed, because per-location budget decisions are the whole point of a multi-location program.
Verification, not deployment, is the deliverable
Tags are easy to deploy and easy to deploy wrong. Every conversion path in scope is walked end to end in a real session — user action, data layer, trigger, tag fire, platform receipt — and the result recorded in a QA document per path.
Verification then repeats after a week of live traffic, because the failures that matter are conditional: the mobile variant of the form, the returning user, the booking flow that only redirects for one service type.
Client-side versus server-side tagging
| Client-side GTM | Server-side GTM | |
|---|---|---|
| Setup cost | Low | Higher — container infrastructure |
| Running cost | None | Ongoing hosting |
| Data loss to blockers | Higher | Lower |
| Event enrichment | Limited | Full, before dispatch |
| Right for | Most mid-market advertisers | Material blocking loss, strict first-party requirements |
How it's scoped and priced
Implementation is a fixed-fee project, scoped on property count, the number of conversion paths, and how many third-party platforms sit in the conversion path. A single-site property with three conversion actions is a short engagement; a multi-location property with a booking platform and call tracking is not.
Repair work is scoped after a short assessment, because the difference between a broken container and a container that needs rebuilding is material to the price. Ongoing measurement maintenance can be folded into a retainer.
Kodelytics does not publish rates. Every engagement is quoted after a discovery call, because the same service name covers materially different amounts of work.Ask for a quote.
What you get at the end
- A measurement plan document mapping business questions to events.
- A data layer specification your developers can implement against.
- A documented GTM container with naming conventions.
- A tracking QA checklist and test results per conversion path.
- A conversion definition register — what counts as a conversion, and where it's counted.
Questions
How long does a GA4 implementation take?
Two to four weeks for a typical site, including the measurement plan, the build, and a verification period across real traffic. Multi-domain or booking-platform integrations extend that, usually because of third-party access rather than the work itself.
Why don't my GA4 conversions match Google Ads?
The platforms count differently by design: Google Ads attributes a conversion to the click's date and applies its own attribution model, GA4 attributes to the session and applies another. A gap is expected. A large or unstable gap usually means duplicate event firing, missing cross-domain linkage, or an unverified conversion action — that's a diagnosable problem, and the attribution audit is the engagement for it.
Do we need server-side tagging?
Most mid-market advertisers do not. It's worth the infrastructure cost when you have material data quality loss from client-side blocking, strict first-party data requirements, or a need to enrich events before they reach a platform. Kodelytics will say no where the answer is no.
Can you fix an implementation someone else built?
Yes, and it's a common engagement. The first step is an inventory of what currently fires, because a container's documentation and its behaviour are rarely the same thing.
Who owns the accounts and containers afterwards?
You do, always. Kodelytics works in your Google accounts under named access, and documents the build so another provider can pick it up.