Google Analytics 4 Partners

The document that has to exist before a single tag does

A measurement plan is a short document, usually eight to twenty pages, listing the questions the business needs answered, the decisions those answers will change, and the events and parameters required to answer them. It is written before anyone opens a tag manager. The test of a good plan is subtractive: it should say which events you decided not to collect, and why. Teams that skip this stage fire forty events, twelve of which nobody has ever queried, while the question the finance director asks every month still needs a manual export to answer.

The plan also has to name owners. Every event needs someone who can say what it means when it fires, and every parameter needs someone who will notice when its values drift. This matters more in GA4 than under the old session-and-pageview model, because the event schema is not fixed by the tool. You invent it. That freedom is useful, and it is also how two teams in one company end up with purchase, order_complete and transaction all live at once, each counting something slightly different. Version the plan alongside your application code, not in a slide deck.

Event and parameter schema, written as a contract

• Event naming is a one-way door — renaming an event later splits your historical reporting in two, so the convention, typically lowercase and underscore-separated, belongs in writing before the first tag ships.
• Parameters carry the analysis, events carry the count — a good schema keeps the event list short and pushes detail into parameters, so you are not inventing an event every time marketing adds a form.
• Registration is a limited resource — GA4 caps how many custom dimensions you can register, and parameters collected but never registered stay invisible in the interface even though they sit in the export.
• Types must be declared up front — decide whether a parameter is a string or a number before it ships, because a value logged as text cannot be summed later without cleaning every historical row.
• High-cardinality values need a rule — free-text search terms, URLs carrying query strings and anything user-supplied will blow out reporting cardinality, and should be truncated, bucketed or sent only to the export.

Writing a dataLayer specification developers can maintain

The dataLayer is a JavaScript object your website populates with structured information about the page and what the visitor just did; the tag manager reads from it. Everything else in your analytics depends on it being accurate. A usable specification gives developers, for each event, the exact key names, data types, allowed values, an example payload, and the point in the page lifecycle where the push must happen. Written well it reads like an API contract. Written badly you discover during acceptance testing that the checkout pushes its payload after the page has navigated away, so nothing is recorded.

Ask how the specification survives your next front-end release. The honest answer involves automated checks: a test in the build pipeline that fails when a required push is missing or malformed, plus an alert when a key event drops below its expected hourly volume. Without one of those, dataLayer decay is a certainty rather than a risk, because the people shipping front-end changes are not the people reading the reports. A specification handed over with no tests attached simply moves the maintenance bill onto you.

Server-side tagging: ask for a position, not a preference

Server-side tagging moves the tag container off the browser onto infrastructure you run, usually containers on a cloud provider. Requests from the page go to your own subdomain, and that server decides what to forward to Google, to advertising platforms, and to anything else. The benefits are real: fewer third-party scripts slowing the page, first-party context for cookies, and one place to strip fields you do not want leaving your estate. The costs are equally real and belong in the proposal as numbers. You take on compute charges that scale with traffic, a container needing patches, an on-call path, and debugging that no longer appears in browser developer tools.

The right answer depends on traffic volume and on what you are trying to fix. At modest traffic with no specific cookie-duration or page-speed problem, a well-built client-side setup is the cheaper correct answer, and a partner should say so. At high volume, where Safari cookie lifetimes visibly truncate your reporting windows, or where events must be enriched with data the browser should never hold, the case is strong. Ask for a written recommendation with a monthly running cost at your actual event volume, a named owner for the infrastructure, and what breaks when the server goes down.

What Consent Mode actually changes in your reports

Consent Mode lets your tags load but adjust their behavior according to the consent signals your banner sets. When a visitor declines analytics storage, the tag sends a cookieless ping rather than nothing. Google then uses those pings, with observed behavior from consenting visitors, to estimate the activity it could not measure directly. The result appears in your reports as ordinary numbers, unlabelled in most views. This is the thing buyers most need to understand: once Consent Mode is live, some portion of your reported users, sessions and conversions are statistical estimates rather than counted events.

That is not an argument against it, and in most jurisdictions you have little choice. It is an argument for knowing the size of the modeled portion and being disciplined about which decisions you let it drive. modeling needs threshold volumes to activate, so it can run for your largest market and not your smallest, which makes country comparisons quietly unreliable. Ask for your consent acceptance rate, which properties currently qualify for modeling, and which reports to treat as directional. The BigQuery export contains observed events alone.

Questions to settle before modeling goes live

• What your banner actually sets — the consent platform must pass the specific states the tags read, and an implementation that blocks scripts outright instead of signalling consent produces no modeling at all.
• Which regions are in scope — a single global configuration is simpler to run but usually collects less than a region-aware one, and that trade-off deserves to be a documented decision.
• How advertising consent is handled separately — analytics storage and advertising storage are distinct signals, and conflating them either breaks remarketing or over-collects.
• What your baseline was — capture key conversion volumes before the banner changes, because otherwise you cannot separate a consent effect from an ordinary tracking bug.
• How you will explain the drop — recorded sessions will fall after a consent rollout, and the explanation needs circulating in advance or somebody senior reads it as a traffic collapse.

Enable the export on day one, then decide who models it

The BigQuery export writes GA4 events into a table you own, one row per event, with parameters nested inside. It is not retroactive. Whatever you do not export today is gone from the export permanently, which makes this the cheapest valuable thing you can do in the first week, long before you have any use for it. Turn on the daily export, and the streaming export too if you expect to need same-day data. The cost is small and the option value is large. Everyone who has regretted this decision regretted not making it sooner.

Raw exported events are not analyst-ready. Each row carries a repeated key-value structure that must be unnested before anyone can write a simple query, sessions have to be reconstructed, and the relationship between visitors, sessions and orders has to be defined in code rather than assumed. Somebody must build and own that modeling layer, typically scheduled queries producing flat tables an analyst can join to finance and CRM data. Establish who that is at the start, and if your partner builds the models, ask for them in version control and in plain SQL rather than inside a proprietary tool.

Reconciling ecommerce revenue against the order system

No GA4 ecommerce build should be signed off until its revenue has been compared, day by day for at least a fortnight, against the order management system. Perfect agreement is neither the target nor achievable. What you need is a known, explained and stable gap. The usual causes are consent declines, ad blockers, purchases completed in an app or by phone, tax and shipping included on one side and not the other, currency converted at different rates, and refunds the order system reflects and the tag never hears about. Each is a reconciliation line with either a fix or a deliberate decision to live with it.

Set the tolerance before you start. A retail site with a clean single-currency checkout should sit within a few percent; a business with heavy phone ordering and partial cancellations will legitimately sit further out. Write the agreed figure down with the date it was measured, because in six months somebody will ask why analytics disagrees with finance. Build the comparison as a scheduled query against the export rather than a one-off spreadsheet, so the check runs weekly and drift is caught when it starts instead of at year end.

Programs rarely stop at one product. Buyers hiring for Google Analytics 4 often pair it with BigQuery partners , Campaign Manager 360 partners or Display & Video 360 partners , or review the whole Google Marketing Platform landscape before committing.