GA4 implementation · GTM · e‑commerce

A GA4 implementation that can be tested and maintained.

I design measurement from business questions and event specifications through GA4 and GTM configuration, testing and documentation. The scope is not a bundle of technologies; it follows decisions, data sources and the capabilities of your team.

BigQuery, server-side tagging and dashboards are not mandatory additions. They are included when they solve a defined problem and have an owner after launch.

Describe the current implementation Check GA4 first
Specification before tagsevery event has a purpose and acceptance criteria
QA and reconciliationscenarios are tested and critical results are compared
Documentation and ownershipthe project does not end when a container is published

Common starting point

The code runs, but the data still does not answer the questions.

The issue is not always GA4 configuration. Definitions, systems of record or change ownership are often missing.

Conversions differ from CRM or store data

The cause may be definitions, consent, duplicates, cancellations or event timing.

The e‑commerce funnel is incomplete

Events, product parameters or a stable transaction_id needed for deduplication are missing.

The dataLayer changes without a specification

Tags depend on page structure, button labels and selectors that break after a release.

The CMP and tags operate separately

Consent states, firing order and tag behaviour have not been tested together.

Events have no owners

Marketing, development and analytics teams use different names, definitions and acceptance criteria.

Historical configuration keeps accumulating

Old tags, unused conversions and rules remain because no one can change them safely.

Primary outcome

Measurement with acceptance criteria, not a list of published tags.

The implementation core connects each event definition with its test and owner. Technical modules are selected separately.

Implementation core

01

Measurement map

KPIs, events, parameters, conversions and systems of record connected to decisions.

02

dataLayer specification

A data contract for developers with triggers, field types and payload examples.

03

GA4 and GTM configuration

Property, streams, tags, variables, rules, custom dimensions and critical conversions.

04

Testing and reconciliation

QA scenarios, duplicate and missing-parameter controls, and comparison with the reference system.

05

Documentation and handover

Configuration, test results, known limitations, owners and the process for future changes.

Modules selected when needed

Not every project needs every module at launch.

E-commerce

Funnel, item data, promotions, transaction_id and purchase reconciliation.

CMP and Consent Mode

Consent-state integration and tag-behaviour testing for the agreed model.

BigQuery

GA4 export, retention, cost and basic freshness and completeness controls.

Server-side tagging

First-party routing and server integrations when architecture and scale justify them.

Advertising platforms

Google Ads, Meta CAPI and Enhanced Conversions within the agreed scope.

Starter report

A control view for quality and key KPIs, not automatically a full BI project.

If a sound measurement plan or dataLayer already exists, I reuse it. I do not recreate working assets simply to expand scope.

Explore the measurement plan

Process

From qualification to stable maintenance.

  1. 01

    Current-state qualification

    We review the service, tags, sources, CMP, integrations and people needed.

    Outcome: scope and dependencies
  2. 02

    Definitions and specification

    We agree events, parameters, conversions, dataLayer and acceptance criteria.

    Outcome: measurement contract
  3. 03

    Implementation

    I configure GA4 and GTM while the development team delivers agreed application and dataLayer changes.

    Outcome: test environment
  4. 04

    QA and reconciliation

    We test scenarios, parameters, consent and duplicates, then compare critical results with the reference source.

    Outcome: acceptance record
  5. 05

    Publication and handover

    We publish the configuration, hand over documentation and agree monitoring and change ownership.

    Outcome: maintainable implementation

Tangible outcome

What one event specification looks like.

This abbreviated example shows the structure. The final document also covers data types, environments, consent and development dependencies.

Critical eventpurchasee‑commerce
Business question
How many confirmed transactions and how much revenue are attributed to channels?
Trigger
A successfully created order after its identifier is assigned.
Required data
transaction_id, value, currency, items and agreed product fields.
Source
Store backend and dataLayer, reconciled with the order system or ERP.
Acceptance test
One event per transaction, complete parameters, correct types and no duplicate after refresh.
Responsibility
Development exposes data, analytics configures and tests, business accepts the definition.

Acceptance

