Server-Side Processing

1. The Server Side of Collection

The browser sends a POST /collect request containing a JSON body. On the server side, that request kicks off a multi-step pipeline before the data ever reaches the database. Each step has a specific job, and if any step fails, the pipeline must handle the failure gracefully without leaking information back to the client.

The 204 No Content response is intentional. The server confirms receipt without sending a response body. This is the standard pattern for analytics endpoints — there is nothing useful to return to the client, and a smaller response means less bandwidth and faster completion.

2. GET vs POST for Analytics

Analytics data can theoretically be sent via either HTTP method, but the choice has real consequences for security, capacity, and correctness.

GET is the legacy approach. The classic tracking pixel pattern (<img src="/track.gif?page=/about">) uses GET because it requires no JavaScript. It still works and has its place (email tracking, noscript fallbacks), but it cannot carry rich payloads.

POST is the modern standard. It supports structured JSON bodies, carries no size constraints from the URL, keeps data out of server access logs, and is semantically correct — you are submitting data, not requesting a resource. navigator.sendBeacon() uses POST exclusively.

3. CORS Configuration

In a typical analytics setup, the collector script runs on yoursite.com but sends beacons to analytics.yoursite.com or a completely different domain. The browser's Same-Origin Policy blocks these cross-origin requests unless the server explicitly allows them via CORS (Cross-Origin Resource Sharing) headers.

The Headers You Need

Access-Control-Allow-Origin: https://yoursite.com
Access-Control-Allow-Methods: POST, OPTIONS
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 86400

The Preflight Problem

When the browser sends a POST with Content-Type: application/json, it is a "non-simple" request. The browser automatically sends an OPTIONS preflight request first to ask the server for permission. Your endpoint must handle both:

sendBeacon and preflights: If you send a beacon with Content-Type: text/plain instead of application/json, the browser treats it as a "simple" request and skips the preflight. This halves the number of requests but means you must parse the body manually on the server. Many production collectors use this trick for performance.

4. Validation & Sanitization

Analytics beacons arrive as user-supplied input. An attacker can craft any payload they want using curl, browser DevTools, or a script. If you blindly store this data and later display it in a dashboard, you have a stored XSS vulnerability.

The Validation Pipeline

What to Validate

5. Server-Side Enrichment

The client can tell you what page the user is on and what their viewport size is. But some data can only come from the server, and some data the server should override because the client cannot be trusted to provide it accurately.

What the Server Adds

Privacy Considerations

Storing raw IP addresses raises privacy concerns (GDPR, CCPA). A common approach is to hash the IP with a daily rotating salt, producing a consistent identifier for sessionization without storing the actual IP:

// Node.js
const crypto = require('crypto');
const dailySalt = getDailySalt(); // rotates every 24 hours
const userHash = crypto
  .createHash('sha256')
  .update(clientIP + userAgent + dailySalt)
  .digest('hex')
  .substring(0, 16);

// PHP
$dailySalt = getDailySalt(); // rotates every 24 hours
$userHash = substr(
    hash('sha256', $clientIP . $userAgent . $dailySalt),
    0, 16
);

6. Sessionization

A session groups related page views and events from a single user visit. Without sessions, your analytics data is just a flat list of unconnected events. Sessions let you answer questions like "how many pages does a typical user view?" and "where do users enter and exit?"

The 30-Minute Rule

The industry standard (used by Google Analytics, Adobe Analytics, and others) defines a session as ending after 30 minutes of inactivity. If a user views a page, leaves for 25 minutes, and comes back, it is the same session. If they leave for 35 minutes, a new session starts.

Session Linking Algorithm

1. Compute user_hash from IP + User-Agent (see Enrichment above)
2. Query for the most recent event from this user_hash
3. If found and the last event was less than 30 minutes ago, reuse that session_id
4. Otherwise, generate a new session_id (UUID v4 or similar)
5. Store the session_id with the current event

First-Touch Attribution

The first event in a session carries special significance. It records:

• Landing page: where the user entered the site
• Referrer: where they came from (search engine, social media, direct)
• Session start time: used for duration calculations

7. Batch vs Real-Time Ingestion

Once beacons are validated, enriched, and sessionized, they need to be inserted into the database. There are two fundamental strategies, each with distinct tradeoffs.

Real-Time (Insert Per Beacon)

Each incoming beacon triggers an immediate INSERT statement. Data is available in the database within milliseconds of the event occurring.

Batch (Buffer and Bulk Insert)

Beacons are accumulated in an in-memory buffer (or a file queue) and flushed to the database periodically (e.g., every 5 seconds or every 100 records).

8. Error Handling

Your analytics endpoint will encounter errors: malformed JSON, unexpected field types, database connection failures, disk full conditions. The way you handle these errors matters for both reliability and security.

The Golden Rule: Always Return 204

Regardless of what happens internally, your /collect endpoint should return 204 No Content to the client. Never return error details.

Why Not Return Error Codes?

• Information leakage: A 400 Bad Request tells an attacker their payload was rejected, helping them refine their attack. A 500 Internal Server Error reveals your server is struggling.
• Client cannot act on errors: The browser's sendBeacon does not expose the response status code to JavaScript. Even fetch-based collectors typically ignore the response. There is no point returning errors the client will never read.
• Retry storms: If you return 500 and the client retries, a database outage becomes a traffic multiplier. Returning 204 prevents cascading failures.

9. Dual Implementation: Node.js & PHP

The tutorials in this section provide both a Node.js (Express) and a PHP (PDO) implementation of the server-side processing pipeline. Both cover the same logic: receive, validate, enrich, sessionize, and store analytics beacons.

You do not need to build both. Choose the language that matches your stack — or build both to compare the execution model differences firsthand. The Node.js endpoint demonstrates the event-loop / long-running process model, while the PHP endpoint demonstrates the start-process-die model. Both are valid architectures for analytics ingestion.

Tutorial Modules