Holiday Promo Abuse from Black Friday to New Year

You turned the holiday offer on.

By the next morning the same laptop had redeemed the Black Friday code on a fresh email, referred itself for the bonus, and opened another trial the hour the last one ended. Cyber Monday looked like a record week. The paid plans never started.

The promotion worked. The customers didn't multiply.

Real buyers were in that week too. One account, one household, actually using the product. A hard block on every shared laptop punishes them along with the fellow who opened the rest.

Holiday promo abuse is that ordinary mess, squeezed into the weeks from Black Friday to New Year. Promo codes, referral bonuses, extended trials, and holiday free credit all draw the same crowd, and the controls have to be on before the code goes live.

Dregs is one judgment layer on the account. It scores each identity and opens every score into its observations, so a suspicious account can be held without treating every holiday signup as abuse.

What Black Friday Promo Abuse Looks Like

The offer was real. A launch credit, a signup coupon, a referral bounty, a trial stretched for the holidays, a pile of free credit with an expiry date in January. Each redemption looks like a new customer, because the code was published on purpose and a single signup clears every check aimed at one account. The abuse shows up when the accounts are connected, or when the redemptions pile up and a paid plan never starts.

Promo abuse and coupon abuse work this way in March too. From late November through New Year the offer is public, dated, and more generous, so the same behavior arrives as a crowd. The spike that gets called Cyber Monday fraud is that crowd, one day later, with a louder code.

Coupon stacking through new accounts

That fellow, a sharper with a public code for a personal allowance, redeems it, closes the laptop, and opens it again as a stranger: different inbox, same machine, same offer. Then he does it again before lunch.

The more ambitious of these spongers can collect the offer a dozen times in a morning, each account solemnly new, none of them about to pay when the credit runs out. The campaign report counts a dozen customers. The laptop counts as one.

Referral farming

A holiday referral bonus pays for an introduction. The enterprising version of the scheme needs no friends. The referral link goes out, a second account comes back through it, and the bounty lands on both sides of a transaction conducted with one person. Referral fraud is that pattern the rest of the year. A Black Friday bounty just makes the arithmetic worth an afternoon.

Extended trials and holiday free credit

Lengthening the trial, or dropping holiday free credit on every new account, is a gift to someone who was going to pay. It's also an invitation to take the gift twice. Free trial abuse is the same person claiming a trial that was meant to be singular, under a fresh email the hour the last one ends. An extended holiday trial doesn't reset that rule. The calendar got longer. The customer didn't multiply.

Signup bots

Scripts fill the form faster than a person finds the submit button, rotating inboxes so each registration looks like a visitor. The accounts sit ready for the hour the code goes live, or they redeem on the way in. A CAPTCHA on the form is a toll at that volume, paid in fractions of a cent. Signup bots are the automated end of the same week.

Card testing at checkout

A card testing attack at signup is a wave of throwaway accounts whose job is to reach checkout and try a card. The holiday promo is useful cover: checkout volume is already high, new accounts are expected, and a failed payment looks like an abandoned checkout. The pattern worth scoring is the accounts. A disposable inbox, a device that has already produced a pile of signups, a purchase event, and no use of the product. Declining the card still belongs to the payment processor. Stopping the next throwaway account is the part that lives in the user table.

Account farming

A spare afternoon with a public code is a nuisance. A pool of accounts operated together is a business. The glossary name for that pool is a bot farm: accounts run as one resource, pointed at whatever a product will hand out. Operators call the holiday version account farming. The accounts are stock, and the credit, the trial, and the referral bounty are the product. The operation gets paced to look like ordinary signups, overnight gaps included. Any one account may look fine. The population does not. The blister running it has no intention of starting a paid plan.

A Pre-Launch Checklist

Promo abuse prevention for a dated offer is the work done before the code is public. The week the offer is live is a bad time to discover that the only limit is the email field, and that nobody is watching the queue.

Cap the offer per identity

One redemption per customer. The key is the person, not the inbox. A new address, a plus address, and a disposable email address are cheap. A hard block on plus addressing punishes people who use it to organize mail, and it misses the next free inbox anyway. Normalize the address, count it, and still expect a determined operator to move to a different inbox. The cap has to follow the identity: the device, and the cluster of accounts that share one.

