How to Distinguish Real Users from Scalper Bots in Flash Sale Systems

1. Core Differences Between Real Users and Scalper Scripts

Real‑User Characteristics

Random operation intervals: browsing, scrolling, pausing a few seconds, clicking, and entering captchas with millisecond‑level random delays.

Mouse or finger actions such as page scroll, clicking empty areas, switching pages, exiting and re‑entering, typing text.

Device uniqueness: one phone or computer maps to a fixed account; rarely switches many accounts in a short time.

Normal network: home broadband or 4G/5G, IP location matches the shipping address.

Account exhibits normal lifecycle behavior: regular browsing, ordering, favoriting, payment, and historical orders.

Can solve graphic captchas and SMS verification, with retries and occasional page lag.

Scalper Script / Crawler Characteristics

No operation interval; millisecond‑level loop requests with extremely high frequency and no page stay.

No front‑end interaction; directly calls backend APIs without scrolling, clicking, or dragging.

Bulk multiple accounts on a single device, logging in dozens or hundreds of accounts quickly.

Uses proxy IPs, dial‑up pools, or data‑center IPs; IP changes frequently and does not match the user's address.

Bulk registers dummy accounts with no history, zero orders, and only participates in flash‑sale events.

Automatically bypasses captchas via cracking platforms; request timing is perfectly regular.

Device information is absent; request headers, UA, and device parameters are fixed, resulting in identical fingerprints.

2. Five‑Layer Risk‑Control Interception System (From Page to Order)

First Layer – Front‑End Behavior Verification (Intercept Naked API Scripts)

Human‑Machine Behavior Data Collection

Mouse movement trajectory, click coordinates, scroll distance, page stay duration.

Click intervals, page scroll count, window switches.

Input behavior: whether the input box is touched, captcha slider dragging. Scripts generate empty or perfectly uniform data, which is blocked directly.

Dynamic Slider / Behavior Captcha (Pre‑Sale Verification)

Instead of simple numeric captchas that cracking platforms can solve instantly, use drag‑slider or trajectory captchas. Backend validates drag curve, speed, and pause points. Scripts produce straight‑line constant‑speed drags, while real users exhibit jitter, pauses, and variable speed, allowing direct discrimination.

Dynamic Encrypted Request Signature

Front‑end generates a dynamic encrypted sign based on page behavior, timestamp, and device info; the signature changes for every request. Scripts cannot reproduce a valid signature and are blocked.

Page Access Sequence Verification

Rule: users must first visit the product detail page and wait 1–8 seconds before entering the flash‑sale order page. Scripts that skip the detail page and call the order API directly are blocked.

Example Front‑End JS for Mouse Tracking and Submission

// Record mouse trajectory
let mouseTrack = [];
document.onmousemove = (e) => {
    mouseTrack.push({x:e.clientX, y:e.clientY, t:Date.now()});
};
// Submit order with behavior data
function submitSeckill() {
    const params = {
        goodsId: 10001,
        userId: "u123456",
        track: JSON.stringify(mouseTrack),
        timeGap: new Date().getTime() - pageEnterTime,
        sign: getDynamicSign()
    };
    axios.post("/seckill/submit", params);
}

Second Layer – Device Fingerprint Risk Control (Intercept Bulk‑Account Scripts)

Generate Unique Device Fingerprint ID

Front‑end collects multiple parameters and hashes them to produce a unique, non‑forgeable identifier.

Mobile: IMEI, OAID, OS version, screen resolution, kernel parameters, installed app list.

Web: Browser UA, font list, Canvas fingerprint, WebGL parameters, timezone, language, plugin list.

Mixed‑parameter hashing ensures that altering a single parameter cannot reproduce the same fingerprint, making it hard for scripts to forge the full device profile.

Device Rate‑Limiting Rules

Same device fingerprint allows at most two accounts to participate in a single flash‑sale.

Same device may issue at most five flash‑sale requests within five minutes; exceeding this adds the device to a blacklist.

New devices that have never visited the platform are restricted; only existing users can participate.

