The ABCs of analytics and privacy

I'm working with an enterprise client in healthcare to rebuild their website and CMS. As part of this project, I'm also helping them figure out an analytics and measurement stack that'll do everything the marketing team needs, but within the privacy rules set down by their lawyers.

I am not an attorney, and the first takeaway I'll share here is that there is no one-size-fits-all solution for capturing and measuring user behavior while preserving privacy. (There are some one-size-fits-most options, however, which we'll get to below.) If you're located somewhere with strict privacy regulations (e.g. GDPR in the EU, or CCPA in California), or in a regulated industry like healthcare, you should consult with your privacy counsel to understand what data you're allowed to collect and where it has to live.

I'm going to focus here on the analytics tools I'm most familiar with — Google Analytics , Fathom , and (especially) PostHog . I think what I have to say can apply more broadly to other products, but YMMV — if you have some specific questions about how to measure responsibly, you should get in touch!

J is for JavaScript

Nearly all analytics tools rely on JavaScript to capture information and send it to a server for measurement, for a few reasons:

• JS code has access to more information about the user's browser/OS, viewport, etc. than is sent to servers as part of a normal web request.
• While page requests carry enough information to generate basic stats — GA itself started as log analysis, with JS tracking coming later — you need JS to capture on-page events like clicks and scrolls, and to know which elements were clicked or interacted with.
• Third-party analytics platforms like GA can be embedded in a site with a simple <script> tag, whereas server log analysis is harder to job out to an outside service and kind of a pain to do yourself.

JavaScript has been part of the web platform for over 30 years, but writing custom JS is still an intermediate-to-advanced developer skill, especially vanilla JS that doesn't rely on frameworks like jQuery or React . A surprising number of people who build websites for a living probably couldn't customize analytics events or implement a custom consent banner.

That's also to say: while these things are table stakes for many marketers, they may not be for the agencies and developers building the sites. This is especially true for agencies that work in low-code tools like Webflow or visual-builder WordPress plugins like Elementor . Potential clients should ask agencies or devs about their bona fides working with these kinds of platforms, to avoid any nasty surprises or additional costs late in a project.

C is for cookies

Browser cookies are central to a lot of analytics privacy discussions. They're the oldest and simplest way to store session state. A cookie consists of just keys and values associated with a given domain name on your browser.

When websites link to scripts or resources on some other domain, the servers hosting those resources can set and read cookies — and that's the first big privacy issue. While website owners can decide whether and how they use their own first-party cookies (set by their own servers/code), they have no control over what happens with third-party cookies.

For example, ad and retargeting trackers — Google's own advertising tags, the Meta Pixel, and the like — set cookies on their domains (doubleclick.net and friends) that they can read on any other site running the same tag, which is what lets them follow you across the web. Google Analytics is a subtler case: its measurement cookie is actually first-party — set on your domain, not Google's — but the data it collects still flows to Google for processing, which is why regulators scrutinize it like a tracker even though the cookie itself isn't third-party. A genuine first-party cookie, by contrast, can only be read on the site that set it — much less worry about cross-site tracking.

Just because a third party like Google can track what you do across websites doesn't mean that they do (though they do), or that this cross-site tracking is nefarious (it's generally used to sell ads). The point is that control over users' information is taken out of the user's hands and spread across multiple other parties.

The other big issue with third-party cookies is that many browsers or privacy extensions will block them from being set or sent at all, precisely to prevent the kinds of cross-site tracking they enable. If your analytics rely on third-party cookies, in addition to raising privacy issues you may not be getting reliable data.

Generally, any external analytics product relies on third-party cookies for the simple reason that it has to be loaded from its own domain (not yours), so any cookies it sets are gonna be third-party cookies. One solution has been self-hosted analytics, running on your own servers, so that all cookies are on your own domain (and therefore become first-party cookies). This works great, but can be expensive and requires you to run and maintain servers.

PostHog offers a great, elegant compromise in the form of managed proxies , where you can assign a first-party domain name to your analytics tracking URL hosted on PostHog's cloud service, so any cookies are first-party and therefore dodge blockers and cross-site-tracking concerns. Managed proxies used to be a paid enterprise feature, but earlier in 2026 the company started offering it to all Cloud users at no charge.

C is also for 'consent', 'control', and 'code'

You've surely seen those annoying cookie consent banners that have spawned all over the internet since GDPR went into effect in 2018. These range from simple notifications, telling you cookies are in use, to elaborate privacy-preference sidebars that let you choose what data is tracked on a granular level.

Consent management consists of both these notification bars and the code that ensures your website honors the user's privacy requests. If you tell a site to Decline All Cookies, the site needs to not set any cookies, and/or delete any that may have been set on the first page load before consent was granted.

