missing conversions

GA4 implementation, from the measurement plan to the BigQuery export.

A written measurement plan, property and stream configuration, event and key event design, the ecommerce item schema, and validation against your own orders. For teams that know what they need to measure and want a property built to hold it.

What this covers

The measurement plan, agreed before the property is touched. A named list of events, the parameters each one carries, the type of every value, which events are flagged as key events, and the counting method set on each. Two of those decisions are taken on day one rather than left until later. Parameters are registered as custom dimensions at the start, since registering one does not populate it over data already collected. Retention is set to the longest option the property allows at the same time, since it governs how far back an exploration or the reporting API can look, and events already aged out are deleted rather than restored by a later change. The rest is a conversation about what the business counts, and it is the conversation the build is quoted against.

Property and stream configuration, decided rather than defaulted. Streams named so a report tells you which surface produced it. Enhanced measurement settled switch by switch against the events on the plan, so one action does not arrive twice under two names. Cross-domain measurement configured across the domains that carry your own tag, so the session survives the hop and the linker parameter is read on the other side. A domain you pass through but cannot tag is a different fix, and it is handled by the unwanted referrals list below. Internal and developer traffic definitions created and then activated, rather than left sitting in testing state.

Attribution and channel settings, fixed and written down. The attribution model and the lookback windows, a campaign tagging convention your team can follow, custom channel groups where your traffic does not fit the defaults, and the unwanted referrals list covering hosted payment pages, booking domains and anything else a buyer passes through on the way to converting. These are settled at the start of the build and recorded with the reasoning, because they are read by people who act on the reports.

The ecommerce and item schema, built out from the catalog. Where you sell online, the build starts at the item and works forward: one item_id carried through view_item, add_to_cart, begin_checkout and purchase, transaction_id taken from the order, value and quantity sent as numbers with a currency code beside them, and refunds sent against the same transaction so the revenue line moves with finance. The plan names which values your developers have to send, so that work can be scoped rather than discovered.

The BigQuery export, linked at the start where it is in scope. Linking is a day-one decision, because the export carries data only from the day it is turned on. In scope, the work covers the link, the dataset, and a set of queries that reproduce your headline numbers from raw event rows, so the warehouse figure and the reported figure can be put side by side. A standard property’s daily export has a volume ceiling, and a property that passes it loses that day’s table, so on high volume the streaming export or a 360 property is part of the same decision rather than a later surprise.

How it runs

Scoped, then quoted fixed-price. The first question is what the business counts and which decision the number feeds. The build is quoted as a fixed-price project against that scope. If you have run the audit, the $900 is credited in full.

Configuration and collection ship together. A key event with no reliable event behind it is a report that looks correct and is not, so property settings and the tagging that feeds them are built and released as one piece.

A rebuild runs in parallel before it replaces anything. Most properties are corrected in place. Where the event schema cannot be reconciled with the reports it has to feed, the new property collects alongside the existing one for an overlap period, so you keep a baseline and the old property stays readable. Which one becomes the property of record is a decision you take at the end of the overlap, not at the start of the work.

Everything is built in your own account. Your property, your admin, your access. Where container work is needed to feed it, that ships in a separate workspace as one named version, only once you approve it.

Validated against something outside GA4. Orders, payment settlements or CRM records for the same window, the same timezone and the same definition of a conversion. Sign-off is that reconciliation, not a green debug panel.

One person from scoping to handover. The person who writes the measurement plan is the person who configures the property and the person who reconciles it.

What you get

The measurement plan as a standing document. Events, parameters and types, key events with the counting method on each, and the custom dimension registry.

The configured property, with every setting recorded and the reasoning attached.

Validation evidence. The reconciliation against your own records over a real window, with the residual difference explained rather than rounded off.

Reports and explorations built around your questions, so the people who read them each week find their number without rebuilding it.

The export, where it is in scope, linked and running, with the queries that reproduce your headline numbers from raw event rows.

Handover documentation. What to check when a number moves, and a marked list of which settings restate what your existing data shows and which only take effect from the day they change.

Ongoing management, if you want it. A monthly arrangement, scoped on the tracking maintenance page. Many clients take the handover and run the property themselves.

When this is the wrong fit

You want to know what is wrong before committing to change it. That is a diagnosis, and it costs less than a build.

You want your history repaired. Reporting-time settings change what your existing data shows, but collection cannot be backfilled. A build improves the numbers from the day it ships.

You need per-user analysis over long windows. GA4 has cohort, funnel and path explorations, and they answer more than they get credit for. What they cannot do is reach past the property’s retention window, return an unsampled result at high volume, or hold one identity across devices without User-ID. When those are the binding constraints, the honest answer is the export or a product analytics tool.

The business has not decided what counts. If nobody agrees on what a lead is, the event design encodes the disagreement and every report inherits it.

The Missing Conversions Audit is the usual way in. It establishes what the property collects today, what it quietly discards, and what a build would have to cover. The $900 is credited in full against the work that follows.

Questions

If we rebuild the property, what happens to our history?

The old property keeps collecting until you switch it off, and it stays readable afterwards. There is no import path between GA4 properties, so history does not travel with you. That is why a rebuild runs the two in parallel for an overlap period: you get a window where both are collecting the same traffic, which is the only honest way to check the new numbers against the old ones before you rely on them. Where the BigQuery export is running on both, the two datasets can be queried together and the seam matters less.

Is the BigQuery export worth it for a property our size?

The case is not volume, it is the questions the interface cannot answer. Sampled explorations, high-cardinality values collapsed into an other row, rows withheld to protect identity, and joins to your own order, CRM or cost data limited to the shapes GA4's data import will accept. If none of that has bitten you yet, the export is still worth linking early, because it carries data only from the day it is turned on and the months before it cannot be backfilled. Storage and query costs are billed to your own cloud account rather than through this project, and they scale with what you store and query.

Who owns the property and the access during the work?

You do. Everything is built in your own Google account, on your property, with access granted at the level the work needs and removed at handover if you want it removed. Nothing is built somewhere you cannot see it, and the measurement plan, the configuration record and the validation evidence are yours to hand to whoever comes next.

Start hereGA4 auditMost of this work is scoped from what the audit finds, and the $900 is credited against it.

Related services

Next step

Find out what this is costing you.

The Missing Conversions Audit is a fixed-price teardown of your GA4, Google Tag Manager, ad pixels and consent setup. Every gap logged, the top 10 fixed and validated. $900 flat. 5 business days.

A 15 minute call

  • We look at your setup from the outside and say what we can already see.
  • You get a straight answer on whether the audit is worth it for your account.
  • If it fits, we book the slot and send the access checklist.
Open the booking calendar

Opens the calendar here. Nothing loads from Calendly until you do.

Prefer email? hello@missingconversions.com