Server-side Analytics vs Client-side Analytics
By Matthew Edgar · Last Updated: February 10, 2022
What are server-side and client-side analytics?
Server-side and client-side differ on what triggers the tracking.
Server-side analytics is triggered by the server. Every time a visitor requests a file from the server, an entry for that request is added to the website’s log file. The entry in the log file contains other details, like the user agent (browser and operating system details), the IP address of the person making the request, the resulting status code of the requested file, and referral data. Example: AW Stats.
Client-side analytics is triggered by the browser (the client). Every time a visitor interacts with the website, the browser fires an event. These events include page loads but can also include clicks or scrolls. Events are tracked by the analytics tool through JavaScript code. Client-side tracking can also create cookies, enabling these tools to collect more information about the people visiting the website. This allows client-side analytics to track far more data than server-side tools. Example: Google Analytics.
Advantages & Disadvantages of Server-Side Analytics
Pros
Because everything in a server-side analytics program is tracked on the server, any settings applied by visitors in the browser cannot prevent server-side analytics from tracking. More people are using ad blockers and those ad blockers can also prevent client-side analytics from being able to track visitors to a website fully and completely. As a result, server-side analytics programs can provide more reliable and complete data about the total volume of visitors reaching your website.
Along with ad blockers, there are also a growing number of legal restrictions that are being placed on the use of tracking cookies (GDPR, CCPA, etc.). These legal restrictions pose significant problems for client-side analytics programs because almost all client-side analytics programs rely heavily on cookies to collect and track data. Even if you remove cookies entirely, server-side tracking will still be able to track the basic information about the people who are interacting with a website. (There are third-party tools that work without cookies, which can be helpful but those tend to be the exception.)
Server-side analytics provides the basic information that people need about their website like the number of visits to the website, the number of pages viewed, referral sources, browsers used, and geolocations. Also, by default, server-side analytics programs track how many people interacted with PDFs or other non-HTML file types.
Along with the server-side analytics programs that rely on log file analysis to generate data, there are also ways of tracking interactions on the server through server-side programming languages. For example, every time the server-side code controlling a shopping cart processes a sale, information about that sale can be stored in a database and retrieved later in a report (this is how plugins like WooCommerce generate reports in WordPress). Like with programs that analyze log files, all interactions with these code-based server-side analytics programs happen on the server and do not depend on the browser settings or cookies. However, unlike log file analytics, code-based server-side analytics programs can quickly expand beyond the basics to track other types of interactions, as we can see in that shopping cart example.
Cons
Despite several advantages, server-side analytics can be difficult to configure and access. With most hosting companies, accessing log files is usually a more cumbersome task. Once accessed, viewing and processing the log file can require hefty computing resources to process the data, especially on larger websites. There are software programs that can make this somewhat easier but that is dependent on budget.
Of course, accessing the log files may not be possible depending on the type of website and the hosting company. Webflow doesn’t provide this information (though sometimes they do indicate you may be able to access pieces of the log file by contacting support). Other websites, like those using Squarespace, do provide access but only in a limited context for a limited timeframe that limits the deeper analysis you’d need to generate an analytics report.
Even if you can get access to and process the log file data, server-side analytics requires more work to scrub and clean the data. This is because server-side analytics tracks everything that occurs on the server—both interactions from human visitors as well as interactions from bots. Client-side analytics is subject to this problem too, though typically to a lesser extent since most bots won’t load the JavaScript required to trigger the client-side analytics program. Not sufficiently filtering away bot activity from the reports can greatly skew the data provided, giving you misleading information about a website’s performance.
While server-side analytics do not rely on cookies, there are still concerns about privacy restrictions and compliance with the related laws surrounding the storing of personal information. Server-side analytics can track IP addresses. This can be filtered out too (or not tracked entirely in a code-based analytics setup). However, if the IP address is tracked, this can be considered personally identifiable information (PII).
Advantages & Disadvantages of Client-Side Analytics
Pros
Client-side and server-side analytics will both provide the basics. However, client-side analytics allows for greater depth of tracking beyond simple pageviews or referrals by bringing in browser-based events. This can include tracking scrolling, playing videos, or tracking the usage of interactive features. In Google Analytics, this can be accomplished with event tracking, though other client-side analytics tools offer similar features.
Tracking data in the browser also opens up more possibilities for tracking goals. With server-side analytics, the only option is destination-based goals: did people visit a confirmation page? Client-side analytics can track destination-based goals too, but can also track goals related to those different ways people interact with the website. Did people use that calculator on your home page? Did people watch a video? Did people click on key external or internal links? Once those are tracked in a client-side analytics program, they can easily be converted into goals, providing a greater depth of understanding about the way people use and convert on the website.
With server-side tracking, you can only track interactions on the server that hosts the website. Log files are server-specific and do not track data across multiple websites. That means server-side tracking is first-party data. (There are exceptions when you get into code-base server-side analytics with sending data over APIs but, in general, and for log-based analytics, server-side means you are looking at data collected on your own server.) In contrast, client-side analytics can easily use third-party scripts. When you use Google Analytics, the data is tracked and stored on Google’s servers, not your own. Because of this, there are many different analytics programs and integrations available that offer client-side tracking. Most CRMs offer some type of web integration via a client-side script, as do ad platforms. This easier integration greatly expands what can be tracked about a website’s performance.
Cons
The downside, of course, of relying on third-party tools is that your reporting becomes subject to whatever the third-party tool wants to do. If suddenly that program changes the definition of a metric, that could greatly alter the way your company’s reporting works. As well, tools like Google Analytics sample data, and that sampling can lead to misleading numbers that differ from reality. GA4, the new version of Google Analytics, also shifts the way certain metrics are tracked and defined.
Using a lot of third-party tools will have an impact on your website’s total load time. The more analytics tools used, the greater the impact. Server-side analytics process the data directly on the server, which will run faster than any tracking that occurs within the browser since even the fastest client-side script will have to run on the browser, send the signal to the server, and wait for a response from the server to fully process the request. That said, Google Analytics has a relatively light footprint on most websites, especially compared to other tools. However, on Elementive’s website, Google Analytics takes about a second to load and then also loads data from other domains, which take another few seconds to load. The more third-party tools used, the bigger a problem this becomes.
Most client-side tracking scripts offer an easy way to start: just copy and paste the tracking code onto your website. However, by default, client-side scripts do not provide a wealth of information and, in many cases, don’t provide much more than server-side programs by default. For example, without additional configurations, all those events and goals will not be tracked in most client-side scripts. Related to this, client-side scripts cannot track any activity on non-HTML files (like PDFs or images). The best client-side scripts can do is track how many times people clicked on a link to open that non-HTML file. Usually, that is an acceptable proxy to true interactions but if those non-HTML files are essential for your business (like a PDF application) then a proxy metric offered by the client-side tools may not be a good enough metric to understand performance.
Which Type of Analytics Should I Use?
For critical information, you want the most accurate and complete numbers. You do not want to rely on proxy metrics or contend with sampled data. You also cannot risk an analytics tool altering how the metric is defined. Given this, server-side analytics makes the most sense for those critical numbers. This also keeps the data under your control and hosted on your server, instead of letting that data be stored in a third-party tool. While this requires work and investment on your end to configure the server-side analytics properly, the value of the data is often worth it. As an example, think about sales data for an ecommerce website—the company needs to track exactly how many orders were placed and exactly how much revenue was generated. Another example would be companies that collect leads—an approximate number of leads wouldn’t be sufficient; the company needs to know exactly how many leads were collected.
For general traffic data, where you don’t need accurate numbers but instead need to get a general sense of performance and see how the data trends over time, client-side analytics make more sense. This gives you the ability to bring in third-party tools that have various types of reports that can be used to give a wide variety of information. As an example, think about marketing campaign performance—you need to know if this week’s newsletter generated more traffic than last week and that amount of traffic needs to be pretty accurate but the exact amount of traffic isn’t so important. For any third-party tool used, it is important to make sure the impact that tool has on the website’s speed is worth the relative gain to the business from the data provided.
Important Note: Server-Side and Client-Side Analytics Won’t Match
If you end up using a mix of both types of analytics tools, as most companies will need to do, you’ll notice that the data collected won’t always match. It is common to see ecommerce websites where Google Analytics reports show a lower order volume than the server-side analytics program also tracking orders. You might even find two server-side analytics programs don’t match or two client-side analytics programs don’t match. Every analytics tool defines metrics differently, even tools of the same type.
As just one example, a pageview in a client-side analytics script is based on how many people trigger the browser’s load event while a pageview in a server-side analytics program is based on how many times the server sent the file to the browser. These are similar concepts but are different at a fundamental technical level.
Additionally, client-side and server-side analytics tools are subject to different flaws in the data. Client-side scripts will tend to do a better job filtering out bot data than server-side analytics programs but client-side scripts won’t track people who have ad blockers installed while server-side programs will. (It should go without saying that, of course, you want each analytics tool to be configured as accurately as possible despite these challenges. But, even if perfectly configured, there will be limitations within each type of analytics tool.)
Given these differences, you need to decide which tool will give you the most accurate number for each metric you care about. Once you’ve decided on that, then use that tool and only that tool for measuring that metric. To go back to the ecommerce website example, it would make sense to trust the server-side analytics program for total order volume and total revenue instead of trusting the same data as tracked in Google Analytics since the data is subject to problems of sampling and people using ad blockers. However, the order volume and total revenue data that is tracked in Google Analytics can still be useful—but not as a measure of exactly how much revenue was made or how many orders came in. Instead, the data in Google Analytics can be used to give a relative sense of order and revenue trends over time and also to see orders and revenue segmented by marketing channel.
Final Thoughts
Deciding how best to track your company’s key metrics and determining which tools to use to track those metrics is challenging. Equally, it can be challenging to overcome the limitations within each type of analytics tool. If you need help resolving issues with your analytics programs or setting up your analytics programs, please contact me, and let’s discuss your current web analytics situation.