Device Blacklist Persistence

Blacklisted device fingerprints are stored in Redis. Once identified as a script device, all associated accounts are permanently blocked, with periodic cleanup for low‑risk devices.

Third Layer – Account Profile Risk Control (Intercept Bulk‑Registered Dummy Accounts)

Account Risk Scoring Model (Score < 60 → Scalper)

Deduction items (each hit reduces score):

Registration time less than 7 days, no historical orders or payment records.

No browsing, favoriting, or adding to cart; only visits flash‑sale page after registration.

Frequent device switching and IP changes in a short period.

Shipping address changes frequently, no fixed address.

Bulk registration with same phone number prefix or email suffix.

Bonus items (add points for genuine accounts):

Historical normal orders and payment records.

Long‑term browsing, interaction, and review behavior.

Fixed device, stable IP, and consistent shipping address.

Account Interception Rules

If risk score falls below the threshold, directly prohibit ordering and show “account activity restricted”.

Blank new accounts are forced to complete SMS verification; scripts cannot receive SMS, so they are naturally blocked.

Batch‑registered accounts in the same batch are marked high‑risk and their purchase quota is limited.

Fourth Layer – IP Network Risk Control (Intercept Proxy/Data‑Center Scripts)

IP Risk Determination Rules

IP belonging to a data center or cloud server is immediately marked high‑risk.

More than 10 flash‑sale requests from the same IP within one minute indicates batch scripting.

IP location frequently changes and does not match the user's shipping‑address province.

Proxy IP pools, foreign IPs, and data‑center IPs are directly blocked.

Large numbers of dummy accounts from the same IP trigger IP blacklist.

IP Tiered Handling

High‑risk data‑center IP: reject all flash‑sale requests.

Normal high‑frequency IP: limit each IP to at most three orders and add captcha verification.

Home broadband / 4G IP: allow passage with regular rate‑limiting.

Fifth Layer – Backend Request Sequence & Behavior Risk Control (Final Safeguard)

Request interval check: the same account must wait at least 300 ms between two flash‑sale requests; scripts that loop in milliseconds are blocked.

Single account is allowed only one order per flash‑sale to prevent duplicate purchases.

Overall QPS statistics: a sudden surge of massive, regular requests triggers temporary rate‑limiting.

Full request chain verification: the request must pass through product page → confirmation page → order page; skipping intermediate steps is considered a script.

Post‑order payment verification: scripts that obtain an order but never pay are marked risky; subsequent attempts are restricted.

3. Redis Multi‑Layer Risk Control Storage Architecture (High‑Concurrency Flash Sale Adaptation)

Device fingerprint rate‑limit cache: device:limit:{fingerId} records request count for the current flash‑sale.

IP rate‑limit cache: ip:risk:{ip} stores request frequency and risk level.

Account risk score cache: user:risk:{userId} caches the profile score.

Blacklist sets: black:device, black:ip, black:user for fast membership checks.

Flash‑sale behavior timeline record: user:page:time:{userId} records the time of entering the product page for interval validation.

Distributed rate‑limit counters to prevent single‑node memory cache failures.

Simple Risk Control Utility Class (Java Spring)

@Service
public class SeckillRiskControlService {
    @Autowired
    private StringRedisTemplate redisTemplate;
    private static final int DEVICE_MAX_REQ = 5; // per flash‑sale
    private static final int IP_MAX_REQ = 10;   // per minute

