Promo abuse false positives: shared devices, households and genuine customers

A promo abuse false positive occurs when a legitimate eligible claim is treated as abusive. Shared devices, addresses and networks can create account relationships without proving a breach of the promotion rules. Evaluate the eligibility decision and the identity assessment separately so the team can identify which part was wrong.

Put the eligibility unit in writing

An offer limited to one account is different from one limited to one person or household. If the campaign permits separate adult customers in a home, a shared address should not quietly become an exclusion. If the offer is explicitly one per household, the system needs evidence and terms appropriate to that policy.

Define permitted behavior before collecting a test set. Include genuine account recovery, returning visitors using a family tablet, workplace hardware and customer-service-assisted orders. An analyst should be able to explain the applicable rule without relying on a vague label such as “duplicate user.”

Use independently established labels

Build known legitimate and controlled ineligible cases using evidence separate from the detector being evaluated. For owned test accounts, record who controls each account, which device is shared and which benefits were already claimed. For real cases, use a documented review process and retain unresolved outcomes separately.

Do not label every blocked claim as confirmed abuse. Do not label every later paying customer as legitimate either: a real payment can still breach a welcome-offer rule. Appeals and customer complaints are useful review inputs, but they are not automatically ground-truth labels.

Inspect the reason behind the relationship

Was the match based on device identity, IP, address, payment instrument, behavior or a broader graph? Is it a durable match or a transient observation? Did the system associate the correct session with the correct account?

SEON’s documentation describes a combination of device and digital-footprint inputs. Ravelin’s graph guide explains account relationships across several identifiers. These are useful review dimensions, but a collection of shared attributes still needs the campaign’s eligibility context.

ShieldLabs provides risk score and Trusted, Suspicious, Dangerous verdicts for visitors, users, devices and IP, with account-abuse findings alongside device/network intelligence. Inspect those reasons in the protected flow rather than treating an isolated proxy flag as a reason to deny every related customer.

Measure two errors and one operational gap

The first error is granting an ineligible benefit. The second is incorrectly withholding a legitimate benefit. Missing collection, a failed lookup or an unresolved review is a separate operational category, not automatically either error.

For each reported rate, state the denominator. “Legitimate claims wrongly restricted divided by independently known eligible claims” is useful. “Complaints divided by blocked accounts” answers a different question. Report the observation window and whether pending cases have matured enough to be classified.

Review action severity as well as classification. A request for additional verification, a temporary reward hold and a permanent account restriction have different customer costs. Track how many genuine customers complete the qualifying task and receive the benefit after review.

Make correction possible

Give reviewers the campaign version, linked event history, relevant reasons and current grant state. Keep a route for correcting account association or eligibility facts. Avoid exposing a complete internal risk model to customers, but provide a useful description of the disputed promotion condition.

If a rule repeatedly affects a legitimate cohort, investigate that mechanism before adding a broad exception. A household allowlist can hide repeated abuse if it ignores the benefit history. A blanket shared-IP restriction can exclude offices, universities and carrier networks without resolving the actual eligibility question.

Test again when the flow changes

A new app SDK, login route, promotion engine or payout schedule can change collection and account association. Repeat the known cases after those changes. Keep the promotion version, vendor configuration and evaluation date with the results so a later reviewer can reproduce the issue.

Use the referral guide for advocate-specific cases and the evaluation guide to include review effort and lost legitimate benefit use in the business assessment.

FAQ

Sources

Checked October 21, 2026: SEON product documentation, Ravelin graph analysis, ShieldLabs promotion protection, Stripe account and promotion abuse.