What Analytics Services Actually Include
Setup, audit, and reporting - what each one should deliver, and how to tell a real one from a template.
"Analytics services" gets used loosely enough to mean almost anything - a one-off tag install, a monthly dashboard subscription, a full engineering engagement. In practice, the work breaks into three distinct jobs: setup, audit, and reporting. Each has a real scope. Here is what belongs in each.
Setup
A complete setup is more than pasting a tracking snippet into a site header. It should include:
- A written event schema - what each event is called, what properties it carries, and who owns changing it
- Consent-aware collection wired in from day one, not bolted on after a compliance review
- A server-side layer where client-side collection is unreliable (ad blockers, browser privacy restrictions, app-tracking limits)
- QA against real user flows - checkout, signup, key conversion paths - not just a "tag fired" check in a debugger
- Documentation handed to you, not retained only in the vendor's head
Ecommerce and platform-specific setup
Ecommerce setups (including WooCommerce and similar store platforms) carry extra weight because product, cart, and transaction events must reconcile with your store's own order and revenue records exactly. A complete ecommerce setup maps product identifiers consistently across the storefront and the analytics layer, captures refunds and cancellations (not just completed purchases), and validates that reported revenue matches the store's ledger before it is called done.
Audit
An audit is a diagnostic, not a health score. A real one checks:
- Event completeness - does every meaningful user action actually fire an event, matched against the site or app's real flows
- Deduplication - are events double-firing on page reloads, single-page-app route changes, or retries
- Identity and session stitching - are logged-in and anonymous sessions correctly connected, and across devices where relevant
- Consent coverage - does every event carry a lawful basis, and does denied consent actually stop collection
- Cross-platform consistency - do the numbers in analytics agree with ad platforms, CRM, and actual sales data closely enough to explain any gap
The output should be a specific, prioritized list of fixes - not a percentage score with no path to improving it. If a discrepancy between platforms is systemic rather than a bug, a good audit says so and explains why (see our note on why numbers don't match across platforms).
Reporting
Reporting services should deliver more than a dashboard link. What belongs in a proper reporting engagement:
- Documented metric definitions - what exactly counts as a "conversion," a "session," a "qualified visitor" - shared across every team that reads the report
- A single source-of-truth layer feeding whichever dashboard tool your team uses, rather than each stakeholder pulling from a different platform's native report
- Scheduled validation so a broken tag or a platform API change doesn't silently produce wrong numbers for weeks
- A format built to be presented - see our note on building an ROI report you can defend in the room
How the three connect
Setup produces the data, audit verifies the data is trustworthy, reporting turns it into something a team can act on. Skipping the audit step is the most common failure mode we see: a technically correct setup that quietly drifts out of accuracy as a site changes, discovered only when someone finally asks why two reports disagree.
Setup, audit, and reporting - common questions
▸Is analytics available as a service, or do I need to hire in-house?
Both models work, and most teams use a mix: an outside practice for the initial architecture and periodic audits, an internal owner for day-to-day monitoring. What matters is that someone owns the tracking plan as a living document - "as a service" just describes who that someone is.
▸What is included in a google analytics audit specifically?
A proper audit checks event completeness against your actual site or app flows, deduplication and double-counting, identity and session-stitching accuracy, consent-state coverage, and consistency between GA4 and every other platform reading the same journeys (ad platforms, CRM, sales data). It should end in a written list of specific fixes, not a general health score.
▸How often should analytics reporting be reviewed?
Event-level validation belongs in your release process, ideally automated. Full reporting-layer reviews - checking metric definitions still match how the business talks about them - are typically useful quarterly or after any major platform migration.
▸Do analytics services include ecommerce and WooCommerce setup?
Yes - ecommerce tracking is one of the more detail-sensitive setup jobs, because product, cart, and transaction events need to reconcile with your store platform's own order records exactly. See the ecommerce section above for what a complete setup covers.
Not sure which of these three you actually need?
A short audit call tells you whether the problem is setup, audit, or reporting - before you pay for the wrong one.