    // Returns true if script risk detected and order should be blocked
    public boolean isRisk(String userId, String deviceFinger, String ip, Long enterPageTime) {
        long now = System.currentTimeMillis();
        // 1. Blacklist check
        if (Boolean.TRUE.equals(redisTemplate.opsForSet().isMember("black:device", deviceFinger))
                || Boolean.TRUE.equals(redisTemplate.opsForSet().isMember("black:ip", ip))
                || Boolean.TRUE.equals(redisTemplate.opsForSet().isMember("black:user", userId))) {
            return true;
        }
        // 2. Device frequency limit
        String deviceKey = "device:limit:" + deviceFinger;
        Long deviceCount = redisTemplate.opsForValue().increment(deviceKey, 1);
        redisTemplate.expire(deviceKey, 10, TimeUnit.MINUTES);
        if (deviceCount > DEVICE_MAX_REQ) {
            redisTemplate.opsForSet().add("black:device", deviceFinger);
            return true;
        }
        // 3. IP frequency limit
        String ipKey = "ip:risk:" + ip;
        Long ipCount = redisTemplate.opsForValue().increment(ipKey, 1);
        redisTemplate.expire(ipKey, 1, TimeUnit.MINUTES);
        if (ipCount > IP_MAX_REQ) {
            redisTemplate.opsForSet().add("black:ip", ip);
            return true;
        }
        // 4. Page access interval (less than 1 s considered script)
        if (now - enterPageTime < 1000) {
            return true;
        }
        // No risk detected
        return false;
    }
}

4. Dynamic Threshold Risk Control + Gray Release to Avoid False Positives

Low‑traffic periods: relax IP and device request limits, reduce risk‑check intensity.

Peak traffic (the three minutes before flash‑sale starts): tighten all thresholds, strengthen slider captcha and account risk verification.

Gray rollout: new risk rules first affect 10 % of traffic; monitor false‑block rate and user complaints before full deployment.

Appeal channel: when users see “activity restricted”, provide an appeal entry for manual review of account, device, and IP data to lift the blacklist.

Timed cleanup of temporary blacklist: low‑risk devices and IPs are automatically removed after 24 hours; high‑risk entries remain permanently.

5. Online High‑Frequency Scalper Script Attack Scenarios & Solutions

Scenario 1 – Naked API Crawler (Direct Order API Call)

Root cause: missing front‑end behavior data and mismatched request sequence.

Solution: enforce submission of page‑behavior trajectory and timestamp; missing data leads to immediate block.

Scenario 2 – Multiple Simulators on One Device

Root cause: identical device fingerprint and high‑frequency multi‑account requests.

Solution: device fingerprint rate‑limit, restrict the number of accounts per device, blacklist devices that exceed limits.

Scenario 3 – Proxy IP Pool Rotation

Root cause: each IP sends few requests, making per‑IP limits ineffective.

Solution: add data‑center IP detection, account‑profile scoring, and block blank dummy accounts.

Scenario 4 – Bulk Registration of New Accounts

Root cause: accounts have no historical behavior, resulting in extremely low risk scores.

Solution: apply the account risk‑scoring model; low‑score accounts must complete SMS verification and are restricted from purchasing.

Scenario 5 – Script Auto‑Solves Slider Captcha

Root cause: simple straight‑line drag trajectories are easily recognized by cracking platforms.

Solution: backend validates drag‑trajectory curve, pause nodes, and irregular speed; uniform straight‑line drags are classified as scripts.

6. Risk Control and Flash‑Sale Business Layered Architecture Design

Front‑risk gateway layer (e.g., Nginx or API gateway) uniformly blocks IP blacklists and high‑frequency requests before they reach business services.

Application risk‑validation layer: after receiving a request, executes the full suite of device, account, behavior, and sequence checks; risky requests are rejected immediately.

Core flash‑sale business layer: only after passing all risk checks does the system perform inventory deduction and order creation.

Advantage: the majority of script traffic is intercepted at the gateway or risk layer, preventing it from reaching inventory or distributed‑lock logic and protecting the core interface from overload.

7. Full Summary

Distinguishing real users from scalper scripts cannot rely on a single check; a five‑layer, front‑end behavior → device fingerprint → account profile → IP network → backend sequence risk‑control system is required. Scripts fundamentally lack the random, delayed, and diverse actions of human users, so every layer is designed around this core difference. Combined with Redis‑based high‑performance blacklists, dynamic thresholds, and gray‑release mechanisms, the solution efficiently blocks bulk bot traffic while minimizing false positives, preserving fairness and system stability for flash‑sale events.