A utility company moved to server-side tagging and made its consent posture defensible

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

The utility serves households across one region, and its customer portal — billing, usage data, outage reporting — is treated internally as an essential service with an uptime expectation to match. Marketing sits beside that portal, promoting efficiency programs and tariff switches, but the portal team ships on its own cadence and answers to its own risk review. After legal flagged what client-side tags had been doing, most measurement was simply switched off, and the marketing team spent a year planning campaigns with almost no data. The culture had become: when in doubt, untag it.

What it was costing

The utility's customer-portal analytics used client-side tags that fired before consent and occasionally captured account numbers in URLs; legal flagged it, marketing lost most measurement, and nobody could say which tags fired what, where.

What they could see

• Legal's review found account numbers reaching tag URLs on some portal pages, and the finding went straight to the executive team.
• Consent was requested in the browser but not enforced anywhere a regulator could inspect, so nobody could prove what fired when.
• Marketing lost most of its measurement overnight, and campaign planning ran on platform self-reported numbers nobody trusted.
• No one could produce a list of which tags fired what, where, on the portal — the estate had outlived its documentation.

The constraints we worked inside

• Regulated-website requirements: personal data must not reach advertising vendors, and consent state must be enforceable server-side, not merely requested client-side.
• The portal team ships on a separate cadence from marketing; tagging changes cannot require portal releases.
• Outage tolerance is near zero — the portal is an essential service, and tagging infrastructure must fail open.

What had been tried before

The team implemented a consent banner with client-side Consent Mode defaults across the portal's marketing pages.

Client-side consent is a request the browser makes on its honor system; legal could not verify enforcement, and identifiers could still leave in URLs before any script respected the banner.

IT produced a one-off log analysis of portal traffic to answer a marketing question after the tags were removed.

It took weeks, answered one question, and was stale on arrival — an artifact, not a system, and the portal team declined to own anything that looked like analytics plumbing.

What we proposed

We proposed moving the boundary server-side: a first-party tagging layer receives portal events, enforces consent state, and strips identifiers before anything reaches a vendor, so the browser never talks to third parties directly. URL and payload scrubbing would run by default with an allowlist legal reviews and signs, making the account-number class of incident structurally impossible rather than policed. The layer deploys redundantly with health checks that alert operations, and its failure degrades measurement — never the portal. The point was to give marketing durable measurement while giving legal something it could actually audit: one door, one policy, one log.

Just as important is what we ruled out, and why:

• Client-side tagging with stricter consent configuration — It leaves enforcement in the browser, which is exactly what legal had already rejected — unverifiable, unprovable, and one script error away from another finding.
• A portal-vendor analytics module with built-in compliance — The vendor's roadmap put delivery a year out and every change would ride portal releases — the same change-control constraint the tagging layer was designed to escape.
• Full measurement freeze until the portal is rebuilt — The rebuild has no committed date, and marketing would spend another planning cycle blind; the risk was not worth indefinite silence to a regulated operator.

How the work ran

Delivered by the growth pod — analytics specialist over 8 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Google Tag Manager (server-side)

Server-side is the only architecture where consent enforcement and redaction happen before data leaves the company's perimeter — client-side could never satisfy legal's requirement.

Consent Mode

It translates the portal's consent state into vendor signals at the tagging layer, so declining users are respected uniformly without per-vendor integration work.

BigQuery

Event logs and the redaction audit trail live in the company's own warehouse, giving legal a permanent, queryable record of what left and what was stripped.

Cloud Run

The tagging layer must fail open and scale with billing-day peaks; managed infrastructure with health checks fit the portal team's operations model without new servers.

Legal-reviewed redaction allowlist

Redaction by default with a signed allowlist turns compliance from a review-per-campaign into a standing policy — the document legal audits rather than the tags themselves.

What went wrong

How we worked together

Cadence

Fifteen minutes twice weekly with the marketing lead and the portal team's technical owner; a monthly written compliance summary went to legal with the redaction report attached.

Client side

The portal team's technical owner co-designed the enforcement point and owns the health alerts; marketing's lead owned event definitions; legal reviewed the allowlist as a named approver.

Decisions

Anything inside the redaction boundary was legal's call, full stop; measurement scope and event definitions were settled in the twice-weekly call and logged in the decision record.

They provided

Portal event access through the integration layer, legal's review time in two structured sessions, operations sign-off on the fail-open design, and staging access mirroring billing-day load.

What changed

The headline: all portal measurement flowing through the first-party tagging layer with consent enforced and identifiers stripped — Client-side exposure → server-side enforcement, read from Legal review sign-off. A second check: vendor-bound requests carrying account identifiers since cutover at 0.

Marketing plans campaigns again, and the portal team stopped seeing the marketing stack as a threat after the first quarter passed with zero vendor-bound identifiers and no portal incidents. Legal moved from gatekeeper to auditor: the redaction report arrives monthly, gets read, and raises no follow-ups. The phrase too risky to touch has left the vocabulary, replaced by a one-page measurement policy that says what is collected, what is refused, and who approves a change — and the answer to who approves is a person, not a shrug.

The result was read from Legal review sign-off against the pre-engagement baseline over the stated window, with a guardrail check on vendor-bound requests carrying account identifiers since cutover. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The server-side tagging layer with its redundant deployment and health-check alerts, operated by the portal team.
• The legal-reviewed redaction allowlist and the monthly audit report format counsel approved.
• The one-page measurement policy — collection, refusal, approval — versioned with the compliance records.
• BigQuery event and audit-log tables with retention settings agreed with legal.
• A runbook and one rehearsal for the fail-open cutover drill the operations team now owns.