Rotating offers: one discount, many audiences, no code

The discount that was always on

The welcome offer went live in month three and nobody has turned it off. Ten percent, everybody, permanently, applied automatically because somebody read that codes hurt conversion.

On 900 orders a month at Rs 1,800, that is Rs 162,000 a month, or Rs 37,413 a week.

Most of it buys nothing. The overwhelming majority of those orders were going to happen at full price, and the discount is a subsidy attached to demand that already existed.

The usual reaction is to turn it off, which produces a visible dip and a nervous meeting, and it goes back on within a fortnight.

Rotation is the third option. Keep a discount running every single week, at a deeper rate than you have ever offered, and spend a twentieth of what you are spending now.

Step 1: Pick the axis you rotate across

Rotation needs a dimension along which shoppers can be divided into groups that do not overlap. Four work.

Delivery zone. The strongest axis, because the boundary is physical and the shopper cannot change it without changing where the parcel goes.

Customer segment. First-time buyers, lapsed customers, or a tier. Workable, though segment membership is invisible to the shopper, which weakens the sense that the limit is real.

Product category. Easiest to implement and the weakest urgency, since a shopper who wants something in a category that is not live simply waits.

Acquisition channel. Rarely worth it, because channel membership is unstable and shoppers arrive through several.

Pick one and only one. Rotating along two axes at once produces a schedule nobody internally can reason about, and the first support ticket asking why a customer did not get the offer will take an hour to answer.

The number of groups on your chosen axis sets your cycle length, which is the next decision and the one that controls the money.

Step 2: Choose the cycle length, which is the budget dial

With one group live per week, a cycle of N weeks means each group is live once every N weeks. The share of orders that get discounted is the average group’s share of volume, which falls as N rises.

The table below assumes 900 monthly orders across 320 pincodes on a Zipf curve with exponent 0.8, giving 208 orders a week. Depth is held at 25%.

Cycle length	Share of orders discounted	Discounted orders per week	Weekly cost at 25%	Against always-on 10%
5 weeks	4.55%	9.5	Rs 4,253	11.4%
10 weeks	3.12%	6.5	Rs 2,921	7.8%
20 weeks	2.06%	4.3	Rs 1,930	5.2%
50 weeks	1.14%	2.4	Rs 1,068	2.9%

A 20 week cycle at 25% depth costs Rs 1,930 a week. The always-on 10% it replaces costs Rs 37,413 a week.

Two and a half times the depth, at a twentieth of the cost, with a promotional event running every single week of the year.

Cycle length is therefore not a scheduling preference. It is the primary spend control, and moving from 5 weeks to 20 halves the cost again.

The constraint on the other side is exposure. A cycle longer than about 50 weeks means some groups never see the offer at all in a year, at which point you are not running a rotation, you are running an offer for a few favoured zones.

Step 3: Set depth from margin, not from the freed budget

The arithmetic above produces a trap, and it is worth naming before somebody walks into it.

If you hold the always-on budget constant and spend it all on a 20 week rotation, it would fund a discount depth of 485%. The number is absurd, and its absurdity is the finding.

It means the always-on budget was over-provisioned by an order of magnitude relative to what a targeted mechanic needs. The correct response is to bank the difference, not to find a way to spend it.

Set depth from your margin floor instead. Take gross contribution per order, subtract any shipping you absorb, and divide by order value to get the depth at which the order stops making money.

Then set the rotation depth comfortably below that, and treat the remaining budget as recovered rather than as available.

Brands that skip this step end up at 40% or 50% depth because the model said they could afford it, and discover that the deepest discounts in their history are landing on the customers who were most likely to buy anyway.

Step 4: Remove the code

A code destroys a rotation completely, and the failure is total rather than partial.

A code is a string with no audience properties. The moment it is posted in one group chat it is available to every group simultaneously, and the entire mechanic collapses into an always-on discount that a subset of people know about.

Per-group codes do not fix this. They convert one shared code into several shared codes, and coupon aggregator sites index all of them within days.

The requirement is an automatic discount that evaluates the audience rule at checkout, so there is nothing to copy and nothing to search for.

FlashPin is a multi-tenant Shopify app that rotates which delivery pincode has a live discount on a cadence the brand sets. Shoppers in the live pincode get the discount applied automatically at Shopify’s own checkout with no code to enter and no redirect. Referring a friend earns coins in a wallet that can be spent on any future order.

The gate has to read something the shopper cannot rewrite. A cart attribute can be edited from the browser console, so the rule needs to sit on a field the platform itself populates, such as the delivery address on the cart.

Removing the code has a second benefit that has nothing to do with rotation. An empty code field at checkout prompts shoppers to leave and search, which costs conversion independently of any discount you were running.

Step 5: Keep the schedule unpublished

The instinct is to publish the calendar so customers know when their turn arrives. That instinct undoes the entire mechanic.

A visible schedule converts urgency into queuing. A shopper who knows their group goes live in three weeks has a rational reason to wait three weeks, and you have taught deferral to precisely the people the rotation was supposed to protect.

Unpredictability is what makes the offer worth acting on. If a shopper cannot forecast their turn, waiting carries real risk of missing entirely, and buying now becomes the sensible choice.

Two related rules follow. Never extend a window, because one extension teaches everybody that the schedule is negotiable. And never grant an exception to someone whose group is not live, because that converts a rule into a policy with an appeals process.

Support will push back on both. Give them a script rather than discretion, and accept that a small number of tickets will end unhappily.

The frequency argument underneath all of this is in flash sales without the brand damage, and the credibility requirement is in scarcity you can defend.

What rotation cannot do

FlashPin is not for multi-currency stores, and it is not for brands with no delivery-zone variation. A brand delivering identically everywhere has to rotate along a segment axis instead, which works but loses the physical boundary that makes a zone rule verifiable.

Volume is the harder constraint. A 20 week rotation touching 2% of orders needs enough baseline volume in each group to produce a readable result, and a brand doing 60 orders a month has groups of one or two.

Rotation also cannot replace a sale. Two percent of orders is a rounding error against a festive event, and a brand that swaps its Diwali campaign for a rotation will have a bad quarter and a correct explanation for it.

The limitation worth sitting with is that all the cost saving comes from reaching fewer people, so the saving and the reduced reach are the same fact described twice. A rotation that costs 5.2% of an always-on discount does so because it discounts 2.06% of orders, and no amount of cadence tuning separates those two numbers.

If your problem is that not enough people are buying, rotation solves the wrong half of it, and the honest use of the freed budget is acquisition rather than a deeper offer. The urgency mechanics that decide whether the window converts at all are in countdown timers are dead.