Glossary8 min readUpdated May 1, 2026

What Is Server-Side Analytics? (vs Client-Side)

A clear 2026 explainer of server-side analytics, how it differs from client-side tracking, and when each approach makes sense for modern web applications.

what is server-side analyticsserver-side trackingclient side vs server side analyticsserver-side gtagserver-side tracking guide

TL;DR

1.Server-side analytics fires tracking events from your server, not from the visitor's browser. Client-side does the opposite.
2.Pros of server-side: not blocked by adblockers, more reliable, better for sensitive data. Cons: misses bot filtering, more setup, doesn't see browser metrics.
3.Pros of client-side: easier setup, captures browser metrics (vitals, scroll, clicks). Cons: blocked by adblockers, drops 10–30% of EU traffic on consent.
4.For most marketing-site analytics, client-side privacy-friendly tools are the right default.
5.A hybrid stack — client-side for visitor analytics + server-side for revenue/conversions — is the modern best practice.

The core difference

Client-side analytics: a JavaScript snippet runs in the visitor's browser. The browser sends the tracking request.

Server-side analytics: when a request hits your application server, your server sends a tracking event to the analytics provider.

These approaches measure different things. Most modern stacks use both — client-side for visitor analytics, server-side for revenue and high-value conversions.

How client-side tracking works

You install a JavaScript snippet in your <head>. When the browser loads a page, the script runs, gathers context (URL, referrer, user-agent), and sends a request to the analytics server.

This captures everything the browser knows: page URL, referrer, screen size, web vitals (LCP, CLS, INP measured live), scroll, clicks. It also naturally filters bots — most bots don't execute JavaScript.

Downsides: ad blockers can prevent the request from reaching the server. Cookie consent in the EU adds friction. The script adds page weight (45 KB for GA4, 1–2 KB for cookieless tools).

How server-side tracking works

When a request hits your server, your server-side code fires an analytics event.

Pros: not blocked by adblockers, reliable for high-value events you can't afford to miss (purchases, signups), better for sensitive data.

Cons: doesn't capture browser metrics (LCP is a browser concept), more code to maintain, requires a session/visitor identifier passed from the client.

Server-side analytics in Node.js (example)

import { sleekServerSide } from '@sleek/server'

app.post('/checkout/complete', async (req, res) => {
  const order = await processOrder(req.body)

  await sleekServerSide.track({
    event: 'purchase',
    visitor_id: req.session.visitor_id,
    properties: {
      order_id: order.id,
      value: order.total,
      currency: 'usd',
    },
  })

  res.redirect('/thank-you')
})

When to use client-side

Most marketing-site analytics — pageviews, top pages, sources, devices, real-time
Web vitals tracking (LCP, CLS, INP) — only measurable client-side
Scroll depth, time on page, click tracking
Mobile vs desktop conversion analysis

When to use server-side

Revenue and purchase tracking — don't want adblockers to break this
Conversion events from authenticated users
Data for ad-platform attribution (Facebook CAPI, Google Enhanced Conversions)
High-stakes events you need 100% accuracy on

Why server-side isn't a silver bullet

Bot filtering becomes harder. Server-side tools see every request — you have to filter bots yourself.

You lose browser-level signals — LCP, CLS, INP, scroll, click events.

You need a way to correlate visitor IDs across requests, often re-introducing cookies or session storage.

GDPR/ePrivacy consent still applies if you store identifiers.

warning:A common myth: "Server-side tracking is GDPR-compliant by default." This is wrong. If you're tracking individual users with a stable identifier, you're processing personal data — server-side or not — and GDPR consent rules apply.

Server-side Google Tag Manager

Google offers Server-Side Tag Manager (sGTM), a way to deploy tracking through a server you control. It's sometimes pitched as "GDPR-compliant GA4" — but several EU DPAs have indicated that the underlying transfer to Google's US infrastructure remains the legal problem.

sGTM has legitimate uses but isn't a privacy-compliance shortcut.

A modern hybrid stack

Each tool does what it's good at. The data quality is much better than picking one approach for everything.

Client-side: Sleek for marketing-site analytics — pageviews, sources, real-time, web vitals.
Server-side: Stripe webhook + Sleek server-side for revenue tracking.
Server-side: Conversion API integrations (Facebook CAPI, Google Enhanced Conversions).
Client-side: PostHog for in-app product analytics.

Frequently asked questions

What's the difference between server-side and client-side analytics?

Client-side fires from JavaScript in the browser; server-side fires from your server. Client-side captures browser metrics and naturally filters bots, but is blocked by adblockers. Server-side is more reliable for high-stakes events but misses browser-level signals.

Is server-side analytics GDPR compliant by default?

No. Server-side tracking still processes personal data if you're tracking individual users with stable identifiers. GDPR consent rules apply regardless of whether the request originates from the browser or your server.

Can server-side analytics bypass adblockers?

Yes for the analytics call itself — server-to-server can't be intercepted. But adblockers also block the client-side script that would set up the visitor session, breaking the connection between web visit and conversion event without careful first-party-cookie configuration.

Should I use only server-side analytics?

Probably not. Pure server-side misses browser-level metrics (web vitals, scroll, clicks) and is more complex to set up. Modern best practice: hybrid client-side + server-side.

Does Sleek support server-side tracking?

Yes. Sleek's server-side SDK lets you fire events from your server when a high-value action happens. Pair it with the client-side snippet for full coverage.

Is Server-Side Google Tag Manager (sGTM) GDPR-friendly?

Not automatically. sGTM lets you route data through your own server, but if the destination is Google Analytics, the underlying US-data-transfer issue remains.

Track your own growth loop

Sleek Analytics gives you visitors, sources, pages, devices, and real-time behavior with one lightweight script. No cookies, no GDPR banners.

Get Started Read the docs →