Buying a GA4 audit: what should the agency actually check?

An audit should answer a business question.

Can we trust the inquiry count? Are purchases duplicated? Why do the store and the report disagree? Start there. A long list of configuration observations is less useful if nobody can explain which decisions it puts at risk.

List the journeys that matter: a successful inquiry, a purchase, a booked demonstration or another meaningful action. Include the systems involved and the people who own them. A website form connected to a separate scheduling tool needs a different review from a single-page brochure site.

Ask the agency to distinguish a review of the current setup from a repair project. They are related scopes, but the quote should tell you which one you are buying.

Make the test plan visible.

Include mobile journeys and relevant consent states in the agreed tests. Let the appropriate privacy owner determine permitted collection. Testing a single browser in one state is not the same as validating every visitor’s experience.

A successful click is not always a successful inquiry.

Imagine a fictional form where the submit button sends an event before required fields are checked. A person can trigger the event without sending an inquiry. A report based on that event may overstate successful submissions.

A useful audit records the failed submission, compares it with a completed one and identifies the implementation point that represents success. The fix then needs a retest. A recommendation that simply says “improve conversion tracking” leaves too much work undefined.

For a store, use a similarly controlled journey: view a product, add it to the cart and place an authorized test order in the appropriate environment. Confirm the intended purchase record without repeatedly creating live transactions. Agree the testing procedure with the store owner first.

Use diagnostics as evidence, not a verdict.

GA4 DebugView helps inspect events during testing. Ask for the steps, observed event and relevant parameters behind a finding. A tool’s pass/fail summary can help prioritize work, but it does not explain whether the implementation matches your business definition.

For ecommerce, Google documents specific shopping events and parameters. The proposal should identify which apply to your store and who will maintain the implementation when the storefront changes.

Do not expect every system to show identical totals. Reporting windows, consent, refunds, attribution and implementation can contribute to differences. Ask the auditor to distinguish explained differences from defects instead of forcing numbers to agree.

Buy a handoff your team can use.

Request an issue log with business impact, reproducible evidence, recommended action, owner and priority. Ask which recommendations the agency can implement, what access it requires and which need a developer or another vendor.

Agree acceptance checks before repairs begin. For example: a failed form validation does not count as a successful inquiry; a valid test submission produces the agreed event once; the result is documented. The appropriate criteria depend on your implementation.

Keep an event dictionary and a record of changes. Otherwise a future form update can undo the repair while the dashboard continues to look reassuringly familiar.

A few questions before you brief the crew.

Does a GA4 audit include fixing everything?

Only if the scope says so. Separate diagnosis, implementation, retesting and ongoing monitoring when comparing proposals.

Will an audit recover data that was never collected?

Do not assume it will. Ask what can be reconstructed from other records and what remains unknown. Fixing future collection does not automatically repair historical reporting.