Giveaway Fraud Prevention: Controls, Checks and Templates

Giveaway fraud prevention starts with clear entry rules, controls that match the entry method, and a review before the winner is announced. Use automated checks to catch suspicious activity, then decide whether an entry actually broke a published rule. A shared internet connection, a private profile or an unusual email address is not enough to make that decision.

The goal is a list of eligible entries you can explain, with a reason for every exclusion. This guide shows which controls to choose, what to check when entries look suspicious, and how to keep genuine participants in the giveaway.

Use this four-step prevention and review process

Define: state who may enter, which actions count, the entry limit and the deadlines.
Check: test signup, repeat submissions and the information your chosen tool can actually verify.
Review: check whether a warning sign is supported by evidence that an entry broke a rule. Keep unresolved cases visible.
Record: save the decision and finish outstanding checks before approving the list used for the draw.

A random picker chooses from the list you give it. Random selection does not establish that those entries were eligible.

Choose controls for the way people enter

Different entry methods give you different evidence. Start here before buying another fraud feature or tightening a filter.

For an entry form or email signup

Confirm access to the email address if your rules require it. Check that the confirmation reaches the right entry and that clicking twice does not create another entry. Confirming an inbox does not prove that its owner entered only once.
Apply the stated entry limit. Decide how you will identify repeat entries and handle a retry. One email per submission is a different rule from one entry per person.
Use bot challenges and submission limits where supported. A bot challenge checks whether someone appears to be using the form themselves rather than sending automated submissions. Test that a real person can finish it on a phone and recover from a failed attempt. Ask your provider how limits handle shared networks and a legitimate traffic surge.
Keep an export or review record. You need the original entry, timestamps, relevant confirmation or action evidence, and why a record was flagged for review. An unexplained risk label makes a disputed decision harder to resolve.

Use the comment, account ID, post and submission time your tool actually supplies. Check its documented limits before promising to verify follows, shares or private-account activity. Typing a username into a form does not prove that the person followed an account or completed another required action.

Apply the published duplicate and closing-time rules to the available comments. Review the proposed winner through the announced contact method. Do not infer that a quiet or private account is fake simply because you cannot inspect much of it.

For referral or bonus entries

Define exactly when a referred person qualifies and when bonus entries are earned. Test a new signup, a pending confirmation and an existing participant. Also check that receiving the same signup or confirmation twice does not create extra credit. Check how cancelling an invalid referral affects the referrer's entries. Referral counts and prize-draw entries are different records; verify both before choosing a winner.

Before choosing software, ask: Can I inspect the reason for a flag, correct a decision, export the final list of eligible entries and confirm what the winner actually completed? Check those functions on the plan and entry method you will use. A fraud feature on a marketing page is not proof that your particular rule is enforced.

What a real promotional bot attack teaches

In F5 Labs' analysis of a restaurant promotion, researchers observed automated account creation and login activity during the contest. Registration accepted addresses that looked like valid emails without checking access to the inbox. The activity also used many network addresses.

F5 could see account creation and logins, but not activity in the contest itself. Its evidence therefore did not establish how many fraudulent entries or prize claims succeeded. The useful lesson is to check the connection between account creation, completed entry requirements and the final prize pool. An address that looks valid or passes a network filter does not establish that connection.

Review warning signs before excluding an entry

Write down what you observed, which rule might be affected and what would resolve the question. Apply the same check to comparable entries.

Several entries share an IP address: an IP address identifies a network connection, which several people may share. Check for a household, office, school or event network before treating those entries as one person. Cloudflare's rate-limiting documentation explains how shared addresses can cause legitimate users to be grouped together. There is no universal safe number of entries per IP.
A rush of entries arrives: compare it with your promotion schedule and referrals. Look for repeated submissions or failed requirements within that group; a traffic spike alone does not show which entries are invalid.
Addresses look similar or use privacy services: check the email confirmation and any evidence of repeat participation. Similar spelling or an email alias does not establish that two entries belong to the same person.
A social account has little visible activity: check the required entry action and contact the selected account consistently with your rules. Profile appearance is a weak substitute for evidence.
A required action cannot be verified: check whether the participant failed it or your tool cannot observe it. If your tool cannot check an action, that is not evidence that the participant failed to do it.

Use three states: eligible when the available evidence supports the required checks; needs review when an important eligibility question remains; and excluded when a specific published rule supports the decision. A high risk score can send an entry to review. It should not become your entire explanation.

Worked example: review eight records before the draw

This is a fictional training exercise, not a customer case or a tested fraud-detection model. The example offer allows one entry per person. Repeat submissions count once, form submissions must arrive before the entry close, and required email confirmation can finish by a separately announced review deadline before the draw. Other eligibility requirements have already been checked.

Those are example rules, not universal giveaway terms. The separate confirmation deadline must be announced in advance and supported by the actual system.

