Most stores lose purchases silently: the pixel fires in the browser, a consent tool blocks it, or the browser and server both count the same order. We check what actually fires, what Meta and GA4 actually receive, and whether the numbers can be reconciled with your orders.
Twelve checks across the three places tracking breaks
This is the same list we run on our own stores. Nothing here requires guesswork about what Google or Meta 'prefers' — it is either wired correctly or it is not.
Browser side
Meta pixel loads, with the right pixel ID, on every template (home, collection, product, cart, checkout)
Events cover the funnel, not just PageView: ViewContent, AddToCart, InitiateCheckout, Purchase
GA4 receives the same events, with items, value and currency populated
Consent tool behaviour: whether tracking is blocked before consent, and what is lost when it is
Server side
A server-side path exists at all, and whether it is guarded against third-party event injection
Browser and server events share one event id, so a purchase is counted once rather than twice
Match quality: hashed email and phone, external id, client IP and user agent are attached
Retry behaviour: whether failed sends are retried, and whether retries can double-count
Data integrity
Purchase fires once, on the right trigger — order confirmed or payment paid — not on both
The event id derives from the order number, so a refresh or resend cannot duplicate a sale
Values and currency match what the customer was actually charged
Whether the numbers your platforms report can be reconciled with your order table at all
What you get
A report someone can act on
A written report: every finding, its severity, and the order to fix them in
Annotated screenshots of what we saw, so you can check our work rather than trust it
A one-page summary you can hand to a developer
A 30-minute walkthrough call, recorded if you want it
A fixed-price quote for the install, with no obligation to take it
Not included
The install itself — that is a separate, quoted piece of work
Ad strategy, campaign builds or creative
Server container hosting costs, which are paid directly to the provider
Any promise that ROAS improves — we fix measurement, the platforms decide the rest
Stated up front because the opposite is common: an "audit" that is really a sales call, and a fix that was never scoped. You get the findings in writing whether or not you hire us for the install.
Questions
The things buyers ask before paying
If something is still unclear, ask before you buy — we would rather answer than refund.
What access do you need?
Read access is ideal but not required for most of it. We can audit the browser side, the event payloads and the server path from outside. If you want the purchase event and order path verified properly, we need repository or server access — never a password to your own accounts.
What if I have no tracking set up at all?
Then the audit is short and the answer is straightforward: here is what is missing and what an install costs. You still get the written report, and you are not charged for the install unless you take it.
Shopify or custom store — does it matter?
No. Shopify stores are audited through the theme, apps and checkout; custom stores are audited through their own code and API endpoints. The checks are the same, only the instruments differ.
Why 48 hours?
Because the work is bounded: a fixed number of checks against one store. If the audit needs more than 48 hours you will be told before we start, not after.
Will this fix my numbers?
No. The audit tells you what is wrong and in what order to fix it. The fix is the install. We separate the two deliberately, so you are never paying for a diagnosis you did not ask for.
Send us the store, we'll tell you what we'd find
Send the domain and what you already know. If the audit isn't the right starting point for your situation, we'll say so and suggest what is.
