Ecommerce tracking that reconciles against your store admin.

What this covers

The measurement layer on a store, built to fit the platform underneath it and wired so GA4 and your ad platforms see the same orders your admin does.

The purchase funnel as a set, not one event. view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info and purchase, plus list and cart views where they earn their place. Which of those get built is a scoping decision, taken against the reports you will read and the audiences you intend to build, and written into the spec before the first tag exists. What is left out is written down as left out, so an event missing a year from now reads as a decision rather than a fault.

The items array, and the identifier that stays canonical. Every funnel event carries the same items array: identifier, name, variant, price, quantity. The build decision is which identifier is canonical and at what level, product or variant, and it is settled against the feed your catalog already publishes rather than after the events are written. That id is then emitted at every step and checked against the feed rather than assumed to match. This is the expensive part of the build and the part that makes product reporting, catalog matching and an item-level refund possible at all.

transaction_id and refunds. Purchase carries the store order ID, the one a human can find in the admin, not a checkout token. That one field does three jobs: it is the key you reconcile on, Google Ads uses it as the order ID to discard a repeat send, and Meta discards one when the same value rides along as the event ID. What it does not do is make GA4 forgive a duplicate on your behalf, so the build sends the event once rather than sending it twice and hoping. Refunds go back with the same ID, full and partial, and the reverse path is built and proved inside the same engagement rather than left for your first refund to discover.

What each platform lets the build touch. Shopify puts checkout measurement in the customer events layer, so the storefront identifier has to be passed in deliberately or the sandboxed tag mints its own. WooCommerce is the opposite shape: the order object is available server side, but the block-based cart and checkout changed which hooks exist, and the order received page is refreshable. The scoping call establishes which shape your store is, because that decides the whole build. BigCommerce, Magento and other platforms are quoted on the same basis, once that call establishes where the order object lives and what the checkout allows.

Orders that never open a browser. The specification lists which order paths on your store bypass checkout, and the build covers them from the server keyed to the order ID. Whether a renewal counts as a purchase, and at what value, is settled in the spec before anything is built.

Multi-currency. The presentment amount and the currency code are built to travel together on every order, and that is verified against a real order in a second currency rather than assumed.

How it runs

Scope comes before price. What gets built depends on the platform, the checkout, and how many order paths bypass a browser. That is established on a call, and the work is quoted fixed-price against it.

A written event spec for your store. Every funnel event, the shape of the items array, the canonical identifier and the level it sits at, the revenue definition, and the order paths that never open a browser. Written before any tag exists, so what gets built can be checked against something.

Delivered where the platform intends it to live. App embeds and the customer events layer on Shopify, a plugin or child theme hook on WooCommerce, the application itself on a custom build. Theme files are the last resort, because publishing a theme replaces what is installed, and a snippet in the old one does not come with it.

Tested with real orders, then reconciled. Low value live orders through each payment method that behaves differently, every consent state your store presents, and a refund to prove the reverse path before you need it. Which consent states your store is required to offer is a question for your counsel. Then purchase count against order count for a closed period, matched at the order ID level, with the exclusions written down: test orders, draft orders, POS, cancellations. Every remaining order in the gap is named. A residue under your order count survives any collection that depends on a browser, so the acceptance test is that all of it is accounted for and none of it is unexplained. A count above your order count is a defect rather than a bonus, and it is treated as one.

What you get

A funnel that fires, evidenced. Each event with its payload, before and after, at the destination rather than in a preview panel.

The reconciliation itself. The closed-period comparison at the order ID level, what accounts for each part of the residue, and the exclusion list. This is the page you hand over next time finance asks.

The event spec, maintained. The identifier scheme and the revenue definition written down, with the figure in your store admin each should be compared against.

A recorded walkthrough and a support window. Every event on the store, where each one is delivered from, and questions taken after handover for a period set in the scope.

When this is the wrong fit

You want conversion rate work. This measures the funnel. It does not redesign it.

You want GA4 revenue to equal your accounting. It will not, and a build that forces it has broken something. What you get is a difference you can explain, on definitions you chose.

You need the numbers to go up. Correct tracking often reports less than broken tracking did. That should be expected before the work starts, not discovered after.

The brief is to find out what is wrong. Diagnosis is a different engagement and it comes first.

The usual way in is the Missing Conversions Audit: $900 flat, every gap logged, and the fee credited in full toward the build that follows. For a store it settles what a build would otherwise be scoped around blind: which orders are going missing, and where they are lost. Bring that to the call and the build gets scoped against it.