R01 — Ari: eligible. On-time submission and completed confirmation; no unresolved rule issue.
R02 — Bo: eligible. Shares Ari's household connection, but has a separate completed entry and confirmation. There is no evidence of repeat participation; the rules do not limit entries by network.
R03 — Ari's retry: excluded as a duplicate record. The same participant resubmitted. Keep R01 under the stated one-entry rule; the retry does not disqualify Ari from the giveaway.
R04 — Cato: excluded as late. The recorded submission arrived after the published entry close. This is an eligibility decision, not an accusation of fraud.
R05 — Dev: needs review. The form arrived on time, but email confirmation is still pending and the review deadline has not passed. Check delivery and allow the same published completion window as everyone else.
R06 — Emi: eligible. Uses a privacy email address and has completed confirmation. No duplicate or other rule issue is recorded.
R07 — Fin: eligible. Has little public profile activity but completed this form-based offer's requirements. Social posting activity is not an eligibility condition.
R08 — Gray: eligible. Arrived during a genuine promotion spike and completed the requirements. Timing alone is not a rule breach.

At this checkpoint: eight submission records = five eligible records + one needing review + two excluded records. This is not yet the final draw pool: Dev's case is unresolved. If confirmation arrives within the announced window and the other checks pass, record the evidence and move R05 to eligible. There would then be six eligible records and two excluded records.

If Dev does not meet the published requirement by the stated deadline, record that specific failure and apply the announced procedure. Do not quietly label the record fraudulent, invent a new deadline or draw while a case that could change the pool is still unresolved.

Copy this entry-review record

Copy one card per reviewed entry into a private working document. Use entry IDs in shared summaries; keep email addresses and supporting personal information restricted to people who need them.

Entry-review card

Campaign and entry ID: ______
Published rule and version: ______
Observed signal or missing requirement: ______
Evidence checked and where it is saved: ______
Current state: eligible / needs review / excluded
Decision reason tied to the rule: ______
Reviewer and decision time: ______
Next check, owner and deadline: ______
Correction or restoration, with reason and time: ______

Try it with R05: write “confirmation pending” as the issue, assign someone to check delivery and set the next check within the existing review window. Then record a hypothetical timely confirmation and the change to eligible. The original pending state remains part of the record; it is not overwritten with a claim that the entry was always verified.

If suspicious entries are arriving right now

Preserve the source records. Save the current entries, rules, settings and relevant timestamps in protected storage before a bulk cleanup. Excluding a record from a draw and deleting it are different actions.
Contain the problem you can identify. Use the provider's supported challenge or submission controls, or pause new promotion while the owner investigates. Test legitimate mobile and shared-network entry again after a control changes. Follow the announced rules for any campaign interruption.
Review the affected group. Start with the specific repeated pattern, check the underlying requirements and record decisions. Keep eligible, pending and excluded totals separate; do not report every submission as a qualified lead.
Resolve the draw and communication plan. Resolve pending cases that could change the list of eligible entries before approving that list. If you cannot meet the announced schedule, follow the rules for interruptions and tell entrants what happens next. Do not silently change who qualifies.

Have the campaign owner record how many records were reviewed, are excluded or pending, and were restored after a mistake. Count people separately; these review totals do not measure detection accuracy without knowing which entries were actually abusive. Resume promotion after legitimate mobile and allowed shared-network tests pass and every pending case has an owner and deadline. Cases that could change the draw list still need resolving before the draw.

Do not bulk-delete entries because they share one characteristic and a dashboard calls them risky. Check whether exclusions can be reversed and whether removing one entrant changes referral credit, bonus entries or the displayed totals. Give an owner responsibility for corrections and entrant questions.

Run this prevention checklist before launch

Copy this list and fill the blanks. Leave a box unchecked until the named owner has observed the expected result.

☐ Rules: ______ states how to enter, how many entries each person may have, required actions, deadlines and how the winner will be contacted.
☐ Valid participant: ______ completes the full entry on a phone and receives the expected confirmation.
☐ Retry: ______ confirms that resubmitting or clicking confirmation twice follows the published entry limit.
☐ Shared network: ______ checks that two authorized test participants on the same connection can complete separate allowed entries.
☐ Missing step: ______ checks how an unconfirmed or incomplete entry is shown and resolved.
☐ Referrals, if offered: ______ checks qualification, repeat events, invalid referrals and any change to bonus entries.
☐ Review: ______ can inspect a flag's evidence, record a reason, correct a decision and preserve the original record.
☐ Draw: ______ can export or identify the final eligible pool after pending cases that could change it are resolved.
☐ Response: ______ owns suspicious-entry questions, campaign interruptions and a failed verification check.

Use authorized test identities or a designated test environment. Keep those records out of the real prize draw and acquisition reporting.

Verify the winner before announcing the result

Once the final list is settled, use the announced selection method. Save the entry count, draw time and result. Check the selected entrant's requirements and any outstanding review before announcing or delivering the prize. Request only the information needed for that check through the contact route you announced; do not ask for passwords, sign-in codes or a payment to prove eligibility.

Document an unsuccessful verification and follow the published alternate-winner process. If a review mistake changes the eligible pool after a draw, pause the announcement and have the campaign owner apply the rules to the correction; do not quietly choose a preferred replacement.

For the next step, our guide to picking a giveaway winner fairly covers the draw record, backup winners and announcement. Keep the review record alongside that proof so you can explain both who was allowed into the draw and how the winner was selected.