Server-side vs client-side analytics for the AI era
Major AI crawlers, including GPTBot, ClaudeBot, and PerplexityBot, render no JavaScript at all (Vercel, 2024). That single fact decides this whole debate. Client-side analytics runs as a script in the visitor's browser, so a visitor that never runs a browser is invisible to it. Server-side analytics measures the request itself, before any script could fire. This guide compares the two approaches, where each one wins, and why the agent era tilts the answer toward the server.
Key takeaways
- Client-side analytics fires only when a real browser executes JavaScript, and the largest AI crawlers run none of it (Vercel, 2024), so they leave no trace in browser-based tools.
- In 2025, bots generated about half of all HTML page requests and overtook human traffic for the first time (Cloudflare, 2025).
- Even for humans, client-side analytics undercounts: roughly a third of US users run a tracker blocker, and Safari caps script-set cookies at 7 days.
- Server-side analytics sees every request, human or agent, but it cannot watch in-page behavior. Most serious sites run both, with the server as the foundation.
What is the difference between server-side and client-side analytics?
The difference is where the measurement happens. Client-side analytics runs a JavaScript tag inside the visitor's browser, and that tag reports back only after the page loads and the script executes. Server-side analytics records each request as it arrives at your server, before a single line of browser code runs. One watches the browser. The other watches the request.
That sounds like a small architectural choice, but it decides what you can and cannot see. A browser tag is great at watching what a person does on a page: scrolls, clicks, rage-taps, form fields. The server sees none of that detail, because the body of the visit happens far away in someone's browser. The server sees something the tag never can: every visitor, including the ones with no browser at all.
For years that gap did not matter much, because almost every visitor was a person with a browser. The agent era broke that assumption. For the bigger picture, see analytics for AI agents.
Why can't client-side analytics see AI agents?
Because most AI agents never run a browser, and a tag that needs a browser cannot fire without one. In a study of roughly 569 million crawler fetches, Vercel found that the major AI crawlers execute no JavaScript whatsoever (Vercel, 2024). GPTBot downloads JavaScript files just 11.5 percent of the time and never runs them. To a browser tag, these visits simply never happened.
This is the part teams find hardest to accept. You can install every client-side tool on the market and still see exactly zero of the headless crawler traffic. The tools are not broken. They are working as designed, and the design assumes a browser. When the assumption fails, so does the measurement.
According to Vercel's 2024 crawler study, the major AI crawlers run on a network like Vercel's render no client-side JavaScript, while Googlebot, Gemini, and Applebot do render pages. So your analytics gap is not uniform. The classic search engines may show up; the newest AI readers usually will not. That split is exactly why traditional dashboards feel half-blind right now. We unpack the mechanism in why traditional analytics can't see AI agents.
Server-side vs client-side: a side-by-side comparison
The two methods are not rivals so much as different instruments. Here is how they line up on the dimensions that matter in 2026, when bots make up about half of HTML requests (Cloudflare, 2025).
| Dimension | Client-side (browser tag) | Server-side |
|---|---|---|
| Sees AI crawlers and fetchers | No, they run no JavaScript | Yes, every request is logged |
| Survives ad and tracker blockers | No | Yes, there is no script to block |
| Cookie life under Safari ITP | 7 days for script-set cookies | Full lifetime via server header |
| In-page behavior (scroll, clicks) | Yes, its core strength | No |
| Page performance cost | Adds to browser load | None on the client |
| Setup | Add a tag to every page | Add middleware once |
Read the table as a division of labor, not a winner. The server owns coverage: who arrived, what they asked for, what you served. The browser owns behavior: what a person did once the page was in front of them. The mistake is treating a behavior tool as if it measured coverage. It never could.
What does client-side analytics miss, even for humans?
More than most owners expect, and not only the agents. Around a third of US internet users run an ad or tracker blocker, and many of those tools strip analytics scripts before they load (Backlinko, 2026). Those are real human visits that your browser tag silently drops. The headless agents are the dramatic blind spot, but human under-counting was already baked in.
Browser privacy defaults widen the gap. Safari's Intelligent Tracking Prevention caps cookies set by JavaScript at seven days, so a returning visitor often looks brand new (Snowplow, 2023). A cookie set by your server in the HTTP response is not subject to that cap. Same visitor, very different accounting, depending only on where the cookie was written.
None of this is a scandal. It is the predictable result of measuring from inside a browser that is increasingly built to resist measurement. The server sits upstream of all of it.
What does client-side analytics still do better?
It is the only place to watch behavior inside a page, and that is genuinely valuable. A browser tag can record how far someone scrolled, which button they hovered, where a form lost them, and how a session flowed from click to click. The server cannot see any of that, because once it hands over the page, the action moves to the visitor's device.
So the honest answer is that client-side analytics is not obsolete. If your question is "what did this person do on this screen," the browser is the right instrument, and a server log will not help you. Product teams optimizing a checkout funnel still reach for client-side events, and they should.
The trap is using that instrument to answer a different question. "How much of my traffic is AI" and "which assistants cite my pages" are coverage questions, and coverage lives on the server. Pick the tool that matches the question.
What is the performance cost of client-side tags?
It is real and it has been climbing. About 90 percent of pages now load at least one third party, and scripts are the single largest category of third-party requests (HTTP Archive, 2025). Each analytics and tag-manager script is weight the browser must fetch, parse, and run before the page settles.
The aggregate cost shows up in the field. The median mobile Total Blocking Time reached 1,916 milliseconds in 2025, up 58 percent year over year, with third-party JavaScript a major contributor (HTTP Archive, 2025). Blocking time is time a person stares at a page that will not respond yet. Tags are not the only cause, but they are a cause you control.
Server-side measurement adds nothing to that budget. The work happens in your infrastructure, not on the visitor's phone, so coverage does not trade off against speed. You stop choosing between knowing your traffic and serving a fast page.
When should you use server-side, client-side, or both?
Use the server as your foundation, and add client-side where you need in-page behavior. The server is the only layer every visitor passes through, human or agent, so it is the right place to answer coverage and attribution. Bot traffic overtook human traffic in 2025 (Cloudflare, 2025), which means a browser-only setup now misses a growing majority of arrivals by construction.
For Caprail, the foundation is two lines in your middleware:
import { createCaprailMiddleware } from "@caprail-dev/analytics/next";
export const middleware = createCaprailMiddleware();That classifies every request on the server, with no tag in your visitors' browsers and no hit to your page speed. You get the live feed of agent visits, AI referral attribution, and a coverage view of which engines have read which pages. Layer a behavior tool on top when you need scroll and click detail. The point is sequence: measure who arrived on the server first, then measure what humans did in the browser second.
FAQ
Is server-side analytics more accurate than client-side?
For coverage, yes. It records every request, so it is not undercounted by ad blockers, which about a third of US users run (Backlinko, 2026), or by browser cookie limits. For in-page behavior such as scroll depth, client-side is the more accurate tool, because that detail only exists in the browser. They measure different things.
Can client-side analytics track ChatGPT or Claude crawling my site?
No. The major AI crawlers run no JavaScript (Vercel, 2024), so a browser tag never fires for them. To see GPTBot, ClaudeBot, or a live fetcher like ChatGPT-User, you have to read the request on the server, where every visit is logged regardless of whether a browser ran.
Does server-side analytics slow down my website?
No. The measurement happens in your infrastructure, not the visitor's browser, so it adds nothing to page load. Client-side tags are the opposite: scripts are the largest category of third-party requests, and median mobile blocking time rose 58 percent in 2025 (HTTP Archive, 2025).
Do I have to choose between server-side and client-side?
No, and most serious setups run both. Use the server for coverage and attribution, since it sees every visitor including agents, and add a browser tool for in-page behavior like clicks and scroll. Start with the server as the foundation, because it is the only layer that captures the AI traffic now making up half of requests.
Will server-side analytics still work after third-party cookies go away?
Yes. Server-side measurement does not depend on third-party cookies at all, and it can set first-party identifiers in the HTTP response, which are not capped the way script-set cookies are under Safari ITP (Snowplow, 2023). It is the more durable approach as browser privacy defaults keep tightening.
Conclusion
The server-side versus client-side question used to be a matter of taste. The agent era settled it. When half your requests come from bots and the fastest-growing readers run no browser at all, a measurement method that needs a browser can only ever see part of the picture. The server sees all of it.
That does not retire client-side analytics. It puts it in its proper place: the right tool for watching what humans do on a page, layered on top of a server-side foundation that actually counts who showed up. Start by making the invisible visible. Add the middleware, watch the live feed, and see the traffic your browser tag was never able to report. Then learn how to track AI referral traffic end to end. Caprail is free during the private beta, with no credit card required.
Sources
- Vercel, The rise of the AI crawler, retrieved 2026-06-15, https://vercel.com/blog/the-rise-of-the-ai-crawler
- Cloudflare, Radar 2025 Year in Review, retrieved 2026-06-15, https://blog.cloudflare.com/radar-2025-year-in-review/
- HTTP Archive, Web Almanac 2025: Third Parties, retrieved 2026-06-15, https://almanac.httparchive.org/en/2025/third-parties
- HTTP Archive, Web Almanac 2025: Performance, retrieved 2026-06-15, https://almanac.httparchive.org/en/2025/performance
- Backlinko, Ad blocker usage statistics, retrieved 2026-06-15, https://backlinko.com/ad-blockers-users
- Snowplow, How long do tracking cookies last, retrieved 2026-06-15, https://snowplow.io/blog/tracking-cookies-length