This is relatively simple for first-party cookies, but more involved for third-party ones. Because you, the site owner or developer, don't control when or how a third party sets cookies, a consent banner needs to control both your own cookie-setting behavior and whether third-party cookie-using trackers are loaded on your site at all.

For a host of reasons I won't get into here, effective analytics tracking requires loading a (usually quite small) JavaScript tracker onto your page. A page that doesn't bother with consent can just toss some tracking codes on and be done with it; this will often work even on no-code or low-code platforms like Webflow or Squarespace .

Sadly, there's no non-JavaScript, HTML-only way to control whether first- or third-party scripts load onto a page — the only way to manage how JavaScript loads is more JavaScript.

To effectively manage consent, a web page needs to build its analytics setup around its consent-management UI and logic, like so:

• First, to be safe, developers should avoid setting any cookies on the server side, so that the JavaScript-powered consent banner can do its work. (It's generally OK for the server to read cookies once set, and probably fine to update cookies that are already present.)
• On first page load, the site avoids loading any resource that would set a first- or third-party cookie until the consent banner is shown and responded to.
• If the user allows cookies, the dialog saves that preference to the browser's local storage — another way of storing state that's browser-only and more strictly private, but less versatile than cookies — and your site code can then load whatever cookie-using tracking codes you need.
• If the user rejects cookies, that preference is saved to local storage, and trackers are not loaded.

Any functions or events in your website code need to be designed so they work even when analytics code isn't present. The method varies by tool. PostHog — my favorite platform — supports both autocapture for clicks and pageviews and explicit events via posthog.capture() . If analytics are disabled, autocapture simply won't happen, but any code that calls posthog functions needs to check whether posthog is defined before submitting events — otherwise it'll throw errors and break your site.

F is for 'fingerprint'

JavaScript has access to more private and granular information about you and your computer than a web server does (which is why tracking codes rely on JS). But to identify a user, an analytics platform doesn't need any of that — it just needs a way to tell one visitor from another. The usual approach is to generate a random unique identifier and store it in a cookie, so the platform can group a user's events (clicks, page views, etc.) together, count unique visitors correctly, and track things like conversion funnels.

That stored identifier is one way to fingerprint a user. The other — which we'll get to below — is to derive an identifier from the characteristics your browser exposes, no cookie required. Either way, a digital fingerprint, like the IRL ones on our hands, doesn't contain any private information about who we are; its job is just to tell one person apart from another. That's to say: cookies usually don't contain any personally identifiable information (PII), but because they enable tracking what you do on a site, they serve as a kind of "proto-PII." The concern isn't the cookies or fingerprints themselves, but what they enable.

W is for "what if you can't use cookies"

This is ultimately the several-hundred-thousand-dollar question for clients who risk litigation or sanctions for not taking privacy seriously: if you can't use cookies, or users decline them, what then?

Many mainstream analytics products like Google Analytics don't offer a cookie-less alternative; if users have declined cookies, you simply shouldn't load a Google tracking code onto your site. Conversely, if they allow cookies for tracking, Google's products should be fine as far as cookies are concerned. (If you need to comply with GDPR/CCPA, or if user data falls under another statute like HIPAA , there may be other issues to consider — when in doubt, consult your attorney.)

PostHog does have a clever cookieless mode that uses server-side fingerprinting to approximate the kind of identifier that would usually be stored in a cookie. It also offers server-side options to ignore IP addresses, which can otherwise be used to identify users and expose their location to a service.

Not using cookies or IP addresses increases the privacy guarantee for your site, but the trade-off is that your analytics will be less granular and accurate, and some metrics like unique visitors will be less reliable as a result. On the other hand, some data is better than none: if your site uses a consent banner and has a mix of opted-in and opted-out users, cookieless mode can still tell you enough about your overall user base and patterns to make good decisions.

If you can't use cookies or something like PostHog's server-side fingerprinting, there are still options.

Privacy-first measurement services like Plausible or Fathom don't store any information to identify specific users; instead they keep a running tally of how many times an event was triggered, sometimes using a looser form of server-side fingerprinting to estimate your number of unique visitors.

Additionally, several cloud infrastructure providers like Vercel , Netlify , and Cloudflare offer analytics based on server logs (sometimes with optional JavaScript trackers for more granular data) for sites hosted on their platforms.

E is for ending

Ultimately, navigating privacy-first analytics is a balancing act: the more accurately you want to track users with tools like Google Analytics, the more potential privacy and legal issues you invite, especially around third-party cookies and consent. The best solution is rarely off-the-shelf and always depends on your specific needs. Consulting your own privacy counsel remains the single most important step before choosing your measurement stack.

Once you know your requirements, consultancies like ours can help you figure out what needs to happen in code to ensure you provide a great experience while staying on the right side of the law.