Discounts Train Customers to Wait. Loyalty Programs Should Do the Opposite.
45% of loyalty program members never redeem a single reward. That is not a cost saving -- it is evidence the program is not working, and those members are about to lapse.

The most common e-commerce loyalty program is a discount machine with a points wrapper around it. Customers earn points on purchases, redeem them for percentage-off coupons, and the net result is a margin erosion mechanism dressed up as a retention strategy. The customers who engage most heavily are often the ones gaming the system: buying to earn, redeeming, and churning to the next brand offering a signup bonus.
The programs that actually increase lifetime value work differently. They create switching costs through accumulated status and exclusive access that customers cannot replicate by going elsewhere. They reward behaviors that predict high LTV -- cross-category purchase, review submission, referral -- not just transaction volume. And they are built on a data model that makes all of this trackable and auditable without becoming a reconciliation nightmare.
This post is about the design and data decisions that separate programs that move LTV from programs that move discount depth.
The zero-switching-cost problem and what actually solves it
E-commerce has no physical relationship, no staff recognition, and a competitor one search tab away. The switching cost of leaving your brand is, by default, zero. A loyalty program's job is to make that cost feel real -- not by locking customers in, but by making the accumulated value of staying genuinely worth more than the marginal savings of leaving.
Discounts and cashback fail at this because they are fungible. A 10% discount from you and a 10% discount from a competitor are identical in the customer's mind. They do not accumulate into something that cannot be replicated elsewhere. The loyalty mechanics that create real switching costs are tier status and exclusive access -- things that take time and behavior to earn and that competitors cannot instantly match with a signup bonus.
A customer who has spent $1,500 with you over twelve months and holds Gold status -- with priority support, early sale access, and a dedicated shipping benefit -- feels the cost of leaving more concretely than a customer with a $12 points balance. The $12 can be replicated in one competitor purchase. The Gold status cannot.
This is the design principle that determines whether a loyalty program increases LTV or just increases discount spend: reward behaviors that predict loyalty, not transactions that happen anyway.
The points ledger: the data model decision nobody talks about
Points are a currency. They need to be modeled like one.
The most common implementation mistake in loyalty program builds is storing points as a balance field on the customer record. It feels natural -- a single integer that goes up when points are earned and down when they are redeemed. It is also the implementation that causes the most painful debugging sessions, the most support escalations, and the most reconciliation work.
Every points transaction needs to be a row in an append-only ledger, not an update to a balance field. The reasons compound with scale.
When a customer returns an item, points earned on that purchase need to be reversed. If the balance is a field, you are doing arithmetic on a number with no history. You do not know which purchase the points came from, whether they have already been partially redeemed, or whether a promotional multiplier applied. With a ledger, the reversal is a negative transaction linked to the original earning transaction, and the audit trail is complete.
When a customer disputes a points balance, support needs to reconstruct the history. With a balance field, this requires digging through purchase history, redemption history, and promotion records manually. With a ledger, the full history is the data model.
When fraud patterns emerge -- buy-earn-return cycles, referral manipulation, multi-account exploitation -- detection requires querying transaction patterns. A balance field tells you where someone is. A ledger tells you how they got there.
The schema is not complex:
points_ledger id member_id transaction_type -- earn | redeem | expire | adjust | reverse points -- positive for in, negative for out source_type -- purchase | referral | review | bonus | return source_id -- order_id, referral_id, review_id, etc. promo_id -- nullable; links to promotion if multiplier applied expiry_date -- nullable; for earn transactions created_at
member_points_balance (materialized view) member_id available_balance pending_balance -- earned but not yet settled (e.g., within return window) lifetime_earned
The pending_balance field is the one most often skipped and most often missed in production. Points earned on a purchase that is still within the return window should not be immediately available for redemption. If a customer earns 500 points on a $100 purchase and immediately redeems them for a discount before returning the purchase, you have paid out a reward on a sale that did not happen. Settlement delay of 14 to 30 days on earned points, matching the return window, prevents this class of abuse without any complex fraud detection.
Tier design: the thresholds that determine whether tiers motivate or alienate
Tier structure is the highest-leverage design decision in a loyalty program, and it is more sensitive to threshold calibration than most teams realize.
The fundamental design constraint is this: if fewer than 40% of active members ever reach the first earned tier, the tier system is decorative. Members who join, earn points for a few months, and conclude that the next tier is unreachable stop engaging. The program stops changing their behavior. You have a discount club, not a loyalty program.
The threshold calibration that works for most e-commerce programs: set the first earned tier (Silver, or whatever you call it) so that a customer who makes roughly four purchases per year at average order value reaches it. That is attainable for genuinely engaged customers and meaningfully out of reach for one-time buyers. Set the middle tier so that customers who buy monthly at AOV reach it around month eight or nine. Set the top tier so that only your top 3 to 5% of customers by spend qualify -- genuinely exclusive, not aspirationally impossible.
The benefits at each tier need to be distinct enough that moving between tiers feels meaningful. Free standard shipping at Silver is a strong first-tier benefit because it has high perceived value and measurably reduces cart abandonment by 20 to 30%. Free express shipping at Gold is a meaningful upgrade. The mistake is loading all the meaningful benefits onto the entry tier -- Silver gets free shipping and early sale access and extended returns and priority support -- leaving nothing for Gold to offer that Silver does not already have. Tier progression needs to feel like a genuine improvement in the relationship, not a marginal benefit increase.
Early access to sales is underutilized as a tier benefit because it feels soft. It is not. A 24 to 48 hour head start on a sale or product launch creates genuine urgency and exclusivity. Customers who have experienced early access -- and have successfully purchased something that sold out publicly -- associate their tier status with tangible value that cannot be replicated by a competitor's discount. That is the switching cost mechanism working correctly.
The behaviors worth rewarding beyond purchase
Points-per-dollar is the base layer. It is necessary but not sufficient. The behaviors that predict high LTV are often not the purchase itself -- they are the behaviors around the purchase that indicate genuine engagement with the brand.
Cross-category purchasing is the strongest predictor of long-term LTV in e-commerce. Customers who buy from only one category have a thin relationship with the brand. Customers who buy apparel, accessories, and home goods from the same brand have a much thicker relationship and a much higher cost of switching. Rewarding a bonus for purchasing from a third category in a rolling window -- "Buy from 3 categories this month, earn 500 bonus points" -- directly incentivizes the behavior that predicts retention, not just the behavior that generates revenue today.
Referrals are the highest-ROI earning mechanic per point awarded, because a referred customer arrives with social proof behind them and lower acquisition cost. The failure mode in referral mechanics is rewarding the referrer immediately on signup rather than on first purchase. A program that awards 500 points the moment the referred customer creates an account is a program that generates fake account creation. Reward 250 points on referred account creation and the remaining 750 points on the referred customer's first purchase above a minimum order value. This structure pays out only on genuine conversions.
Review submission with an incentive generates user-generated content that drives conversion for new visitors and gives the brand behavioral signal about product satisfaction. The incentive needs to be available for honest reviews, not just positive ones -- a program that only rewards five-star reviews creates a biased review corpus that customers see through quickly. Award the points on any verified review submission, and let the review content be unfiltered.
Purchase frequency bonuses -- 1.5x points on a second purchase within 30 days, 2x points on a third -- create a short-window incentive that drives repeat purchase without requiring a deep discount. The multiplier costs margin only when customers take the repeat action you wanted them to take, unlike a blanket discount that applies regardless of whether the customer would have bought anyway.
Cart abandonment: the failure mode that discounts make worse
The standard cart abandonment recovery playbook -- trigger a 10% discount email 24 hours after abandonment -- trains a segment of customers to abandon carts deliberately, knowing the recovery email is coming. This is a well-documented behavioral pattern and an expensive one to sustain at scale.
Loyalty-based cart recovery inverts this. Instead of "here is a discount for the cart you abandoned," the message is "complete this order and earn 3x points today" or "you are 150 points from Gold status -- this order would get you there." The customer receives a reason to complete the purchase now, tied to accumulated progress rather than a one-time discount. The points cost is lower per-unit than a 10% discount, the customer does not receive a perverse incentive to abandon again, and the completion behavior is attributed to loyalty engagement, which strengthens the relationship.
The status progress message -- "this order would move you to Gold tier" -- is the highest-converting variant for customers within range of a tier upgrade. It works because it makes visible an opportunity cost: not completing the order means missing out on something that took months to accumulate. The same principle applies to expiring points reminders: "You have 400 points expiring in 7 days" reliably drives redemption behavior because loss aversion is a stronger motivator than equivalent gain.
The platform decision: when Smile.io is enough and when it isn't
For Shopify brands running standard points-per-dollar programs with tier structures, Smile.io at $49 to $599 per month is a legitimate choice. It handles points earning, tier tracking, basic reward catalog, and Klaviyo integration without requiring engineering effort. LoyaltyLion at $199 to $699 per month offers more API flexibility for custom mechanics. Yotpo bundles loyalty with reviews and referrals in a single platform, which simplifies integration at the cost of per-feature flexibility.
The constraint with all three is that you are building inside someone else's data model. Unique earning mechanics, non-standard tier logic, custom reward types, and advanced anti-gaming controls require either workarounds within the platform's configuration or custom code that sits outside it. When the loyalty program needs to know about events that do not originate in Shopify -- a subscription renewal, a mobile app action, an in-store visit at a physical location, a behavior captured in a CRM -- the platform integration becomes the bottleneck.
Build custom when the loyalty program is the product differentiator, not a feature. For a brand where exclusive access, community, and personalized rewards are core to the value proposition -- where customers choose you partly because of the loyalty experience itself -- a third-party platform imposes ceiling on what the program can do and a floor on what it costs per transaction as you scale. The build vs. buy framework for this class of decision applies directly: buy when the commodity tool fits the workflow, build when the workflow is the competitive advantage.
For headless commerce stacks (custom frontend with a commerce API), an API-first loyalty platform like Antavo, Open Loyalty, or Talon.One fits more naturally than Smile.io, which assumes Shopify's checkout and account flow. If neither fits cleanly, a custom build starting around $40,000 to $80,000 gives full control over the ledger, the tier logic, and the integration surface.
Anti-gaming: the controls that need to exist before launch
A loyalty program is a financial instrument. It has economic value that can be extracted by adversarial users, and the extraction patterns are predictable enough that most of them can be controlled at design time rather than discovered in production.
Buy-earn-return cycles are the most common. A customer buys $200 worth of items, earns 600 points, returns the items for a full refund, and keeps the points. Settlement delay on earned points -- making points available only after the return window closes -- eliminates this without any fraud detection complexity. The ledger implementation makes this straightforward: points enter pending_balance at purchase and move to available_balance after the settlement period.
Referral manipulation -- creating multiple accounts to self-refer and earn referral bonuses -- is controlled by requiring phone verification on new accounts, linking referral bonuses to the referred account's first purchase rather than account creation, and flagging accounts where the referred email domain or device fingerprint matches existing accounts. None of this requires sophisticated fraud infrastructure at launch; it requires designing the referral earning rules to not pay out until genuine conversion is demonstrated.
Velocity limits on non-purchase earning prevent review farming (creating low-quality reviews at high volume to earn points) and social share gaming. A member should not be able to earn more than a defined daily cap from non-purchase actions. The cap should be low enough to prevent farming and high enough not to penalize genuine engagement.
For the broader design space of gamification mechanics -- challenges, streaks, and time-limited bonus structures that complement the base tier system -- the mechanics and data model decisions in gamified loyalty program design cover the engagement layer in more depth than this post does.
Measuring what actually matters
The metric that reveals most honestly whether a loyalty program is working is the gap between enrolled and active. Active is defined as a member who has taken a loyalty-motivated action in the last 90 days: earned points, redeemed a reward, or progressed toward a tier. A program with 50,000 enrolled members and 12,000 active members has a 24% activation rate, which means 38,000 enrolled customers are getting no behavioral impact from the program.
The activation gap is where ROI disappears. A member who enrolled and never engaged is not cheaper to retain than a non-member -- they are identical. The program is not changing their behavior. The design response to a low activation rate is almost never "add more rewards." It is almost always one of three things: the first-tier threshold is too high and new members cannot see a path to earning anything meaningful within their natural purchase cycle, the redemption UX is confusing or requires steps that feel like friction, or the non-purchase earning mechanics do not exist or are not communicated.
Comparing member LTV to non-member LTV directly overstates program impact due to selection bias: your best customers self-select into loyalty programs regardless of what the program offers. The correct comparison is a matched cohort study -- members against non-members with similar acquisition date, channel, and initial purchase behavior. That comparison isolates the behavioral impact of the program from the pre-existing quality of the customers who joined it. Incrementality testing, where loyalty communications are suppressed for a 5 to 10% control group and behavioral differences are measured, gives the cleanest signal of how much the program is actually moving the needle versus how much the enrolled customers were going to buy from you anyway.
Closing thoughts
The technical decisions that determine whether an e-commerce loyalty program increases LTV are simpler than the product design decisions, but they are the ones that are most expensive to get wrong late. A points ledger built as a balance field, settlement delay absent, and anti-gaming controls retrofitted after the first fraud incident is a much more expensive program to operate than one designed correctly from the start. The product design question -- discounts versus exclusivity, tier calibration, which behaviors to reward -- is genuinely harder and more context-dependent. But it only matters if the data infrastructure underneath it is built to support auditing, attribution, and iteration. If you are working through tier threshold calibration or the build-vs-buy decision for your commerce stack, I am curious what constraints are shaping the design.
About the author
- RaftLabs is a digital product and software development company that helps businesses build web applications, mobile apps, SaaS platforms, and AI-powered tools. The company focuses on combining design, engineering, and product strategy to create scalable digital experiences for startups and enterprises.
Comments
Join the discussionNo comments yet. Be the first to comment.




