A loyalty program needs more than a points balance
A customer makes a purchase, earns points, and sees a reason to return. That is the simple promise of a loyalty program. Delivering on it takes more than a promotional widget: the business needs reliable earning rules, rewards it can actually fulfill, a clear member experience, and reporting that connects activity to completed orders.
RAS Loyalty Engine brings those pieces into a workspace for managing programs, rewards, members, experiences, and reports. The opportunity is not simply to issue more points. It is to make repeat engagement easier to understand, easier to operate, and easier to evaluate without letting incentives become uncontrolled discounting.
This guide walks through the feature set and the operational decisions behind it. The illustrations explain the workflows; they are conceptual visuals, not product screenshots or measured business results.
1. Build programs with clear operating rules
Teams can create and name programs, give their points currency a recognizable name, and manage programs as draft, live, paused, or archived. A duplicate action provides a starting point for a variation without rebuilding every setting. That makes it possible to prepare a program before launch and keep its lifecycle visible afterward.
Optional point expiry adds another policy decision. A business can define how long points remain valid or leave expiry unset. When expiry applies, the system accounts for remaining unspent earnings, with older points consumed first. The purpose is to expire the balance still attributable to an old award, not subtract the original award again after some of it has already been spent.
For operators, these settings establish the foundation: what the program is called, when it is available, and what members should expect from the value they accumulate.
2. Reward verified purchases and configured customer actions
Earning rules support fixed point awards and points based on spending. Conditions can distinguish first purchases from repeat purchases, set a minimum order amount, match products or categories, and apply to all, new, or returning members. Individual rules can be enabled or disabled as the program evolves.
The verified integration supports completed purchases, account signups, newsletter signups, and custom events. Additional behaviors need an appropriate trusted integration; an event name alone does not prove that a customer performed the action. Spendable points should follow verified activity, not an unverified browser signal.
Purchase settings also define the eligible spending basis. A store can use merchandise value after discounts, excluding tax and shipping, or the final order total including tax and shipping. Currency settings keep the program aligned with the store. These choices matter because two programs advertising the same earning rate can have different costs if they calculate eligible spending differently.
Consider an illustrative program awarding one point per eligible dollar. A purchase with $80 of eligible merchandise would earn 80 points under that rule. Whether shipping contributes to the award depends on the configured basis. This is an example of program design, not a default rate or a forecast of customer behavior.
3. Keep earning tied to a trustworthy customer identity
A points balance is only useful if it belongs to the right person. Loyalty Engine uses verified member context and server-confirmed commerce activity to connect wallets, orders, and rewards. Duplicate-event and duplicate-order protections help prevent a retried integration call from becoming an extra award.
The public experience and the personal wallet serve different purposes. Visitors can discover the program and reward catalog, while verified members receive their own balance and reward information. If identity verification fails, stale personal context is cleared and the experience returns to the public catalog.
That distinction protects the integrity of the program. An email address entered into a browser is not, by itself, permission to access another member's wallet.
4. Create a reward catalog with commercial controls
The catalog supports percentage discounts, fixed-amount discounts, free shipping, and free products. Each reward can have a name, identifying key, image, point cost, and configured value. Teams can set an expiry period, overall usage limits, a per-member maximum, and available inventory, then manage the reward as active, paused, or archived.
These controls let the business shape an offer around its economics. A low-point reward can make the first redemption approachable, while a more valuable reward can require a larger balance. Inventory and redemption allowances give operators a way to constrain availability instead of assuming every incentive can remain open indefinitely.
Catalog availability does not mean every store connector can deliver every reward type. Fulfillment must be supported and configured in the connected store. For example, the current WooCommerce connector supports fixed and percentage coupons for registered, signed-in customers, but not guest checkout, free-shipping rewards, or free-product rewards.
5. Separate reward claims from completed reward use
Claiming a reward and purchasing with it are different events. A claim spends the required points and issues a reward. A completed use is recorded when the reward is linked to a completed order. Expired and cancelled rewards remain separate outcomes.
Loyalty Engine keeps issued reward codes persistent. Reopening the wallet should show the reward already issued, rather than create a fresh code. Issued rewards retain their recorded value and currency, and repeated issuance requests are protected against creating duplicate rewards.
Teams can work with generated codes or an imported coupon pool. In either case, the checkout must recognize and enforce the offer. A code stored in RAS does not automatically become a valid discount in an unrelated commerce platform. Redemption readiness therefore includes a verified order and confirmation that reward fulfillment has been configured.
6. Give members a visible, branded rewards experience
The floating Rewards button can sit at the bottom left or right of the site. Teams can adjust its label, welcome copy, headline, brand colors, and button colors. Balance badges and next-reward progress help members understand both what they have earned and what they are working toward.
An inline hub can place the experience in an account or cart area through a configured slot. A member-opened, keyboard-accessible dialog provides another way to explore rewards without requiring a separate destination for every interaction. Catalog visibility, redemption availability, and email requirements can be managed through experience settings.
The workspace also exposes notification preferences for onsite point updates, reward-unlock alerts, and reward-code email where delivery is available. These options should be configured alongside the actual integration and delivery capability, rather than treated as a guarantee that every channel is connected.
The practical objective is clarity: members should be able to find their balance, see available rewards, understand the next step, and return to an issued code when they need it.
7. Manage members and resolve balance questions
The Members area gives authorized teams a place to find wallets, review balances, and inspect point activity. The ledger distinguishes earning, redemption, expiry, and adjustments, providing context when a customer asks why a balance changed.
Administrative adjustments include a reason, helping support teams record the basis for a correction. Members can be suspended and reactivated, and duplicate member records can be merged within the same program. Active, suspended, and merged states make those changes visible.
This operational layer matters because loyalty creates customer expectations. Staff need an explainable record, not only a number on a screen. Access is scoped to the authorized client and site so that member information is not treated as a shared directory across unrelated businesses.
8. Connect the store and confirm readiness before launch
Guided setup brings together store preferences, the existing RAS loader, database readiness, credentials, a program, verified member and purchase activity, fulfillment confirmation, and a reward-use test. Teams can resume setup and provide a developer handoff when technical work is needed.
Managed pairing uses a short-lived connection code, server credentials, and the store origin. Connections can be revoked. Reusing the shared RAS loader avoids installing a second copy solely for loyalty, but the loader is not a replacement for the server-side commerce integration.
- WooCommerce: Supports registered customer identity, paid-order verification, and customer-restricted, single-use fixed or percentage coupons. The current connector does not cover guest checkout or every catalog reward type.
- Shopify: Includes a server adapter and theme-extension scaffold that require a hosted, authenticated app and developer deployment. This is not a one-click public app installation.
- Custom PHP stores: Require developers to connect verified identity, completed orders, and checkout reward enforcement to the application.
The launch test should follow the whole chain: sign in as a member, complete a qualifying order, confirm the award, claim a supported reward, and verify its use on a subsequent completed order.
9. Classify test orders without confusing testing with a sandbox
URL-based test sessions let configured query parameters opt a browser into a marked testing session. Available durations include a browser session with an eight-hour maximum and fixed one-, four-, eight-, or twenty-four-hour windows. A visible banner and an End test session control make the state clear, and test classification is carried into order creation.
This helps teams separate real, test, and combined order activity in purchase reports. It does not make checkout financially harmless. A test-classified order can still charge a payment method, trigger fulfillment or email, and affect points or rewards. Payment-provider sandbox settings and operational safeguards must be configured separately.
10. Measure purchasing behavior and compare periods
Reports support site and date filters, real or test order selection, and comparisons with the previous equal-length period or the corresponding dates in the previous year. Teams can review revenue, average order value, discount totals, purchasing members, repeat purchaser rate, and orders using rewards.
Daily order and revenue charts make timing easier to inspect, while currencies remain separate. The reported revenue is the stored final order total after discounts, including tax and shipping. It is not profit, a refund-adjusted accounting figure, or proof that the loyalty program caused the purchase.
Repeat purchaser rate describes purchasing members who have an earlier recorded purchase in the selected order population. That answers a useful operational question, but it is different from cohort retention. Keeping the definitions clear prevents an attractive percentage from answering the wrong business question.
11. Understand second purchases and the time between orders
Thirty-, sixty-, and ninety-day second-purchase cohorts group members by the month of their first recorded purchase. A cohort window is evaluated only when enough follow-up time exists. Newer groups remain awaiting data rather than being presented as failed repeat purchasers.
Median time between orders adds a view of purchase cadence. For a replenishment business, it can help frame when a return visit is normal. For a seasonal retailer, it can support a different conversation about timing. The result is a starting point for interpretation, not a universal reminder schedule.
These measures depend on the history recorded in RAS. A first recorded order is not necessarily the first order the customer ever placed if older commerce history has not been connected.
12. Follow reward outcomes, engagement, and outstanding points
Reward reporting separates completed-order revenue, discounts, order counts, and average order value from the issuance lifecycle. The lifecycle view tracks issued rewards, completed uses, rewards still available, rewards expired unused, cancellations, and completed-use rate. Recorded use requires a linked order, not merely an administrative status.
Member reporting includes new profiles and first earning, first claim, and first use milestones. Those are independent counts, not a conversion funnel. Profiles may be created automatically, so a new profile should not be interpreted as a voluntary loyalty signup.
Current outstanding points stay separated by program and exclude merged wallets. Signed ledger movements show how balances changed without pretending to calculate financial liability or infer refund reversals.
Scope labels are important here. Reward lifecycle, points, and engagement reporting include real, test, and legacy activity even when purchase charts are filtered to real orders. Lifecycle reporting follows issue dates and current reward status, which can include use after the selected period.
13. Find customer opportunities that deserve attention
Reports turn several patterns into current member lists that a team can inspect:
- Near a reward: Members with at least 80% of the points needed for a reward.
- Unused reward: Members with issued rewards that have not yet been used.
- Expiring soon: Members with unused rewards expiring within fourteen days.
- Time to return: Members with no recorded purchase in sixty days.
Each group suggests a different operational question. Is the next reward clear? Is checkout redemption difficult? Does the customer know a reward is expiring? Is a sixty-day gap unusual for this business? These lists support investigation and planned follow-up; they do not automatically send outreach.
The lists are current snapshots rather than historical segments restricted to the selected reporting dates. Only the overdue-purchaser group follows the real or test order filter. Being near a reward also does not guarantee eligibility, remaining stock, or an unused redemption allowance.
14. Take useful evidence into operational reviews
Highest-spending member drilldowns and underlying order rows help teams move from a summary to individual examples. Authenticated CSV exports retain filters and scope labels so the exported view remains understandable outside the workspace.
The export is a report snapshot, not an unlimited raw-data download. Recent-order rows are limited to 100; highest-spending member rows and each opportunity list are limited to 50. Aggregate counts are not truncated by those table limits.
For a marketing, support, and finance review, the most useful discussion connects several views: outstanding points, reward availability, completed reward uses, repeat purchases, and discount cost. That gives the team evidence for adjusting the program without confusing participation with profitability.
How Loyalty Engine fits the wider RAS workflow
Loyalty data becomes more useful when the team also understands the experience around it. JourneyLens can support investigation of a difficult account or checkout journey. Voice of Customer can help collect feedback on why a reward feels unhelpful. SiteMetrics can add context about the pages and campaigns bringing visitors back, while Optimize can support testing changes to the experience.
Those are complementary uses of separate RAS modules, not a claim that every loyalty event automatically triggers another product. Abandonment Recovery and loyalty also address different moments: one helps the business respond to an unfinished journey, while the other gives an identified customer a continuing reason to engage. Any connected campaign or custom earning behavior still needs explicit configuration and appropriate verification.
Start with a program the business can explain and fulfill
A practical rollout starts small: one clear program, verified earning, a supported reward, a usable wallet, and a completed reward-use test. From there, teams can review purchasing patterns, inspect unused rewards, and adjust earning or catalog settings as evidence develops.
The complete value of Loyalty Engine is the connection between those steps. Program controls define the promise. Verified activity makes balances trustworthy. Reward and member tools make the promise manageable. Reports show what happened and where to investigate next.
Loyalty Engine does not turn points into guaranteed incremental revenue. It gives the business a more disciplined way to operate loyalty, make the customer benefit visible, and evaluate repeat engagement using recorded behavior. That is a stronger foundation than a points counter that nobody can connect to a completed customer journey.