The same cap covers the other holiday offers. A referral bonus pays once for a real introduction, not for a second account that came back through its own link. An extended trial is still one trial. Holiday free credit doesn't become a second credit because the first inbox was abandoned.

Your application enforces the cap. Whether two signups are one customer is a separate judgment, and it has to be in place before the first credit goes out.

Check the device and the email

A device shared across signups that each applied the offer is the strongest account signal, including an incognito session that was supposed to look new. Email is the other check, and it's a signal rather than a wall. A disposable address correlates with throwaway signups. It's also something a privacy-conscious person may use for a first contact, which is a false positive if the domain alone is blocked. Read it alongside the device, the redemption, and whether a paid plan ever starts.

Turn escalation rules on before the code goes live

Escalation rules open a stateful incident when an identity's scores or badges match conditions you define. Limit the holiday rules to new identities, so an established customer whose score dips for an afternoon doesn't land in the queue.

Useful conditions are a low Uniqueness score on a signup that redeemed the offer, a low Authenticity score on a new identity, and a low Humanity score when the registration looks automated. You set the thresholds. A badge with an apply delay, then an escalation on that badge, produces fewer false positives than a rule that fires on a score flicker. Match the severity to the hurry: Critical when a script is minting accounts, Warning when a cluster collects the credit and never pays, Info when the pattern only needs to be on record.

Route the rule to a channel someone will actually see: email, Slack, or a webhook. The dashboard shows every escalation either way.

Name who watches the review queue

An escalation opens, someone acknowledges it, and it closes when the decision is made: hold the credit, step up the cluster, or mark a false positive and let the customer through. Acknowledging is how two people avoid working the same account. Name the owner, and name a backup, before the week between Christmas and New Year. That's when the queue fills and the team is thin. If open escalations pile up in the summary and nobody owns them, the rules are a diary.

Decide the mid-campaign moves before you need them

Write the response down while the numbers are still calm.

• Hold the next credit on accounts that share a device with an earlier redemption, or that stack codes and never start a paid plan. The signup can stay. The allowance doesn't have to go out.
• Step up verification on the linked cluster only. A single redemption that becomes a paid plan stays on the ordinary path, including a shared office on Cyber Monday morning.
• When the queue is full of households and cofounders, loosen the rule. That's a false positive problem. Read the observations so you can see exactly why before a real buyer loses the offer.
• When one device produces a stream of redemptions, tighten the hold on that cluster and leave the public code up for everyone else.
• Keep the campaign on the queue. Suspicious accounts arrive with the evidence attached, which means less manual review than a hand search of the user table.

How Dregs Fits

Dregs works at the account layer. It scores every identity and escalates the ones that match rules you define. A card testing attack shows up here as accounts created to reach checkout. A purchase event on checkout and plan change is what makes that signup campaign visible on the account. The decision to charge a card stays with the payment stack.

Four scores, each from 0 to 100. Each one opens into its observations, so you can see exactly why an account was flagged.

• Humanity estimates whether a person is behind the signup. It's accurate from the first page load, which is what catches signup bots almost instantly.
• Authenticity estimates whether the submitted identity looks genuine. Out of the box, obvious disposable email domains and gibberish names are caught. With training, the score becomes more nuanced about what legitimate data looks like on your product.
• Uniqueness estimates whether this is the only account. A new signup that shares a device fingerprint with an existing one, including an incognito session, is flagged with no training period. That's what makes a cap on the person real: a new inbox on the same laptop doesn't look unique.
• Behavior estimates whether usage looks like a customer. A new account with one event has no meaningful Behavior score yet. Once redemptions repeat and a paid plan never starts, or purchase events pile up on accounts that never use the product, that pattern is what Behavior reads.

Custom rules and lists are how those scores become a holiday policy. In Dregs that means badge rules and escalation rules. A badge settles a classification, such as a cluster collecting the offer, and the escalation fires on the settled label rather than on a momentary dip. Webhooks carry the decision to your application moments after new activity, which is how your app holds the next credit before it lands. You choose the thresholds. Your application enforces the cap.

Frequently Asked Questions

Further Reading