How we know the implementation is ready.

Exact tolerances are agreed before delivery. GA4 need not match a transaction system one to one, but the differences must be understood.

Critical scenarios pass QAevents fire at the right moment with required parameters
Duplicates and gaps are controlledtransaction_id, identifiers and resend conditions have tests
Discrepancies have explanationsreference-source comparison covers consent, cancellations and delays
Configuration has ownersdocumentation identifies owners for dataLayer, GTM, definitions and reports

Choosing the first step

Implementation is not always the right place to start.

The current state is unknown

GA4 audit

When data exists but what works and what needs rebuilding is unclear.

Explore the audit
Definitions and dataLayer are missing

Measurement plan

When KPIs, events, parameters and developer requirements need agreement first.

Explore the plan
The scope is known

GA4 implementation

When specification can move into configuration, testing and publication.

Review the scope
Measurement is already live

Data quality monitoring

When critical data needs recurring controls, alerts and a response process.

Explore monitoring

Responsibility

What I own — and what I need from your team.

My responsibility

  • event, parameter and acceptance-criteria design,
  • GA4 and GTM configuration within the agreed scope,
  • QA scenarios, tests and a list of identified issues,
  • configuration documentation and team handover,
  • analytics coordination for dataLayer and integration changes.

Client responsibility

  • access and decision-makers across marketing, IT and business,
  • KPI-definition approval and systems of record,
  • application and dataLayer development when required,
  • legal decisions on consent, processing basis and policies,
  • test orders, leads or other business scenarios.

Honest limitations

A good implementation does not remove source-data limitations.

I document limitations instead of hiding them behind a claim of “complete data”.

  • GA4 is not an accounting system.Revenue and transactions may differ from ERP because of definitions, cancellations, consent and delays.
  • Consent and blocking create gaps.Not every session or conversion is observable, even with correct configuration.
  • Server-side does not recover everything.It improves flow control but does not replace consent or a sound dataLayer.
  • Configuration is not legal advice.I implement the agreed consent model; the client or legal adviser approves the legal basis.
  • Historical gaps cannot be rebuilt.A new implementation improves collection from publication onwards.
  • Changes require maintenance.New features, CMP, checkout and campaigns may require specification updates and retesting.
Krzysztof Surowiecki

One accountable consultant

I connect specification, configuration and data acceptance.

I lead the project personally across business, marketing and development, so event requirements do not remain a detached document with no path into GTM and testing.

20+years of experience
150+analytics and data projects
50+clients

Figures refer to the broader analytics and data practice, not only new GA4 implementations.

Before we talk

Frequently asked questions.

How long does a GA4 implementation take?

It depends on services, events, integrations and development capacity. After qualification, I define stages, dependencies and a realistic timeline.

Is server-side tagging mandatory?

No. It makes sense when goals, volume, integrations, first-party requirements and maintenance justify it. A sound client-side scope can be appropriate in a simpler environment.

Do you change the website code and dataLayer?

I prepare requirements and payload examples and lead QA. Application changes are usually delivered by the client's development team. Delivery responsibility is agreed before the project starts.

Does Consent Mode implementation guarantee GDPR compliance?

No technical configuration alone can guarantee legal compliance. I implement agreed tag and consent behaviour; the client or legal adviser approves the legal basis and policies.

What happens after publication?

I hand over documentation and test results. We can also agree an observation period, quality monitoring or ongoing analytics support.

How is the project priced?

Pricing depends on events, services, integrations, dataLayer, e‑commerce, consent and delivery responsibility. I propose a core scope and optional modules after qualification.

First step

Describe the service, current measurement and three most important decisions.

I will follow up with questions about sources, dataLayer, CMP, integrations and the people needed for acceptance.

Discuss the implementation Explore ongoing support

Prepare for the project

Check the current state and requirements.

GA4 configuration auditorself-assess measurement and remediation prioritiesRun the auditor GA4 taxonomy plannerevents, parameters and specification exportOpen the planner dataLayer generatorexample e‑commerce payloadsGenerate dataLayer