Skip to main content
Back to Scope Definition v2.0.0

Scope Explainer

Analytics Provider Integration — Scope Explainer

Analytics integration is the engineering that wires a provider (GA4, Plausible, PostHog or equivalent) into the site behind a compliant consent gate — not the dashboards, reports, attribution models or marketing strategy that sit on top of the resulting data.

Commercial explainer only. In any conflict, the binding clause prevails. Read the binding clause (item #12).

Version
v2.0.0
Last updated
2026-05-16
Immutability
Immutable

What it means & why it matters

Analytics integration has two distinct layers. The engineering layer is the snippet, the consent gate, the page-view emission on SPA route changes, the typed custom-event API, and the validation that data actually arrives in the provider. SessDev ships the engineering layer.

The data layer — dashboards, weekly reports, conversion definitions, multi-touch attribution, cohort analysis, A/B testing decisions — is product and marketing work. It depends on the business question, not on the build, and it sits outside the engagement.

The provider account is owned by the client. SessDev integrates against it; SessDev does not pay the bill, does not hold the admin, and does not assume responsibility for the analytics roadmap.

What SessDev includes

  • Documented recommendation between GA4, Plausible, PostHog or an equivalent provider, based on privacy posture, data-residency requirements and the agreed event volume.
  • Provider snippet integrated through the head with a CSP-safe nonce, deferred to avoid blocking first paint.
  • Analytics fires only after explicit user consent through the cookie / consent banner; pre-consent state emits nothing trackable.
  • Automatic page-view tracking on SPA route changes, including locale segment so traffic can be sliced per language.
  • Typed custom-event API with 3–5 default events agreed at scope time (e.g. form submit, CTA click, outbound link). Adding events post-launch is a documented change.
  • Pseudonymous user-id wiring when the provider supports it natively, so authenticated and anonymous sessions can be stitched without persisting PII.
  • Optional server-side proxy / first-party endpoint design when the provider supports it, to harden against ad-blockers and ITP without breaching consent.
  • 1 end-to-end validation pass: consent granted → page view recorded → default events fire → events visible in the provider in real time.
  • 1 recorded walkthrough for the marketing team covering how to read the live event stream and how to scope a new event request.

What is excluded

  • Creating the provider account, organisation, billing entity or workspace structure on the client's behalf.
  • Paying the provider invoice, monitoring quota limits or reconciling overage charges.
  • Custom dashboards, exploration boards or saved reports inside the provider UI.
  • Weekly, monthly or quarterly reporting cycles, KPI summaries or stakeholder presentations.
  • Multi-touch attribution models, channel attribution or marketing-mix modelling beyond the default last-click view.
  • Defining what counts as a conversion, the funnel logic, the goal hierarchy or the success metrics for the business.
  • Custom audience segments, retention cohorts or persona-based filtering beyond the default events.
  • Cohort analysis, lifecycle reports or longitudinal user-behaviour studies.
  • A/B testing platforms, experiment design or statistical analysis of variants.
  • Export pipelines to BigQuery, Snowflake, Redshift or any warehouse beyond the provider's native UI.
  • Growth strategy, channel mix decisions, paid-media planning or content-marketing roadmap.

Risks if this is mis-configured

  • Consent breach

    If analytics fires before consent is granted — a regression, a misconfigured wrapper, a third-party tag injected later — the site is in breach of GDPR, ePrivacy or CCPA. Fines and reputational damage exceed any analytics value gained.

  • PII leak in URL parameters

    Forms that POST through GET, magic-link tokens in the URL, or user emails appended as query strings can be captured by the provider as page-view URLs. This is PII in an analytics system that is not contracted to hold PII.

  • Browser blocking and ITP erosion

    Ad-blockers, Safari ITP, Firefox ETP and iOS Private Relay erode the sample by 20–60% depending on the audience. Decisions made on the resulting numbers under-count mobile and privacy-conscious users systematically.

  • Bot traffic inflation

    Headless browsers, scrapers and uptime monitors fire page views and events the same way humans do. Without bot filtering, the numbers inflate silently and any optimisation decision against them is wrong.

  • Provider account loss

    If the client misplaces the provider admin credentials, leaves the company, or fails to add a backup owner, the account becomes irrecoverable. SessDev does not hold those credentials; recovery is the client's responsibility.

  • Sampling and methodology drift

    Providers change sampling thresholds, default event definitions and identity-resolution logic without explicit notice. Year-over-year comparisons silently become apples-to-oranges; no engineering work catches that drift.

  • Event schema creep

    Every marketing experiment wants one more event. Within months the schema has 200 ad-hoc events, no taxonomy, no documentation, and reports become unreliable. Adding events should be governed, not improvised.

Use case — Partner

Your agency owns the marketing strategy, the dashboards and the reporting cycles. SessDev ships the analytics plumbing — provider snippet, consent gate, page-view tracking, typed events, validation — so the data your team reports on is real, compliant and complete. Recommended pairing: SessDev Care retainer to absorb event-schema additions, monitor consent-gate regressions, and patch tracking when providers change their snippets or identity-resolution rules.

Apply as a partner

Use case — One-Shot

You receive the analytics integration as part of the buyout: provider snippet, consent gate, page-view tracking, default events, validation. After handoff, dashboards, reports and marketing decisions are yours. If you plan to add events as you learn what to measure — and most teams do — add a Care plan at quote time so each new event is scoped, typed and validated instead of patched into production.

Request a one-shot quote

Related scope items

Frequently asked questions

Which analytics provider do you set up?
GA4, Plausible or PostHog by default, chosen on privacy posture and data-residency needs. Other equivalent providers are evaluated case by case during discovery.
Who owns the analytics data and the provider account?
The client (or partner agency) owns the account and the data. SessDev integrates against it and does not retain copies, does not resell the data and does not sit between the client and the provider's billing.
Is consent required before analytics fires?
Yes, by default. Analytics is gated behind explicit consent through the cookie / consent banner. Pre-consent state emits no trackable signal. Opting into a less-strict policy is a documented client decision and only available where local law allows it.
Do you build dashboards or weekly reports?
No. SessDev ships the integration; dashboards, weekly reports and stakeholder presentations are owned by the client or a marketing-services partner.
How do you handle GDPR / ePrivacy?
The integration is consent-gated by default, avoids capturing URL parameters that commonly contain PII, and works with providers that offer EU data residency where required. The client is still responsible for the privacy policy, the cookie banner copy and the data-processing agreement with the provider.

Legal reference

Read the binding scope clause — item #12, v2.0.0