Setup Guide
CustomerGenius is flexible by design — most merchants only need a few settings, but advanced setups can combine cross-evaluation groups, custom rules, occurrence tuning, and per-code thresholds. This page walks through real scenarios and the exact settings to use for each.
By default, every discount code you monitor is evaluated independently — a customer using SAVE10 is only compared against past orders that also used SAVE10. A cross-evaluation group tells CustomerGenius to treat several codes as a single eligibility pool, so abuse across the family is caught even when each order uses a different code.
You run a campaign where every code shares a prefix — for example BFCM_10, BFCM_15, BFCM_20 — and you want CustomerGenius to treat them as one offer.
Any order using a code that starts with BFCM_ is now evaluated against past orders using any code that starts with BFCM_. If the same customer identity has used BFCM_10 before and now uses BFCM_15, the fraud score is computed across both orders and abuse is detected.
The cleanest setup whenever your campaign codes share a meaningful prefix. Works for influencer codes (e.g. INFL_*), BFCM campaigns, newsletter automations, and any rule-generated unique code where the prefix identifies the campaign.
You want to treat a handful of unrelated codes as a single group — for example WELCOME, NEWBIE, and FIRSTTIME all serve the same first-time-customer offer but share no prefix.
Every discount code on every incoming order is now evaluated, regardless of whether it appears in your monitored list. Identity matches across past orders using any code count as abuse signals.
When your group of codes doesn't share a prefix and you'd rather not maintain a list manually, or when you want CustomerGenius to monitor all codes in your store — including codes you forgot to add. The tradeoff is that you lose per-code control unless you also configure custom automation rules.
You want CustomerGenius to monitor every discount code in your store, all the time, with no setup per campaign.
Every order using any discount code is scored. The default fraud threshold and action from the Automation tab applies to all of them. New codes you create in Shopify are automatically covered without any update in CustomerGenius.
The hands-off option for merchants who don't want to maintain a code list. Pair this with conservative occurrence tuning (see below) if you'd rather observe before auto-refunding.
You only care about abuse on a specific code — say a first-time-customer code WELCOME10 — and want every other discount code ignored.
Only orders using WELCOME10 are evaluated for discount abuse. Orders using any other code are ignored entirely by the discount-abuse pipeline. Identity matching against past WELCOME10 orders runs as normal.
The strictest, most predictable setup — use this when you have one well-defined offer that's the primary abuse target and you want everything else left alone.
Occurrence controls how many distinct customer identities must have used a code (or be tied to one via identity matching) before CustomerGenius takes automatic action. Occurrence = 2 means "act the moment a second aliased identity uses the same code or group". Occurrence = 3 means "wait until the third". This lets you observe a pattern before automating refunds.
Note: occurrence counts unique identity-matched customers, not orders. If one abuser uses the same email across three orders, that's one customer with two prior orders — occurrence = 2, not 3. Occurrence = 3 fires when three distinct aliased identities (e.g. different emails but the same address) have used the rule's codes.
You want CustomerGenius to act the first time an abuser is identified — the moment a second alias hits the same code.
The first time an aliased identity is detected on a monitored code (current customer + at least one historical aliased identity), CustomerGenius takes the action you chose, as long as the fraud score meets the threshold.
Most merchants. This is the simplest setup and works well when your fraud signals are clean (e.g. addresses are reliable in your category).
You want to see abuse patterns first — flag the 2nd occurrence for review by email, but only auto-refund starting at the 3rd.
When the 2nd alias hits — occurrence = 2 — the rule's occurrence condition (≥ 3) is not met, so no automatic action runs. The order is flagged for manual review and you get an email. When the 3rd alias hits, the rule fires and the action you chose (refund or hold) runs automatically.
New merchants who want a confidence-building period. Also good for codes where you suspect there might be edge cases (gift recipients sharing addresses, multiple household orders) that look like abuse but aren't.
An influencer code may legitimately be used by 1-2 family members at the same household before you'd call it abuse. You want to be generous on that code only.
On orders using that influencer code, CustomerGenius takes no automatic action until the 4th distinct aliased identity is detected. You'll still get manual-review emails for the 2nd and 3rd occurrences if notifications are enabled, so you can review case-by-case.
Influencer or affiliate codes where light reuse is expected. Also useful for codes you've publicly shared (newsletters, podcasts) where you expect higher organic legitimate reuse.
The default rule covers everything, but custom automation rules let you set different behavior for specific codes or campaigns. Rules are matched in priority order from top to bottom — the first one whose values match the order's codes wins. Drag rules in the Automation tab to change priority.
You want a low score threshold (more aggressive) for your most-abused first-time code, and the normal threshold for everything else.
Orders using WELCOME10 are auto-refunded at fraud score 6 or higher. Every other monitored code uses threshold 8.
When a particular code is repeatedly abused and you want to be tougher on it without tightening the bar across the board.
You sell high-margin items where refunding too aggressively could lose legitimate sales. You'd rather pause fulfillment and personally review before deciding.
Flagged orders are placed on fulfillment hold via Shopify (the order isn't refunded, but it can't ship). You receive a notification email. From the CustomerGenius dashboard you can release the hold (if it's a legitimate customer) or issue a refund.
High-AOV stores, bespoke products, B2B, or any category where a refund mistake is costlier than a fulfillment delay.
Some promotions don't run through a discount code — gift-with-purchase, certain BFCM offers, automated tagging from third-party apps. CustomerGenius can monitor order tags with the same identity-based abuse detection it uses for codes.
You auto-tag every BFCM order with the tag BFCM2026 and want to detect abuse across those orders.
Orders tagged BFCM2026 are evaluated against past orders also tagged BFCM2026 using the full identity matching pipeline. Treated identically to discount-code monitoring, just keyed by tag.
When the campaign isn't tied to a single discount code (or the discount is automatic, with no code at all). Common for BFCM, gift-with-purchase, and rule-based discounts.
Several campaign tags like CAMPAIGN_SPRING, CAMPAIGN_SUMMER, CAMPAIGN_FALL all serve the same purpose and you want them treated as a group.
Any order with a tag starting with CAMPAIGN_ is grouped — abuse across CAMPAIGN_SPRING and CAMPAIGN_SUMMER on the same identity is detected as if they were one tag.
The same logic as cross-evaluation discount groups, but for tags. Use whenever your tagging convention groups campaigns by prefix.
The Skip recurring subscription orders toggle does two useful things at once. The obvious one: legitimate subscribers stop getting flagged for placing repeat orders that share an address and email. The more powerful one: a discount code that's monitored as "single-use on the online store" can keep auto-applying on every Recharge renewal without each renewal triggering a duplicate-use refund. Fraud evaluation runs on the original online order; renewals are skipped.
You offer a discount on the online store that's meant to be used once per customer, but the same code auto-applies on every recurring Recharge renewal. Without this toggle, every renewal would look like the customer reusing the code and get refunded. You want the renewals left alone.
Renewal orders generated by supported subscription apps are recognized and excluded from fraud scoring entirely. The discount can be reused on every renewal without flagging. First-time subscription orders are still evaluated normally — only the ongoing renewals are skipped. Existing subscribers also stop getting flagged for placing legitimate repeat orders.
If you offer any subscription product and want a one-time online-store discount to keep applying on renewals — or if you just want to make sure subscribers never get caught in fraud scoring. There's no downside: the skip only applies to recurring renewals, not first-time subscription orders.
The block list is a separate feature from discount monitoring. It's for customers you've decided not to serve — repeat chargeback filers, people who've abused your customer service team, or anyone else you want banned regardless of what they buy or what code they use.
A customer was rude to your support team and you want every future order from them refunded, even if they try to sign up under a new email.
Any future order from that customer is automatically refunded — no fraud-score check, no threshold. CustomerGenius also runs identity matching, so an order from a different email but the same address, phone, or name is refunded too. The block follows the person, not just the email.
When a specific customer has crossed a line and you've decided you don't want their business. The mechanism is independent of discount abuse — the customer doesn't need to use any code for the block to fire.
A realistic store: you run a first-time customer code (FIRST10), a seasonal campaign with several codes (BFCM_10, BFCM_15, BFCM_20), and you have three influencers with their own codes (INFL_ALICE, INFL_BOB, INFL_CHARLIE). You also have Recharge subscriptions and one customer you've banned.
Adapt this template to your own codes and thresholds. The structure — specific rules on top, generic rules at the bottom, sensible default — is the pattern most multi-campaign stores end up converging on.
Every store is different. If your setup doesn't match a scenario on this page, email support@customergenius.io with a description of what you're trying to achieve and we'll write the recipe for you — often within a day.