What is free trial abuse?
Free trial abuse is when one person repeatedly creates new accounts to re-claim a product’s free trial or free-tier quota without ever converting to paid. Each account looks like a distinct customer, but they all originate from one person behind a single device or local network, cycling identities to keep the free benefit running.How ShieldLabs surfaces it
ShieldLabs resolves each signup to a set of identifiers and grades how many accounts a device has spread across. Four layers answer four different questions:| Layer | What it answers | Where you read it | Latency |
|---|---|---|---|
| Identification | ”Is this the same device, even after cleared cookies, incognito, or a new IP?” | The durable device_id on the webhook / History API | About a second |
| Anonymity detection | ”Is this trial start masked or anonymous right now?” | The signals array on the webhook / History API | About a second |
| Risk Score | ”How risky is the visit overall, as one 0-100 number?” | risk_score on the webhook / History API | About a second |
| Patterns | ”How many accounts has this device or local network already started a trial with?” | Dashboard Patterns + export | Background (~10 min) |
Prevent free trial abuse
The rule your code applies: read the durabledevice_id and your own user_hid on every trial start, count the distinct user_hid values behind one device_id (and behind one local_ip.ip for the local-network case), and when that count crosses your trial limit, require verification or deny the trial instead of minting another free run. Fold in the session Risk Score (0–100) as weight: a clean device with a first trial passes, while a machine already cycling several accounts, or a high-band masked session, gets held. When a cycler hides behind a VPN to look like a new region, the real network IP (local_ip) still exposes the network behind a faked public_ip.country, and detection_flags.ip_mismatch is set to true so your code can act on it. ShieldLabs surfaces the count and the score; your signup handler owns the allow, verify, or deny. The steps below wire it up.
Build it
Identify at trial start
Load the snippet on the page where the trial begins — the signup form or “start free trial” button — and re-identify on the action itself so you score the session actually starting the trial. Pass the account’s hashed id (UserHID), never a raw email.
start-trial.html
Read the scored result on your server
The score arrives on the webhook. Verify the signature, cache it by The weights in
request_id, and read it back with the shared waitForScore helper, or fall back to a History API read by request_id. The fields your trial gate reads:signals always add up to score; the webhooks reference has the full schema and every detection_flags boolean.Count the trials behind the device and decide
Read the session For the local-network shape, run the same distinct-
score for anonymity, then link related accounts by the durable device_id to count how many trials that machine has already started. A high score alone can be an honest prospect on a VPN; a high score and several accounts behind one device is the cycling shape worth gating.api/start-trial.js
Read a device's trial history
user_hid count keyed on local_ip.ip instead of device_id.See the spread over time
The per-session check catches a trial right now. The standing view is Patterns, graded server-side over a rolling window and exported as CSV or JSON. Two map directly to trial cycling.
Many Accounts on One Device
Many Accounts on One Device
One device linked to many distinct accounts: the core trial-cycling shape. The grouping identity is the durable DeviceID, so a fresh email and a private window do not reset it. It grades Suspicious, then Dangerous, as the account count climbs.
Many Accounts on One Local IP
Many Accounts on One Local IP
Many accounts starting trials through the same local network address, even when each session uses a fresh cookie and a different public IP. This catches a person who spreads across several separate browsers but still sits behind one router or NAT.
History reads through
account.shieldlabs.ai are free; the Management History path bills 1 request per returned row (an empty result still bills 1). For high-volume signup flows, use the pattern export as a fast denylist of cycling DeviceIDs and Local IPs, and reserve live reads for the borderline trials that are expensive to give away by mistake.Tune to your product
Start in logging-only mode, watch how your real signups distribute, then set the device and local-IP limits that match your trial terms before you raise friction. A real prospect on a corporate VPN can fire the same anonymity signals, so weigh the count, the score, and your own context together.
Test it
You do not need a real farm to see this work. Start a trial once in your normal browser and note thedevice_id on the webhook. Then play the cycler: clear cookies, open a private window, or switch to a second browser profile, and start a trial again as a different account. The cookie_id and visitor_id change every time, but the same device_id returns, and the distinct-user_hid count off that device climbs with each run — exactly the count your gate reads. Toggling a VPN adds the matching anonymity signals to the score without changing the durable DeviceID.
Next
Promo Abuse
The reward-time sibling: the same device-count logic applied to coupons, signup bonuses, and referral credit.
New Account Fraud
Join accounts to the DeviceID at registration so a farm is thinned before it ever reaches a trial.
Multi-Accounting
The general shape behind trial cycling: one person, many accounts, one machine.
Risk Scoring
How the 0-100 explainable score and the Clean / Low / Medium / High bands work.