Website Tracking API: Send Events from Server or Client
A tracking API receives pageview and event data from your website. Understand the difference between client-side scripts, server-side tracking APIs, and when to use each.
Two ways to get data in. One dashboard to see it all.
Client-side scripts vs server-side tracking APIs: when to use each, and how to combine them.
Jump to section
What Is a Website Tracking API?
Every analytics tool has two sides: a tracking API that receives data, and an analytics API that lets you read it back. Most discussions focus on the analytics (read) side. This article focuses on the tracking (write) side — how data gets into your analytics tool in the first place.
A tracking API is an HTTP endpoint that accepts pageview and event data. When a visitor loads your page, something sends a request to this endpoint with information about the visit: the URL, referrer, screen size, browser, and any custom event data.
That "something" is usually a JavaScript script running in the visitor's browser (client-side tracking). But it can also be your own server sending the data directly (server-side tracking). The choice between these two approaches has major implications for accuracy, privacy, and implementation complexity.
Two APIs, Two Directions
Tracking API = write path (data flows in). Analytics API = read path (data flows out). They are separate endpoints serving opposite purposes.
Client-Side vs Server-Side Tracking
The two tracking approaches serve the same goal but work very differently under the hood.
| Aspect | Client-Side (Script) | Server-Side (API) |
|---|---|---|
| How it works | JS script in browser sends HTTP request | Your server sends HTTP request |
| Installation | Paste script tag | Write backend code |
| Blocked by ad blockers | Sometimes (depends on script domain) | Never |
| Requires JavaScript | Yes | No |
| Tracks non-JS visitors | No | Yes |
| Access to browser data | Full (screen, timezone, language) | Limited (only what server sees) |
| Latency | Minimal (async request) | Adds server processing time |
| Privacy control | Limited (browser environment) | Full (you control what is sent) |
| Best for | Pageviews, standard events | Conversions, sensitive events, bot tracking |
Client-Side Tracking: How Script-Based Tracking Works
Client-side tracking is the standard approach. You add a JavaScript snippet to your website. When a page loads, the script collects data from the browser (URL, referrer, screen size, language, timezone) and sends it to the tracking API endpoint.
This is how Copper Analytics, Plausible, Fathom, and GA4 all work by default. The script handles everything: pageview detection, SPA navigation tracking, and custom event collection.
The main limitation is ad blockers. Some ad blockers and privacy extensions block requests to known analytics domains. The impact varies: typically 5-15% of visitors use ad blockers, though it can be higher on developer-focused sites.
<!-- Copper Analytics: <1KB, cookieless, auto-tracks pageviews -->
<script defer data-domain="yoursite.com" src="https://copperanalytics.com/track.js"></script>Bring External Site Data Into Copper
Pull roadmaps, blog metadata, and operational signals into one dashboard without asking every team to learn a new workflow.
Server-Side Tracking: Sending Data from Your Backend
Server-side tracking bypasses the browser entirely. Your server makes an HTTP POST request to the analytics tracking endpoint whenever a relevant event occurs. This is immune to ad blockers because the request never touches the visitor's browser.
The trade-off: you lose browser-level data like screen size, timezone, and JavaScript-dependent metrics. You also need to write backend code to format and send the tracking request, which is more work than pasting a script tag.
Server-side tracking is most valuable for high-accuracy conversion tracking, bot detection, and privacy-sensitive events where you want full control over exactly what data leaves your server.
When Server-Side Wins
Use server-side tracking for conversions (signups, purchases) where 100% accuracy matters. A missed conversion due to ad blocking is a missed data point you cannot recover.
const axios = require("axios");
// Send a conversion event from your server
await axios.post("https://copperanalytics.com/api/track", {
domain: "yoursite.com",
name: "signup",
url: "/register",
referrer: req.headers.referer || "",
props: { plan: "pro" },
}, {
headers: { "Content-Type": "application/json" },
});The Hybrid Approach: Best of Both Worlds
Most sophisticated analytics setups use a hybrid approach: client-side tracking for standard pageviews and browser events, server-side tracking for conversions and sensitive actions.
This combination gives you the richness of browser data (screen size, timezone, SPA navigation) for general analytics, plus the reliability of server-side tracking for the events that matter most to your business.
Hybrid Tracking Strategy
Client-Side (Script)
Pageviews, scroll depth, time on page, referrer data, device/browser info, SPA navigation, custom UI events (button clicks, form interactions).
Server-Side (API)
Signups, purchases, subscription changes, API key creation, payment events, bot detection, any event where 100% accuracy is critical.
The hybrid approach is only possible with analytics tools that support both a client-side script and a server-side tracking API. Copper Analytics, GA4, and PostHog all support this. Simpler tools like Plausible and Fathom are client-side only.
Copper Analytics Tracking: Client and Server
Copper Analytics supports both tracking methods. The client-side script handles standard pageview tracking with zero configuration. The server-side tracking API accepts custom events for cases where you need ad-blocker resistance or backend-only data.
Both methods feed into the same dashboard. You see client-tracked pageviews and server-tracked conversions in a unified view, without needing to merge data from separate sources.
<1KB
Client-side script
POST
Server-side endpoint
Unified
Single dashboard
Free
Both methods on all plans
Track from Client, Server, or Both
Copper Analytics: <1KB client script + server-side tracking API. Unified dashboard. Free on all plans.
Frequently Asked Questions
What is a website tracking API?
An HTTP endpoint that receives pageview and event data from your website. It is the write path of analytics — data goes in through the tracking API and comes out through the analytics (read) API.
What is the difference between client-side and server-side tracking?
Client-side tracking uses a JavaScript script running in the visitor's browser. Server-side tracking sends data from your backend server directly. Client-side is simpler to implement and provides richer browser data; server-side is more reliable and immune to ad blockers.
Can ad blockers block analytics tracking?
Client-side tracking can be blocked by some ad blockers and privacy browser extensions, typically affecting 5-15% of visitors. Server-side tracking bypasses ad blockers entirely because the requests originate from your server, not the visitor's browser.
Should I use client-side or server-side tracking?
Both, ideally. Use client-side for pageviews and standard browser events (easy, rich data). Use server-side for conversions, purchases, and critical events where 100% accuracy matters and ad-blocker immunity is valuable.
Does Copper Analytics support server-side tracking?
Yes. Copper provides both a sub-1KB client-side script for pageviews and a server-side HTTP tracking endpoint for custom events. Both feed into the same unified dashboard. Available on all plans including free.
What to Do Next
The right stack depends on how much visibility, workflow control, and reporting depth you need. If you want a simpler way to centralize site reporting and operational data, compare plans on the pricing page and start with a free Copper Analytics account.
You can also keep exploring related guides from the Copper Analytics blog to compare tools, setup patterns, and reporting workflows before making a decision.