Shopify retention audit
Diagnose retention before you build a program
A Shopify retention audit checks repeat purchases, order value, reorder timing and customer reach to decide what to work on next. Run it in Shopify Sidekick, then bring the audit into ChatGPT to prepare changes with Joy MCP and Klaviyo MCP. Review what will change before anything is saved.
Loyalty is not always the answer. Start with your store’s data.
Find what brings your customers back
A points program is one option. Your store may need a better second-order email, a replenishment offer or a stronger first purchase experience. The audit starts with that decision.
Read the evidence, check what is missing and choose the next step. If rewards fit, use Joy to shape the program and widget around your brand. If lifecycle timing comes first, prepare the segments and draft flows in Klaviyo.
From your audit to approved changes
Sidekick diagnoses. ChatGPT prepares the review. Joy and Klaviyo then build through MCP (Model Context Protocol) connections, only after you approve the exact changes.
01
Diagnose in Shopify Sidekick
Copy the retention-audit skill below into Sidekick, save it as a skill and run it in your Shopify admin. Review the findings and missing data before choosing what to build. Sidekick does not call external MCP servers.
/retention-audit
02
Prepare changes in ChatGPT
Bring the audit into ChatGPT with the retention architect skill. Connect Joy MCP and Klaviyo MCP for the work you need. Ask for exact changes to review, including reward costs, segment rules and flow timing. Nothing is saved before approval.
03
Approve the build, then review it
After you approve the exact changes, Joy MCP builds loyalty configuration and a widget draft. Klaviyo MCP builds segments and draft flows. Read back the saved changes. Publishing the widget, activating a flow and sending campaigns each need separate approval.
Copy the skills into Sidekick
Start with /retention-audit. Use /loyalty-program only when the audit supports a loyalty program. Read each card, copy its instructions into a Sidekick skill and use the matching shortcut. These cards load the current files from GitHub.
/retention-audit
4,964 / 5,500 chars
Audit the retention
Diagnoses. Names the one constraint that binds, and is allowed to conclude that no program is needed.
Audit this store's retention and report what the data says. Diagnose only — do not design a loyalty program, and do not recommend one unless the evidence points there. MEASURE 1. Purchasers = customers with at least one order. Repeat = customers with two or more. second-purchase rate = repeat / purchasers. 2. Report the total customer-record count NEXT TO the purchaser count. Most stores hold far more records than buyers (email captures, account signups). Dividing by total records understates the rate several-fold and aims the whole strategy at the wrong problem. 3. Use the order's PROCESSED date for every window, sort and interval. The created date is when the row was written; on any migrated or imported store the two diverge and a year of trading collapses into however long the import took, silently. 4. Sanity-check before reporting: a stricter percentile must have a HIGHER threshold, so the top-4% spend figure cannot be below the top-15% figure. If it is, the query is wrong. Report reorder gaps in DAYS, not weeks — a flow fires on a day. 5. Also collect: orders per purchaser; time to second order as p25 / median / p75; AOV split into first orders vs repeat orders; share of revenue from repeat orders; trailing-12-month spend per purchaser at the top 15% and top 4%; share of orders carrying a discount, split first vs repeat; top products and whether bundles carry more basket than single items. THREE CHECKS THAT CONSTRAIN WHAT YOU MAY RECOMMEND - Email/SMS consent among PURCHASERS — divide by purchasers, not by total records. The denominator rule applies to every rate in the report, not only the repeat rate. If most purchasers are not subscribed, the first job is consent capture and any flow you propose reaches almost nobody. - Whether a loyalty or subscription app is already installed and what it is actually doing — how many members, what has actually been issued, whether rules are switched on. Proposing a program the merchant already runs destroys credibility. - Whether any selling plan exists. On a catalog with a monthly consumption cycle, the absence of a subscription mechanism is itself a headline finding, not a footnote. TWO TESTS BEFORE YOU CONCLUDE Cadence vs basket. A tight repeat gap says "subscription". But check how often a second order contains a product from the first. Tight cadence with low same-product repeat means customers keep a rhythm while rotating items — that is a FLEXIBLE subscription, not subscribe-and-save on a hero SKU. Reporting only the cadence leads to the opposite build. Artifact vs behaviour. If most records never purchased, the naive reading is an activation problem. Test it before saying it: compare the spread of customer creation dates against the spread of order dates — a real store accumulates both together. Check whether non-purchasers differ systematically from buyers (all created the same week, or better email consent than buyers). If they do, they are an import artifact and must be excluded from every rate, not called a dormant audience. VERDICT Name the ONE constraint that binds, and say which of these the evidence supports: - First-order conversion or traffic — acquisition, not retention - Basket too small to fund anything — AOV, bundles, thresholds - Product repeats but buyers stop after order one — lifecycle timing, aimed at the window just BEFORE the median gap - Predictable replenishment — subscription - Organic repeat and margin already exist — then, and only then, loyalty - Nothing yet — say so Loyalty is not the default answer. If repeat behaviour is already healthy without a program, say that plainly and name what would actually move the number. STOP IF THE DATA CANNOT ANSWER If no customer has a second order, then repeat rate, time-to-second, repeat AOV and any at-risk or lapsed segment are structurally unfillable. Report what you did measure, say the dataset cannot support a verdict and what is missing, and stop. A long report whose headline metric is 0% reads as authoritative while saying nothing. OUTPUT - Verdict: the binding constraint, in one sentence - Evidence table: metric, value, window, and where it came from - Three to five findings, each a sentence a merchant could act on - Segments with real counts: one-time within the reorder window, one-time past it, active repeaters, at-risk, lapsed, subscription-shaped (three or more orders at a stable gap) - What you could not measure, and what would change the answer Never invent margin, ad spend, CAC, reorder cadence or industry benchmarks. Ask for margin and ad spend if the recommendation needs sizing; if unavailable, label the recommendation unsized rather than guessing. Keep measured figures separate from anything modelled. Close by naming the next step the verdict implies — the flow to build, the subscription to offer, the program setting to fix — so the merchant knows what to do, not just what is true.
/loyalty-program
5,491 / 5,500 chars
Design the program
Runs only once a verdict has earned it. Sizes tiers and rewards from this store’s own numbers.
Design a loyalty program for this store from its own data. Audit retention first: if evidence points at acquisition, basket size, lifecycle timing or subscription, say so and stop. A program built on the wrong diagnosis quietly costs margin for a year while the number it was meant to move stays flat. FIRST, CHECK WHAT ALREADY RUNS Read whether a loyalty app is installed, how many members it has, and what it has issued. Diagnose that program rather than designing over it: proposing one the merchant already runs ends the conversation. DERIVE EVERY NUMBER FROM THIS STORE If you cannot point at the figure that produced a threshold you are guessing; say so rather than presenting it as designed. Never copy another brand's dollars: they carry that brand's basket and order frequency with them. Tier thresholds. Compute trailing-12-month spend per purchaser, sort descending, read the figure at the top 15% (tier 2) and top 4% (tier 3). Round to a number a human would say: $150, not $147. Check the revenue share each slice holds: if the top 4% holds a fifth of revenue the perks are affordable; if the top decile holds barely a third there is no whale class, so use three tiers. Sanity-check first: a stricter percentile must carry a HIGHER threshold, so the top-4% figure cannot be below the top-15% figure. If it is, the query is wrong, and that error propagates into every perk and cost estimate downstream. First rung from AOV, reachable in one or two orders. Point expiry from the median gap between orders: two to three times it, never sooner, and warn first. Referral minimum order above AOV, or the reward subsidises a below-average basket. TIERS ARE EARNED BY SPEND, NEVER BY ACCUMULATED POINTS The most common error, and self-defeating: if status runs on the same points members spend, redeeming a reward demotes them. Members hoard, the currency stops circulating, the program inverts its purpose. Spend sets status; points are for spending. Trailing 12 months, not a calendar-year reset. THE ARITHMETIC redemption_ROI = (reward_value / (units_required / earn_rate)) x 100 ~1% is the safe default. Richer can be right, but that is a margin decision: state the cost as a percentage of revenue rather than burying it in a points table. Where 1% and "reachable" collide. Below a certain basket they are incompatible: at $58 AOV two orders earn 116 points at 1 per dollar, which at 1% buys a $1.16 reward. Nobody joins for that. Name the lever you pull: make the first rung NON-MONETARY (free shipping, a sample, early access carry perceived value above marginal cost, sidestepping the ratio; usually right on a low-AOV catalog), or run richer than 1% and say the number out loud. Moving the rung further out does NOT work: five orders at $58 is $290, still $2.90. Distance cannot rescue a rate too thin for the basket. Never quietly ship a $1 reward, nor keep the 1% label while the ladder pays 5%. Ladder shape. At least five rungs. Keep monetary rungs on a flat arithmetic step so the next reward is always the same distance away; geometric spacing makes each feel further than the last, the opposite of what a ladder is for. Hold redemption ROI FLAT across monetary rungs: if it rises you have built an incentive to hoard. Put escalation in the tier multiplier, which rewards sustained spend rather than a sitting balance. Top rung not convertible to money. Ranges: earn 1-5 units per $1; signup bonus $0.50-1.00 of value; referral $8-15 each side; multiplier steps of ~0.25x. Read a multiplier as cost: a 1% base at 1.5x pays 1.5% on your best customers. Cap what a member earns without buying below the first rung, or you have built a way to farm rewards. IF CONTRIBUTION MARGIN IS UNAVAILABLE Do not dead-end, and do not invent one. Design at a stated planning assumption, labelled as an assumption not a finding. Show what changes if it is wrong: cost as a share of revenue at a low, middle and high margin, plus the break-even repeat-rate or AOV lift at each. Make margin confirmation a launch gate: designed now, live once the merchant confirms it is affordable. PIN THESE DOWN, OR SOMEONE DECIDES THEM SILENTLY - What earning applies to: post-discount merchandise subtotal, excluding tax, shipping and gift cards. Earning on the pre-discount total lets a sitewide sale inflate every balance. - How the multiplier compounds: it multiplies the EARN RATE, not redemption value. Left undefined, implementations have shipped at 6% by stacking both ends. - Product rewards costed at COGS, shown at retail: that gap is why they beat dollars off. State both. - Breakage: from the incumbent program's history if there is one; otherwise model a band, not a point estimate, and track liability monthly. - Redemption stacking: whether a reward rides on a discount code, bundle price or subscription discount. The most expensive unstated rule. - Eligible SKUs by name, preferring high retail-to-COGS items with stock depth. "Free full-size product" is not buildable. - Capacity for any experiential rung: how many a month, who delivers it, what happens when demand exceeds supply. OUTPUT Tier table with thresholds and the percentile each came from; reward ladder with units, value and ROI per rung; earning and mission values with the no-purchase cap; referral terms; expiry; the definitions above; cost as a share of revenue with the margin assumption stated; and the first three things to measure after launch. Keep measured figures apart from modelled ones.
Keep diagnosis and program design separate so the audit can recommend something else. These Sidekick skills do not connect to external MCP. For the next stage, open the retention architect skill and setup instructions and bring the audit into ChatGPT with the relevant MCP connections.
See the full walkthrough
Follow the demo from Shopify analytics to a review in ChatGPT, then see the branded loyalty program. Select any image to open the full screenshot in a new tab.
These screenshots come from a password-protected Shopify development clone built with Ritual’s public storefront assets for this walkthrough. It is not Ritual production, and there is no affiliation or endorsement. The figures are demo data, not benchmarks or evidence of a retention lift.
| Metric | Value | Source / basis |
|---|---|---|
| Gross sales | $97.9K | Shopify dashboard |
| Fulfilled orders | 1,600 | Shopify dashboard |
| Average order value | $61.24 | Shopify dashboard |
| Returning-customer rate | 35% | Shopify metric |
| Purchasers | ≈1,000 | Sidekick estimate |
| Repeat purchasers | ≈350 | Sidekick estimate |
| Purchaser repeat share | ≈35% | ≈350 ÷ ≈1,000 |
Shopify’s returning-customer rate and the estimated purchaser repeat share are separate measures. Neither is a benchmark. Confirm the reporting window and customer-level data before comparing rates or setting flow timing.
Bring the findings into ChatGPT
In this example, the proposed next step is a reorder flow, with rewards held for later review. ChatGPT prepares the segment, timing and settings to check. Nothing is saved before approval.
One loyalty program that carries your brand through
One visual system across sign-in, rewards home and member profile. The same typography, imagery and program identity carry through all three views of this demo program.
Sign-in
Introduce the program and show customers how to join.
Rewards home
Bring points, rewards and referrals into one place.
Member profile
Carry the same identity through to the member’s account.
All three screenshots are from the development clone, not Ritual’s live store. They demonstrate the look of one program, not a measured retention result or proof of publication.
Loyalty is not always the answer
Let the evidence decide where to start. The two Sidekick skills keep diagnosis separate from program design.
Acquisition or conversion
If too few visitors buy once, work on the first purchase before adding rewards.
Basket size
Check bundles, thresholds and offers when the basket cannot cover acquisition and reward costs.
Lifecycle timing
When customers are due to reorder, check the timing and reach of your follow-up messages.
Replenishment
Consistent same-product orders can point to a subscription. Check the actual reorder pattern first.
Loyalty
When repeat buying and margin support rewards, design a program around your customers and your brand.
Not enough evidence yet
If the data cannot support a decision, collect what is missing before building anything.
Approve what gets built
ChatGPT coordinates Joy MCP and Klaviyo MCP. Review the proposed changes before any write, approve one build at a time and check the saved result.
Joy MCP
Loyalty configuration and widget
Read the current program first. Prepare earning rules, rewards, tiers and a widget that fits your storefront. Review the proposed differences and costs before saving approved changes. The widget stays in draft until you set it live. Earning rules, rewards and tiers are different: once you approve them they change what every customer earns straight away, so check the costs before you approve, not after.
Klaviyo MCP
Segments and draft flows
Check existing segments, flows, consent and the exact customer properties available. Review triggers, exclusions, timing and offers before saving. Approved flows stay draft or inactive until you separately approve activation.
ChatGPT
Review and verification
ChatGPT coordinates the connected tools and presents the changes for review. It checks saved settings against what you approved and flags anything it cannot confirm. An approved plan is not permission to publish or send.
Nothing is saved before approval. Saving a draft does not publish it. Publishing a widget, activating a flow and sending campaigns each need separate approval. Earning rules, rewards and tiers have no second gate: they change what every customer earns as soon as they are saved.
The report
What your audit should make clear
A useful Shopify retention audit shows what the data supports, what needs checking and what you are being asked to approve.
Evidence you can check
Keep the value, source, reporting window and denominator beside each metric. Label estimates as estimates.
Segments with a clear basis
Show definitions and counts when the data supports them. Mark unavailable counts instead of filling in guesses.
Reorder timing
Use customer-level order dates to check the gap between purchases. A sales dashboard alone cannot set the day an email should send.
What to do next
Choose what to build now, what to revisit later and what to leave alone. Loyalty is not always the answer.
Missing inputs
Ask for margin, acquisition costs and data the store cannot provide. Keep unverified assumptions out of reward sizing.
Changes ready for review
List the proposed settings, draft content and approval needed for each action. Report what was saved and what remains inactive.
Frequently asked questions
A Shopify retention audit checks repeat purchases, order value, reorder timing and customer reach to decide what to work on next. This workflow starts in Shopify Sidekick, then brings the findings into ChatGPT to prepare changes for your review.
No. Sidekick diagnoses retention inside Shopify and does not call external MCP servers. You bring the audit into ChatGPT, where the connected Joy MCP and Klaviyo MCP tools carry out the approved build.
No. The audit and proposed changes are read-only until you approve the exact writes. Joy MCP can then save loyalty settings and a widget draft; Klaviyo MCP can save segments and draft flows. Publishing a widget, activating a flow and sending campaigns each require separate approval. One thing to know before you approve: earning rules, rewards and tiers change what every customer earns as soon as they are saved, and setting a widget live has no undo. Only the widget and the Klaviyo flows wait in draft.
Start with /retention-audit in Sidekick. Read the findings before using /loyalty-program to design a program, and use it only if loyalty fits the diagnosis. Both Sidekick cards load their instructions from GitHub. For the build, bring the audit and the retention architect skill into ChatGPT with the required MCP connections.
No. Loyalty is not always the answer. The next step can be acquisition, basket size, lifecycle messaging, replenishment or better data. If you already run a program, review its settings and results before proposing changes.
No. The screenshots come from a password-protected Shopify development clone built with Ritual’s public storefront assets for this walkthrough. It is not Ritual production, and there is no affiliation or endorsement. The figures are demo data, not benchmarks or evidence of a retention lift. The ChatGPT conversation is illustrative and does not show live tool actions.
Shopify displays a 35% returning-customer rate. Separately, Sidekick estimates about 1,000 purchasers and 350 repeat purchasers, giving an estimated purchaser repeat share of about 35%. These are different measures even though the displayed percentages match. Check their definitions, windows and underlying data before comparing them.
You can still run the Sidekick audit and review the proposed program or lifecycle plan. ChatGPT needs access to the relevant connected tools to save changes. Without that access, keep the output as instructions for review and manual setup.
Start with your customers. Build what fits your brand
Brands run loyalty on Joy
Shopify App Store rating
Merchant reviews