GA4 Rebuilt to Reconcile Against Your Billing Ledger

We do not hand over a GA4 property until its revenue reconciles with the billing system inside 2 percent across a rolling 30 days. That number is the engagement. Everything else, the event names, the custom dimensions, the migration plan, exists to make that comparison possible and then to make it hold. Most GA4 rebuilds fail on the same thing. The property was designed against what a marketer wanted to see in a report rather than against what finance already knows happened. So purchase fires on a thank-you page that Pix buyers never reach, boleto orders are counted at checkout and never reversed when they expire three days later, and by the time anyone notices, six months of data is usable for nothing but a trend line. How we work: We start in your source of truth, not in GA4. ERP, order table, Stripe or Mercado Pago or Pagar.me, whichever holds the row finance closes the month against. We pull 90 days of it and define what a conversion is at the row level, including which states are reversible. In Brazilian ecommerce this is usually where the engagement earns its fee, because a purchase event fired at checkout submission is a number nobody in the room can defend. Then the event schema, which is a document before it is a tag. Every event, every parameter, its type, its allowed values, which ones become custom dimensions and why, and what the value is when it is missing. Your engineers implement against that document. We review the implementation in staging with a request-by-request diff before anything reaches production. BigQuery export is on from day one and the reconciliation runs there as a scheduled query. You get the query. It compares GA4 revenue against your order table by day, by channel group and by payment method, and flags any day that drifts past the threshold. When the number breaks in month four, you find out from a table rather than from a quarterly review. Migration specifically: If you are moving off Universal Analytics history or a badly built GA4 property, we do not carry the old event names forward. A 2013 schema is how a property becomes unreadable. We freeze the old data as a historical table in BigQuery, define the new schema on its merits, and document the join so a year-on-year comparison stays possible and stays honest about where the definitions changed. Not included: Attribution modelling. We configure GA4's models and explain what they can and cannot support, but we do not build media mix or incrementality work here, and we will say plainly when a channel report is being asked a question it structurally cannot answer. Dashboards. We deliver BigQuery and the reconciliation query. A Looker Studio layer or a warehouse model on top is separate work, often better done by whoever owns your BI. Ongoing tag maintenance. The container build is its own engagement. Who this is not for: Anyone who needs the numbers to go up. A correct rebuild almost always reports fewer conversions than the property it replaces, because the old one was counting some of them twice. If that reduction is politically impossible inside your organisation, this work will fail and we would rather decline now than deliver it into an argument. Also not for pre-revenue products with no billing system to reconcile against. Without a ledger there is nothing for us to be right about, and a cheaper implementation is the correct choice.