Client-Side vs Server-Side Analytics: The Healthcare Decision

Two Architectures, Two Completely Different Risk Profiles

On the surface, client-side and server-side analytics answer the same question: what are visitors doing on your website? Both collect pageviews, track events, measure conversions, and generate reports. A VP of marketing looking at the dashboard sees similar charts regardless of which architecture powers them.

Underneath those dashboards, the two approaches are as different as sending a patient's medical chart through the public mail versus handing it to a courier with a signed chain-of-custody form. One exposes data to every intermediary along the way. The other ensures it never leaves controlled hands.

For most industries, the distinction is a technical preference. For healthcare, it is the line between compliance and a multimillion-dollar enforcement action. Every one of the 15 major tracking technology cases totaling $193M+ in settlements since 2023 involved client-side analytics. Not one involved a properly implemented server-side architecture.

How Client-Side Analytics Actually Work

When your website uses client-side analytics, this is the sequence of events that occurs each time a patient visits your site.

The patient's browser loads your webpage. Embedded in the page is a JavaScript snippet, a tracking pixel, or a tag manager script that instructs the browser to load additional code from a third-party domain. That domain might be googletagmanager.com, connect.facebook.net, script.hotjar.com, or any of dozens of other analytics and advertising platforms.

The patient's browser obeys. It reaches out to the third-party server, downloads the tracking code, and executes it. The code monitors the patient's behavior: pages viewed, buttons clicked, forms started, scroll depth, time on page. It packages this behavioral data with identifying information: the patient's IP address, device fingerprint, browser cookies, and sometimes email addresses or other identifiers passed through the data layer.

Then the code sends all of this data from the patient's browser directly to the third-party's servers. Google's servers. Meta's servers. Hotjar's servers. The data travels through the open internet, from the patient's device to infrastructure the healthcare organization does not own, does not control, and often cannot audit.

The healthcare organization's server never sees this data flow. It happens entirely between the patient's browser and the third party. The marketing team may not know exactly what data is being collected. The compliance team may not know the data flow exists. And the patient almost certainly does not know that their visit to the "Depression Treatment Options" page was just transmitted to Facebook.

How Server-Side Analytics Change the Architecture

Server-side analytics reroute the entire data flow. Instead of the patient's browser communicating with third parties, all data collection happens at the server level.

The patient's browser loads your webpage from your server. The server captures the pageview, the event, or the conversion at the point of delivery. No third-party JavaScript is loaded in the browser. No tracking pixels fire. No requests leave the patient's device for any domain other than yours.

The data sits on your infrastructure. From there, your server decides what to do with it. It can send aggregated, stripped, consent-verified data to Google Ads for campaign optimization. It can pass anonymized conversion signals to Meta through a server-to-server connection. It can route analytics data to your internal dashboards. Every downstream transmission is a deliberate, controlled, auditable decision made by your systems.

The patient's browser never talks to Google. Never talks to Meta. Never talks to any third party. There is no pathway for PHI to leak because the browser, which is the leak vector in every enforcement case, has been removed from the equation.

The $47.5 Million Architecture Lesson

The distinction between these two architectures is not theoretical. It has been tested in courts and regulatory proceedings repeatedly.

Kaiser Permanente ($47.5M class action, 2025). From 2017 to 2024, Kaiser's websites, patient portals, and mobile apps used third-party tracking code that transmitted health information to Google, Microsoft, Meta, and X without member consent. The breach affected 13.4 million members across 9 states. Data included search terms, medical histories, and communications with healthcare professionals. Source

Kaiser's tracking was client-side. JavaScript on the page sent data from patient browsers to four different advertising and analytics platforms. The health system did not intend to share medical histories with Microsoft or X. But client-side architecture does not require intent. It requires only that the tracking code is present. The code does what it was built to do.

Sutter Health ($21.5M class action, 2025). Sutter Health implemented Google Analytics, the Meta Pixel, and other advertising tracking tools on its MyHealthOnline patient portal. These tools tracked and disclosed private patient data to Google and Facebook without authorization, covering California residents from June 2015 through March 2020. Source

Sutter's case is notable because the tracking was on a patient portal, a space where every interaction is inherently health-related. Client-side analytics on a patient portal means every login, every page navigation, every action transmits data to third-party servers. Server-side analytics on the same portal would capture identical behavioral data for the health system's own use without any third-party transmission through the browser.

What Each Architecture Means for Compliance Requirements

The choice between client-side and server-side analytics affects every compliance pillar.

BAA coverage. Client-side analytics tools process PHI on the third party's infrastructure. Those vendors need BAAs. Most major analytics platforms (Google Analytics, Hotjar, Meta Pixel) do not sign BAAs that cover marketing data. Server-side analytics process data on your infrastructure first, meaning BAA requirements only apply to the downstream destinations you choose to send data to, and you control what data reaches them.

SOC 2 scope. With client-side tools, you depend on the vendor's security practices for data in transit and at rest on their servers. With server-side architecture, your own SOC 2 certification covers the primary data processing. Any platform that receives downstream data should maintain SOC 2 Type II with all five trust criteria (Security, Availability, Processing Integrity, Confidentiality, and Privacy), but your exposure is limited to what you deliberately send.

