NEXSUM_LABS
  1. Home
  2. Work
  3. A telehealth dermatology service rebuilt its marketing funnel measurement without touching patient data
Book a call

[ Case study ]

TelehealthGoogle Tag Manager (server-side)GA4Change-control event layerDe-identification allowlist

A telehealth dermatology service rebuilt its marketing funnel measurement without touching patient data

The provider couldn't see which campaigns produced consultations: the booking flow sits behind a patient portal, client tags had once collected form input that legal had to remediate, and marketing measurement had been frozen since as 'too risky to touch.'

CLIENT a telehealth dermatology provider — FOCUS Funnel events without the portal

Google Tag ManagerAnalytics & CROGoogle Tag ManagerTelehealthRepresentative example
Client
a telehealth dermatology provider
Industry
Telehealth
Engagement
6 weeks — growth pod — analytics specialist
Service
Analytics & CRO / Google Tag Manager
Headline outcome
Campaign-to-consultation funnel measurable with the de-identification policy in force: Frozen measurement → governed funnel, read from Policy document + funnel reports

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 provider delivers dermatology consultations by video, with new patients starting from paid search and social, passing an intake, and booking inside a patient portal built on validated clinical software. Marketing owns the top of that journey but has no code access to the portal itself, and a past incident — form input collected by a script — had left legal scar tissue deep enough that all measurement was frozen. The tension is structural: marketing needs funnel granularity to buy consultations efficiently, and legal needs prohibition on anything identifiable, and both positions are correct.

What it was costing

The provider couldn't see which campaigns produced consultations: the booking flow sits behind a patient portal, client tags had once collected form input that legal had to remediate, and marketing measurement had been frozen since as 'too risky to touch.'

What they could see

  • Campaign budgets were set from platform-reported consultation counts that no internal data could confirm or deny.
  • Nobody could say where in the intake journey prospective patients stalled, because the portal's interior was unmeasured by policy.
  • The marketing team had stopped proposing funnel tests entirely — every idea died with a version of the phrase too risky.
  • Legal carried a standing veto over marketing tooling with no process to approve anything, so even safe requests went nowhere.

The constraints we worked inside

  • Nothing identifiable may reach advertising platforms — not IDs, not form contents, not combinations that could re-identify.
  • The patient portal is validated software; changes require change-control, so tagging must live outside it.
  • Marketing needs funnel granularity; legal needs prohibition. Both must be satisfied in one architecture.

What had been tried before

Marketing relied entirely on the ad platforms' own consultation-conversion reports, imported monthly into a simple tracking sheet.
The platforms grade their own homework and count differently from each other, so channel comparisons were fiction — and legal rightly noted the platforms received more data than anyone could verify.
A vendor proposed a client-side funnel tracker with aggressive field filtering to satisfy the privacy rules.
Filtering happens in the browser after collection, which legal had already ruled unacceptable once — the proposal repeated the exact architecture that caused the original remediation.

What we proposed

We proposed keeping the portal untouched and letting its existing integration layer emit coarse, anonymous funnel events — consultation started, intake step passed, consultation completed — under the portal team's normal change control. A server-side layer would forward only allowlisted, de-identified event shapes; anything resembling an identifier is dropped and logged. The architecture satisfies both requirements at once: marketing gets its funnel, legal gets structural refusal rather than promises. The third piece was procedural — a one-page measurement policy stating what is collected, what is refused, and who approves changes, converting an unmanageable veto into a governed process.

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

  • Server-side tracking keyed on hashed patient identifiersHashes of names and contact details are still identifiers under the rules legal applies, and re-identification risk from combinations killed it in the first design review.
  • Panel-based or modeled consultation attributionModeled conversions cannot be audited against the clinic's real booking counts, and in a regulated context an unauditable number is worth less than a narrow, honest one.

How the work ran

01Funnel events without the portal

Consultation starts and completions are emitted by the portal's existing integration layer under change control as coarse, anonymous events — marketing gets the funnel, the portal stays untouched otherwise.

02Vendor calls behind a proxy that refuses

A server-side layer forwards only allowlisted, de-identified event shapes; anything resembling an identifier is dropped and logged.

03Write the rules down

A one-page measurement policy — what is collected, what is refused, who approves changes — turned 'too risky to touch' into a governed process.

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

The stack, and the reasoning

Google Tag Manager (server-side)
The refusal layer had to sit on infrastructure the portal team never touches; server-side gave legal a single chokepoint to audit and marketing a container they can extend safely.
GA4
The funnel reports marketing already knows how to read, fed only by the allowlisted anonymous events, so adoption required no new tool training during a trust-sensitive rollout.
Change-control event layer
The portal is validated software; emitting events from its integration layer under the same change control kept the compliance boundary intact instead of routing around it.
De-identification allowlist
An explicit list of permitted event shapes is what legal signs — refusal by default means every future marketing request is a policy question, not a code review.
BigQuery
Dropped-event logs and forwarded events live side by side in the warehouse, so policy violations are provable-absent rather than asserted-absent.

What went wrong

Obstacle

Legal joined in week three instead of week one and imposed two structural requirements — no portal code changes, refusal before vendor egress — that forced a redesign of nearly everything.

Handled: We discarded three weeks of design rather than negotiate around it, rebuilt on the integration-layer approach, and from then on legal reviewed architecture sketches before anything was built.

Obstacle

The portal team's change-control board met monthly, and the first event-emission ticket missed the cutoff by two days, threatening the engagement's timeline.

Handled: We drafted the resubmission with the board's own template pre-filled — risk assessment, rollback plan, test evidence — and it passed without amendment at the next sitting.

How we worked together

Cadence
A weekly 30-minute call with the marketing lead; legal joined three times at fixed review points; the portal team's change-control board set the only hard calendar in the engagement.
Client side
The marketing lead owned definitions and dashboards; legal owned the refusal policy; the portal team's integration engineer implemented the event emissions inside their own process.
Decisions
Event definitions were settled between marketing and us; anything touching the refusal rules needed legal's written approval, which we requested as one consolidated list to save review cycles.
They provided
Integration-layer access for the portal team's engineer, ad-platform export history for baseline context, legal's review time, and patient-free sandbox bookings for funnel testing.

What changed

The headline: campaign-to-consultation funnel measurable with the de-identification policy in forceFrozen measurement → governed funnel, read from Policy document + funnel reports. A second check: policy violations logged since the tagging layer went live at 0.

Marketing started proposing funnel improvements again — the frozen vocabulary thawed, and the first experiment in over a year shipped within a month of handover. Legal's posture changed from blanket prohibition to auditing a policy, which is a role they can sustain. The portal team, initially wary of anything touching their perimeter, ended the engagement owning the event emissions as ordinary work in their own backlog. The organization gained something it had never had: a funnel number both marketing and legal will defend in the same meeting.

The result was read from Policy document + funnel reports against the pre-engagement baseline over the stated window, with a guardrail check on policy violations logged since the tagging layer went live. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

  • The one-page measurement policy — collection, refusal, approvals — signed by legal and marketing.
  • The de-identification allowlist with the log format that proves violations absent.
  • The server-side container and its refusal layer, with change requests routed through the documented process.
  • Funnel reports in GA4 built only from allowlisted anonymous events.
  • A change-request template pre-filled for the portal team's change-control board.

What we would do differently

We would involve legal in week one, not week three — their two structural requirements shaped the whole design, and three weeks of work preceded them.

Analytics & CROGoogle Tag ManagerTelehealthGoogle Tag Manager (server-side)

Next case study

A cleaning franchisor separated franchisee leads from customer leads and fixed its national reporting