GA4 Audit Report Template: What Stakeholders Actually Read (2026)

What goes in a GA4 audit report?

A useful GA4 audit report has six sections in this order: (1) executive summary (1 page, severity-ranked findings + business impact in £/$), (2) property configuration findings, (3) tag and consent findings, (4) attribution findings, (5) data quality findings, and (6) a prioritised remediation roadmap with effort estimates. Length: 12–20 pages for SMB, 30–50 pages for enterprise. Anything longer is usually padded; anything shorter is missing context. Each finding includes severity (Critical/High/Medium/Low), description, evidence (screenshot or query), business impact in monetary terms, recommended fix, and effort estimate.

The executive summary is the only section the CMO will read. The other five are for the people who will fix things.

The six-section structure

Section 1 — Executive summary (1 page max)

The CMO opens the report, reads this page, and either approves remediation work or doesn't. Everything else is supporting evidence.

What goes here:

• Headline finding (one sentence summarising the audit's most important conclusion)
• 5 highest-severity findings in order, each with one-line description and £/$ business impact
• Overall data quality score (e.g., 67/100, with breakdown by domain)
• Recommended next 30 days — the top 3 remediation actions

What does NOT go here:

• Any technical detail
• Methodology description
• Findings below Critical or High severity
• Generic best-practice language

The page should pass the "30-second test" — a CMO with 30 seconds available understands what's broken, what it's costing, and what to do next.

Section 2 — Property configuration findings (PC)

Configuration issues that don't require live tag inspection. Examples:

• Data retention set below 14 months (silently breaking Explorations beyond the window)
• Time zone misconfigured (causing day-boundary attribution errors)
• Internal traffic filters not configured (inflating session counts with team activity)
• Currency mismatch between data streams
• Reporting identity choice misaligned with use case (Device-based when User-ID exists)
• Conversion events not marked as key events
• Audience definitions with logic errors

Format per finding: severity badge, description, screenshot or admin path, business impact, fix steps, effort estimate (in hours).

Section 3 — Tag and consent findings (TC)

Live tag firing, consent mode, dataLayer integrity. Examples:

• Consent Mode V1-only implementation (V2 required since March 2024 for EU/UK Google Ads)
• GA4 cookies firing before consent (CMP race condition)
• Uninitialised dataLayer
• PII detected in event parameters
• Missing gcd parameter
• Tag firing without consent in Basic mode
• Hardcoded GA snippets bypassing GTM consent

Each finding needs DevTools-verified evidence — network request screenshot, parameter values, the specific page URL where the issue was reproduced.

Section 4 — Attribution findings (UC)

Whether traffic is attributed to its true source. Examples:

• Custom channel group missing (AI traffic buried in Referral)
• Payment gateway self-referrals (Stripe, PayPal, Klarna stripping UTMs)
• gclid lost on SPA navigation
• Inconsistent campaign tagging across teams (medium='paid_social' vs 'cpc' for the same channel)
• Cross-domain tracking gap
• Auto-tagging conflicts (gclid stripped by intermediate redirects)

Include a Source/Medium audit table showing where attribution is leaking — usually 5–15% of paid traffic in Direct on a typical mid-market property.

Section 5 — Data quality findings (DQ + EC)

Statistical credibility checks plus e-commerce validation. Examples:

• Bot traffic spike (statistical anomaly above Z-score threshold)
• Cardinality limit exceeded (dimensions collapsed to 'other')
• Sessions per user abnormally high (>5)
• Zero mobile traffic detected
• Unexpected hostnames sending data
• Duplicate transactions from client+server double-firing
• Missing items array on purchase events
• Refunds not tracked (revenue overstatement)
• Cross-source reconciliation gap (GA4 vs Shopify vs Stripe)

Cross-source reconciliation is where audits prove their value. Show GA4 revenue alongside the source-of-truth revenue from Shopify/Stripe/CRM for a 7-day window. The gap (typically 5–25%) is what a paid audit pays back.

Section 6 — Prioritised remediation roadmap

The "what to do next" section. Findings grouped by:

• Quick wins (under 4 hours engineering each — usually 5–15 items)
• Medium effort (1–3 days each — usually 5–10 items)
• Structural (1+ weeks each — usually 1–3 items)

Each item linked back to its finding number above. Effort estimates in hours, owner suggested (engineering / marketing / external), expected business impact restated.

This is the section that determines whether the audit gets actioned. A roadmap that's too vague ("improve attribution") doesn't get scheduled; a roadmap that's too detailed ("review line 47 of GTM container") doesn't get prioritised. The sweet spot is mid-grain: "Fix payment gateway self-referrals (3 items, 4 hours total) — recovers ~8% of paid traffic attribution".

The severity scoring framework

Every finding needs a severity rating. The four-tier framework that works:

Critical — actively producing wrong data that drives business decisions, or actively non-compliant.

• Examples: PII in event params (TOS violation), Consent Mode V1 in EU/UK production (compliance breach), GA4 reporting 30%+ different revenue than Shopify (decision-grade data wrong)
• Should be fixed within 7 days
• Triggers immediate stakeholder notification

High — meaningfully degrading data quality but not catastrophic, or fixable workaround exists.

• Examples: Custom channel group missing for AI traffic, gclid lost on some SPAs, sessions-per-user anomaly indicating bots
• Should be fixed within 30 days
• Included in the executive summary if among the top 5

Medium — quality issue that affects optimisation but not core reporting.

• Examples: Sub-optimal cardinality on a custom dimension, internal traffic filter missing one IP range, Looker Studio cached reports beyond useful TTL
• Should be fixed within the quarter
• Listed in domain section, not executive summary

Low — best-practice deviation with no immediate business impact.

• Examples: Audience naming convention inconsistency, sub-optimal report Library organisation, missing annotations for major changes
• Fix when convenient
• Listed in domain section as a one-line note

Most audits surface 30–60 findings on a mid-market property. A typical distribution: 2–5 Critical, 8–15 High, 15–25 Medium, 5–15 Low. If your audit shows 30+ Critical findings, either the property is genuinely broken (rare) or your scoring is too aggressive (common).

Length benchmarks

The number of pages a GA4 audit report should be is a function of property complexity, not audit thoroughness:

Reports beyond 80 pages tend to lose readers — split into multiple deliverables (executive briefing + technical appendix) instead of one giant PDF.

Reports below 12 pages on a mid-market property are usually missing depth — either skipping cross-source reconciliation, skipping live tag inspection, or skipping the remediation roadmap.

Format choices that matter

PDF or PowerPoint? Both. PDF for the comprehensive report (technical audience), PowerPoint for the executive readout (stakeholder presentation). Most agencies deliver both for the same engagement.

Branded or white-label? Branded if you're the agency selling future engagements; white-label if you're a tools vendor letting agencies resell. The Agency Pro tier of most audit tools ($999/year+) unlocks white-label PDF and PowerPoint output.

Print-friendly or screen-only? Print-friendly. Even in 2026, stakeholders print key sections to read in meetings. Use legible body text (11pt+), clear table borders, sufficient margins.

Multiple files or one? One primary deliverable plus an appendix file with raw data exports. Splitting into 5+ files creates "where's the actual report?" confusion.

Static or interactive? Static for the audit report itself. Interactive (Looker Studio) for the ongoing monitoring dashboard that comes after remediation — different artifact, different purpose.

What stakeholders actually read

Eye-tracking and engagement data on professional reports is sparse, but our experience across hundreds of audit-report walkthroughs:

• Executives read the executive summary in full. Page 1 only. They occasionally skim section headers.
• Marketing directors read the executive summary plus the attribution findings section. They want to know what's wrong with their channel reporting.
• Engineering leads read the tag/consent and remediation sections. They want the implementation detail and effort estimates.
• Compliance officers (when involved) read the consent findings section in isolation. They cite specific pages back at the team.
• Junior analysts read the entire report. They're learning. The deep detail in sections 2–5 exists for them.

Design the report knowing each section has a different audience. A finding about Consent Mode V1 should be technically specific in section 3 (for engineering) but framed in £/$ business impact in section 1 (for executives).