Server-Side vs Client-Side Tracking for Indie Devs

Client-side tracking runs a script in the visitor's browser; server-side tracking records events from your server, CDN or backend. Client-side gives you the richest picture of behavior (scrolling, clicks, single-page navigation, Web Vitals) but misses visitors who block scripts, roughly three in ten internet users by survey data and often more among developer audiences. Server-side sees every request and can't be blocked, but it sees less context and counts bots unless you filter them. For most indie developers the right answer is both: client-side for page behavior, server-side for the events that matter most (signups, payments) and for AI crawlers.

What is the difference between client-side and server-side tracking?

The two approaches fail in opposite places, which is why combining them works. The script misses people with blockers; the server misses what happens inside the page. Where they overlap (pageviews, referrers, UTM tags) you can compare them to measure how much each misses.

How much traffic do ad blockers hide from client-side analytics?

Survey data from GWI, published by DataReportal, put ad blocker use at about 29.5% of internet users worldwide in 2025 and somewhat higher in the US, with desktop well above mobile. Not every blocker blocks every analytics tool: uBlock Origin with the EasyPrivacy list, Brave's built-in Shields, and Firefox's strict tracking protection all target well-known analytics domains, while smaller tools and first-party setups slip through more often. Audience matters more than averages: a developer tool or a privacy-focused product can lose a much larger share than a recipe site.

Blocking is not the only client-side loss. Safari's Intelligent Tracking Prevention caps cookies set from JavaScript at seven days, so a client-side visitor ID on Safari stops recognizing returning visitors after a week. Visitors who close the tab before a deferred script loads are never counted. These effects are smaller than blocking, but they compound.

How do you measure your own block rate?

1. 1.Pick a page that is not cached at the CDN, or count at the CDN itself, so every human pageview produces a server request.
2. 2.Count server-side requests for that page over a week, filtering to HTML requests (Accept: text/html) from real browsers: exclude known bots, prefetches (Sec-Purpose: prefetch) and your own uptime checks.
3. 3.Count client-side pageviews for the same page and window in your analytics tool, with bot filtering on.
4. 4.The gap, as a share of the server count, is your approximate loss: (server − client) / server.
5. 5.Repeat for a docs page and a marketing page. The block rate usually differs by audience, so one number for the whole site can mislead.

Expect some noise. Server counts include bots that look like browsers and that your filter misses, and client counts include SPA navigations the server never saw. The aim is an order of magnitude: 5% loss and 40% loss call for different decisions.

What does server-side tracking look like for an indie developer?

“Server-side tracking” covers three different things that are often confused:

• Request logging. Your web server, middleware or CDN records each request (path, referrer, user agent). It is the most complete count of requests and the only way to see AI crawlers, which never run JavaScript. See how to track AI crawlers.
• Backend events. Your application sends an event when something meaningful happens on the server: an account is created, a Stripe webhook confirms a payment, a trial converts. These are the events you can least afford to lose.
• Server-side tagging. A client-side tag sends data to your own server endpoint (for example server-side Google Tag Manager), which forwards it to vendors. Collection is still client-side; what moves to the server is the routing and filtering.

For an indie developer, the first two are where the value is. A backend event is a single HTTP call:

// After your database confirms the new account (server code)
await fetch("https://visitrack.app/api/track", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.VISITRACK_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    type: "event",
    visitorId: user.analyticsVisitorId ?? user.id, // ties it to earlier visits
    name: "signup",
    props: { plan: "free", method: "google" },
  }),
});

The example uses VisitTrack's server events endpoint; most analytics tools have an equivalent (GA4 calls it the Measurement Protocol). The detail that matters in any tool is the visitor ID: pass the same ID the browser script used, captured before signup or checkout, so the server event joins the visitor's earlier pageviews and inherits their source. Without it, you know a signup happened but not where it came from.

Should you proxy your analytics script through your own domain?

Serving the script and its collection endpoint from your own domain (say /stats/script.js and /stats/event, rewritten to the vendor) avoids blocklists that match on the vendor's domain. Many tools document a proxy setup, and frameworks make it a few lines: rewrites in Next.js, a Worker on Cloudflare, a location block in Nginx. Before you do it, know the trade-offs:

• The vendor now sees your proxy's IP instead of the visitor's. Unless the proxy forwards the client IP (X-Forwarded-For) and the vendor trusts it, every visitor appears to come from your hosting provider's data center: country data is wrong, and bot filters that flag cloud IPs may discard real people.
• Blockers adapt. Lists also match on script names and request patterns, so a proxy reduces blocking rather than eliminating it.
• It is a judgment call about consent. Someone running a blocker has expressed a preference. A cookieless, aggregate tool that stores nothing on the device is a much easier case to defend than routing an advertising tracker around a blocker.
• Use only what your vendor supports. A homemade proxy that the vendor's documentation doesn't describe can break attribution in ways that take weeks to notice.

Is server-side tracking more private?

Not inherently. It moves where processing happens; it doesn't change what you collect. The IP address is personal data under GDPR whether a browser script sends it or your server reads it from the request. Server-side setups can even be less transparent, because the visitor can no longer see in DevTools what is being sent where. What makes analytics privacy-friendly is the data model: no persistent cross-site identifiers, short-lived or hashed visitor IDs, no raw IP storage, aggregate reporting. Our cookieless tracking explainer covers that model, and the legal side is in Do you need a cookie banner for analytics?.

Which setup should an indie developer choose?

If you are on Next.js, the Next.js analytics guide walks through both halves, and the Next.js integration page has the minimal setup. For the business case of attributing revenue to traffic sources, which is where server-side events pay for themselves, see revenue attribution.

What does a combined setup look like?

A practical hybrid for a small SaaS fits on one page: the analytics script in your layout for pageviews, sources and engagement; a few lines of middleware forwarding user agents and paths so AI crawlers are visible; a server-side signup event sent after the account is created, carrying the browser's visitor ID; and your billing provider's webhook connected to analytics so each payment is attributed to the visitor's first touch. VisitTrack supports each of those pieces (script, crawler endpoint, server events, payment webhooks for Stripe, Polar, Lemon Squeezy, Paddle and Razorpay), but the architecture is the point, and it works with any tool that accepts server-side events.

The pattern holds up because each event is captured where it is most reliable: behavior in the browser, crawlers at the edge, conversions on the server. A blocked script then costs you some pageviews, not your signup or revenue numbers.