Marketing & channels — Rules2Tag presets
Consent, discount codes, and where the sale came from.
Each of these is a ready-made rule you can adopt in one click inside Rules2Tag, then change however you like. Nothing runs until you say so, and every rule can be previewed against your own store first.
15 presets in this category
Recently abandoned a cart
I want to tag customers who abandoned a checkout recently
Tags a customer whose most recent abandoned checkout is within the last N days — and drops the tag as soon as they order.
Why: Abandonment is a recency signal, not a permanent label — so the tag ages out on its own as the window passes, with no expiry mechanism to configure and nothing to clean up later. The exemption matters as much as the window: a recovery campaign that keeps emailing someone who already bought is the exact failure automated tagging is supposed to end.
Students (.edu email)
I want to spot students so I can offer a student discount
Tags a customer whose email matches a pattern you choose — \.edu$ for US universities.
Why: Email-domain segmentation is how student and employee pricing is usually verified without a third-party service, and a regex handles the variants (.edu, .ac.uk, a company domain) that an equals-match cannot.
Email marketing subscribers
I want to tag customers who agreed to marketing email
Tags a customer whose email marketing consent is subscribed.
Why: Consent lives on the customer profile but is not a tag, so it cannot drive the flows and segments that read tags. It also changes, so a manual copy goes stale — and a stale copy is a compliance problem, not a marketing one.
Discount shoppers
I want to know who only buys on promotion
Tags a customer who has used any of the discount codes you list.
Why: Customers who only ever buy discounted are worth knowing about before you send them another discount — and worth excluding from campaigns meant to protect margin.
Customers with an unverified email
I want to keep unverified addresses out of my sending list
Tags a customer whose email address has not been verified.
Why: Unverified addresses are where bounces, spam traps and typo-ed domains live, and sending to them costs you deliverability for everyone else. Tagging them lets you suppress or re-confirm rather than discovering the problem through a sender-reputation drop.
Customers on your own company domain
I want my team’s own test and staff orders kept out of the numbers
Tags a customer whose email matches a pattern you supply.
Why: Staff accounts, test orders and agency logins quietly distort every cohort you will ever build, and they never look wrong enough to notice. Tagging them once means every later segment can exclude them without anyone having to remember why.
Customers who shop in a particular language
I want to send people email in the language they actually ordered in
Tags a customer whose most recent order was placed in one of the locales you list.
Why: Language is the one personalization customers notice immediately when you get it wrong, and it is already sitting on the order. Most email tools can segment on a tag long before they can be taught to read a Shopify locale field.
Customers with a verified email
I want a clean sending list of addresses I know are real
Tags a customer whose email address has been verified.
Why: The inverse of the unverified rule, and the one you want when building a list rather than pruning one. Sending only to verified addresses protects the deliverability of every message you send afterwards, which is a shared resource across the whole store.
Orders using a discount code
I want to see which orders came from a promotion
Tags an order that used any of the discount codes you list.
Why: Attribution after the fact is painful; a tag applied as the order arrives makes “how did that campaign do” a filter rather than an export.
Orders from direct traffic
I want to see which orders came with no referrer
Tags an order that arrived without a referring site.
Why: Direct traffic is usually returning customers, word of mouth, or an untracked campaign — and separating it from paid traffic is the first step to knowing which is which.
Orders where the buyer opted into marketing
I want to know which orders came with permission to email
Tags an order whose buyer accepted marketing at checkout.
Why: Consent is captured at the moment of the order and then lives on the customer, where it is easy to lose track of which purchase it came with. Tagging the order records the permission against the event that produced it — which is what you want if anyone ever asks.
Orders from a specific date range
I want to label the orders from one sale or season
Tags an order placed between two dates you choose, inclusive.
Why: Every reporting tool can filter by date; none of them leaves anything behind. A tag makes the period permanent — it survives into exports, it can be combined with other conditions, and it still answers "how did Black Friday do" next year when the dashboard has been replaced.
Orders from a particular source
I want to separate orders by how they were placed
Tags an order whose source is one of those you list.
Why: Web, POS, draft order, an app — the source decides which of your processes an order should go through, and it is one of the few facts about an order that never changes afterwards. It is also coarser than the sales-channel preset, which is the right grain when you only need to know "was a human involved".
Orders from a particular sales channel
I want to know which orders came from POS, a marketplace, or an app rather than my website
Tags an order that came through the sales channels you name.
Why: Channel is the split that changes almost every downstream decision — packing slips, returns policy, tax treatment, whether a marketing email is even appropriate — and it is not something you can eyeball from an order list. One rule per channel you actually treat differently.
Orders from a campaign or referrer
I want to tag the orders a specific campaign actually produced
Tags an order whose referring URL matches a pattern you supply.
Why: Attribution reports live inside analytics tools and expire with them. A tag lives on the order forever, travels into every export, and can still answer "what did that campaign actually sell" a year later when the dashboard that produced the number has been replaced.