Consent enforcement. Client-side consent mechanisms (cookie banners, JavaScript consent checks) are notoriously unreliable. Scripts can load before consent is granted. Consent state can be lost between page loads. Ad blockers can interfere with consent management platforms. Server-side consent gating verifies consent status before any data is processed or transmitted. The data simply does not move until consent is confirmed at the server level.

Ongoing monitoring. Client-side tracking surfaces change constantly. Marketing teams add scripts. Tag managers load new tags. Plugins update and introduce new tracking. A web scanner that continuously monitors your website can detect unauthorized client-side scripts, but the fundamental vulnerability remains: any JavaScript on the page can send data anywhere. Server-side architecture eliminates this attack surface because the browser has no third-party communication channels to exploit.

The Data Quality Advantage of Server-Side

Healthcare organizations considering server-side analytics often focus on compliance. But the data quality benefits are equally significant.

Client-side analytics are increasingly degraded by ad blockers, browser privacy features, and cookie restrictions. Ad blockers strip tracking scripts for 30% to 40% of desktop visitors. Safari's Intelligent Tracking Prevention limits cookie lifetimes. Firefox blocks known trackers by default. The result is that client-side analytics show an incomplete, distorted picture of actual website traffic.

Server-side analytics are immune to these limitations. Data collection happens at the server level, before the page reaches the browser. Ad blockers have nothing to block. Browser privacy features have nothing to restrict. Server-set cookies are not subject to ITP limitations. The result is more complete, more accurate data.

For healthcare marketing teams making decisions about service line investment, campaign budget allocation, and market expansion, the difference between 60% data accuracy and 95% data accuracy translates directly into better decisions.

Making the Transition

Moving from client-side to server-side analytics is not a one-afternoon project. It requires changes to your data collection layer, your tag management approach, and your vendor relationships. But the process is well-understood and the tools exist.

Audit your current tracking surface. Before you can move to server-side, you need to know what client-side tracking exists on your site today. A comprehensive audit identifies every script, pixel, cookie, and localStorage entry across every page. This is the baseline that tells you what needs to be replaced.

Implement server-side data collection. Replace client-side tracking scripts with server-side event capture. This typically involves a first-party data collection endpoint on your domain that receives event data and routes it to your analytics platform through server-to-server connections.

Gate downstream transmission on consent. Build consent verification into your server-side data pipeline. Data enters your system freely (you need analytics to function), but it only flows to downstream destinations (ad platforms, email tools, analytics dashboards) after the patient's consent status has been verified server-side.

Monitor for regression. The biggest risk after migrating to server-side is that someone on the team adds a client-side script "just for this one campaign." Continuous monitoring ensures that your compliant architecture stays compliant.

FAQ

Is Google Analytics client-side or server-side?

Standard Google Analytics (GA4) is client-side. It loads JavaScript from Google's domains in the visitor's browser, which collects data and sends it to Google's servers. Google does offer a server-side tagging option through Google Tag Manager server containers, but even with server-side GTM, the data ultimately flows to Google's infrastructure. For healthcare organizations, the question is whether Google receives any data that constitutes PHI, and whether a BAA covers that data flow.

Does server-side analytics mean I lose real-time reporting?

No. Server-side analytics can process events in real time. The data flow is server to analytics platform rather than browser to analytics platform, but the latency difference is negligible. Most server-side implementations deliver data to dashboards within seconds, comparable to client-side tools.

Can I use both client-side and server-side analytics together?

Technically yes, but for healthcare organizations, running client-side analytics alongside server-side creates the same compliance exposure you are trying to eliminate. If a single client-side tracking pixel remains on your site, it can transmit PHI to a third party regardless of how well your server-side architecture is built. The compliant approach is to fully replace client-side tracking with server-side collection.

How much does server-side analytics implementation cost compared to client-side?

Server-side analytics requires infrastructure (servers, data pipelines, first-party domains) that client-side tools provide for free. The cost is higher, but the comparison is misleading. Client-side analytics are "free" because you pay with your data: the vendor monetizes the information you send them. For healthcare organizations, the true cost of client-side analytics includes the compliance risk, which, as $193M+ in settlements demonstrates, far exceeds the infrastructure cost of server-side.

What happens to my historical analytics data if I switch to server-side?

Your historical data in client-side platforms (Google Analytics, etc.) remains accessible. The transition creates a break in your data continuity: new server-side data will show different (typically higher) traffic numbers than your historical client-side data showed for the same pages. Plan for a transition period where you document the measurement methodology change so that year-over-year comparisons account for the shift.

The architecture of your analytics determines both your compliance posture and the quality of your data. Ours Privacy provides server-side analytics infrastructure built for healthcare, delivering complete data without the compliance risk of client-side tracking.

Related reading:

• What Is Server-Side Tracking? A Guide for Healthcare Marketers

• What Is a Tracking Pixel? Why Healthcare Websites Should Remove Theirs

• Server-Side vs Client-Side Tracking: Why Healthcare Can't Use Pixels Anymore

• HIPAA-Compliant Tools