How to hand over a GA4 and Meta Pixel tracking QA to your client
A tracking handover without evidence tends to come back weeks later as "the numbers look wrong". A short QA report gives that conversation a concrete starting point: the agreed plan, the journeys tested, the results and the remaining limitations.
1. Agree on the plan before you test
Write down the events the site must send and what each one must contain: platform, exact event name, required parameters, value rules, how many times it may fire and the consent it needs. Keep it as a file the client can read and you can version, such as a CSV (see how to write a tracking plan as a CSV). If the client never agreed on a plan, the report can only say what fired, not whether it is right.
2. Run the journeys that matter
- The ecommerce path: product page, add to cart, checkout start and purchase, with an order whose transaction ID you write down. Use the payment provider’s test mode or a test order where available. Use the provider’s documented test checkout and record any differences from production. Coordinate any switch to test mode on a live store: it can prevent customers from making real payments.
- The thank-you page again: reload it or come back to it, because a purchase sent a second time is one of the most common problems (see duplicate purchase events in GA4).
- Lead forms, if the site has them: one valid submission and one with a validation error.
- Consent: a fresh visit with no saved choice, one where the visitor rejects and one where they accept, if the site has a consent banner (see how to check Consent Mode v2 in the browser).
3. Put the evidence in the report
- Context: site and environment (staging or live), date, browser and the version of the plan.
- One line per planned event: status (pass, fail, to review, not observed) and, for each problem, what was expected, what was sent and in which request.
- Values and duplicates: the value and currency of each purchase, whether the same order was sent more than once, and whether the browser sent comparable values to GA4 and the Meta Pixel for the same order (see GA4 and Meta purchases that don’t match).
- Consent: the consent state when each event that needs it was sent.
- Pending items: what you could not test (for example, a payment method without a test mode) and who owns each fix.
4. State the scope in writing
A browser check shows what the browser sent during the journeys you ran. It does not show how Google Analytics or Meta processed those events, what server-side tagging or the Conversions API sent from the server, or whether the site complies with privacy law. Say so in the report. To check whether events appear in the destination platform, repeat the journey using GA4 DebugView with debug mode enabled, or use Realtime for an initial check. DebugView may not show events when analytics consent is denied. For Meta, use Test events in Events Manager. Keep this evidence separate from the browser capture: these checks do not establish final attribution or complete reporting.
5. Remove personal data before you share it
Requests can carry client IDs, session IDs, emails or advanced matching data. Hide or mask them before the report leaves your hands, and review the rest of the values: an order ID or a URL parameter can also identify someone.
6. Plan the recheck
Tracking breaks when something around it changes: a new checkout, a theme update, a tracking app or a consent tool. Agree with the client to rerun the same journeys against the same plan after those changes, and keep each report so you can compare them.
Checklist
- The plan is written and the client agreed to it.
- Each planned event was observed, or is listed as not observed with a reason.
- Purchases: one per order, correct value and currency, comparable in GA4 and Meta.
- Consent: behaviour checked with no choice, with a rejection and with an acceptance.
- The report states its scope and lists pending items with an owner.
- Personal data is hidden or masked.