Bonus and promotion abuse

The problem

Promotion abuse is multi-accounting with a direct cost: every extra account earns the reward again. Typical forms are repeat sign-up bonuses, free trials restarted with new emails, single-use coupons used many times, and referral rewards where the referrer and the “friend” are the same person. Email addresses, phone numbers and IP addresses are easy to rotate; a whole device setup is harder.

What WhiskerJS contributes

Collect at the moment the reward is decided, usually sign-up and the first qualifying action (first deposit, first order, trial start). Each result gives a visitorId to count claims per device, a structuredId to catch setups that changed only a little, and integrityFlags that may point at tooling.

Signals and flags that matter

• The stable groups that people rarely change between accounts: gpu, fonts and device. See Signals.
• browser_class and the browser group, which change when someone switches browser on the same machine while the other groups stay.
• Signs of fingerprint-varying tools: noisy canvas or WebGL components, canvas_readback altered, prototype_lie, iframe_mismatch. Privacy extensions can cause the same results, so these are reasons to look closer, not proof.
• Automation flags on sign-up: automation_webdriver and automation_globals point at scripted account creation.

Using structuredId similarity

Someone who opens a private window, changes the language or tries a second browser changes some groups and leaves others. A claim rule can look at the strongest groups:

import { ID_GROUP_ORDER } from 'whiskerjs';

interface PriorClaim { account: string; structuredId: string }

/** Earlier claims whose structuredId shares every listed group with this one. */
function similarClaims(current: string, prior: PriorClaim[], groups = ['gpu', 'fonts', 'device']): PriorClaim[] {
  const cur = current.split('_');
  return prior.filter((p) => {
    const parts = p.structuredId.split('_');
    if (parts[0] !== cur[0]) return false;            // only the same idVersion
    return groups.every((g) => {
      const i = ID_GROUP_ORDER.indexOf(g) + 1;
      return parts[i] === cur[i];
    });
  });
}

The group list is an example. Common device models with default settings share many groups, so measure how often legitimate customers match before you use it.

Anti-replay

A claim script can capture one result and reuse it for every new account. Bind each result to a nonce your server issued for that sign-up or claim, accept it once and only while it is recent. See Anti-replay binding and the Node guide.

What must happen on your server

1. Decide the reward with your own rules: device links, payment instruments, addresses, timing between sign-up and claim, referral graph.
2. Prefer proportionate outcomes: hold for review, require verification, or limit the reward, rather than refusing on the device link alone. Households, students in shared housing and office machines share devices.
3. Never let the device result alone release money or credit.
4. Keep the stored data to what the rule needs and for as long as the promotion and its review period require.
5. Compare only within the same idVersion and signalsVersion.

Limits

• Separate devices defeat device linking. So do enough changes to one device.
• Privacy browsers make devices more alike by design; expect more matches among their users.
• A shared id can be an innocent household. Explain your rule in your terms and in your privacy notice.
• No figures on how many repeat claims WhiskerJS finds have been measured.

Questions and answers

Related pages