Introduction

You cannot make page-view fraud impossible, but you can make it expensive, noisy, and statistically unimportant. The core idea is to stop treating every request as a legitimate page view. Instead, count only events that pass a small set of quality checks, and separate analytics collection from raw traffic logging.

Count Meaningful Views, Not Every Hit

A naive counter increments on every request:

1app.get("/articles/:id", async (req, res) => {
2  await db.query("UPDATE articles SET views = views + 1 WHERE id = ?", [req.params.id]);
3  res.send("ok");
4});

That design is easy to game with refresh loops, scripts, proxies, or low-cost bot traffic. A better design is to define a view more carefully. For example:

• Only count one view per visitor per page during a cooldown window
• Ignore known bots and prefetch traffic
• Count on the server, not in the client alone
• Log suspicious events separately for later analysis

This turns page views into a business metric instead of a raw request count.

A Simple Deduplication Window

One of the most effective baseline defenses is deduplicating repeated views from the same visitor for a short period.

1import express from "express";
2
3const app = express();
4const recentViews = new Map();
5const VIEW_WINDOW_MS = 5 * 60 * 1000;
6
7function makeKey(req) {
8  const ip = req.ip ?? "unknown";
9  const agent = req.get("user-agent") ?? "unknown";
10  const page = req.params.id;
11  return `${page}|${ip}|${agent}`;
12}
13
14app.get("/articles/:id", (req, res) => {
15  const key = makeKey(req);
16  const now = Date.now();
17  const lastSeen = recentViews.get(key);
18
19  if (!lastSeen || now - lastSeen > VIEW_WINDOW_MS) {
20    recentViews.set(key, now);
21    console.log("Count page view for", req.params.id);
22  } else {
23    console.log("Skip duplicate view for", req.params.id);
24  }
25
26  res.send("ok");
27});
28
29app.listen(3000);

This is only a starter example. In production, you would normally store the deduplication key in Redis or another shared store so it works across multiple application instances.

Rate Limiting and Abuse Detection

If one client generates hundreds of page requests per minute, that traffic is probably not normal human reading behavior. Rate limiting helps reduce low-effort abuse before it contaminates your numbers.

Useful signals include:

• Requests per IP over time
• Requests per user account over time
• User-agent anomalies
• Missing JavaScript or cookie support where real users normally have it
• Repeated navigation patterns with no dwell time

You do not need perfect bot detection to improve data quality. Even basic thresholds eliminate a large amount of obvious gaming.

Distinguish Raw Traffic from Trusted Analytics

A strong pattern is keeping two separate streams:

1. Raw access logs for forensic analysis
2. Sanitized analytics events for product or business reporting

That way, you never lose the original evidence, but dashboards are built from filtered data rather than untrusted requests. This makes your reporting pipeline easier to improve over time because you can reprocess history with stricter rules later.

Use Session and Behavior Signals

A real page view usually has context: navigation source, dwell time, scrolling, cookie continuity, and realistic pacing. A fraud script often lacks that context.

For example, you may choose to count a view only after one of these events:

• The page stayed open for at least several seconds
• The user scrolled or interacted
• The page was visible, not just prefetched
• A session token and CSRF-safe request pattern look normal

Be careful not to overfit the definition, because aggressive filtering can undercount legitimate low-engagement visits.

Logged-In and Anonymous Traffic Need Different Rules

For authenticated users, you have stronger identifiers such as account ID, session ID, and device history. For anonymous traffic, you may rely more on short-lived cookies, IP ranges, and request fingerprints.

Anonymous analytics are always noisier, so the goal is often "good enough to resist obvious inflation" rather than perfect identity.

Common Pitfalls

One common mistake is trying to stop all fraud in the request handler alone. Page-view quality is better treated as a pipeline problem that combines application logic, rate limiting, and analytics filtering.

Another issue is relying only on client-side JavaScript events. Those are useful, but they are easy to spoof and should not be your only source of truth.

Developers also sometimes count every refresh as a new view even when the business metric should represent distinct reading sessions. That inflates numbers without any malicious actor at all.

Finally, do not block aggressively enough that real users suffer. Captchas, hard rate limits, or intrusive checks on every article page can damage the experience more than a small amount of analytics noise.

Summary

• Preventing page-view gaming starts with defining what a real view means.
• Deduplicate repeated views within a short time window instead of counting every hit.
• Use server-side counting, rate limiting, and bot signals together.
• Keep raw logs separate from filtered analytics so you can improve rules later.
• Aim for resilient metrics, not perfect fraud elimination.