<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ayra Blog</title><description>Practical writing on Shopify retention: repeat purchase rate, loyalty design, reviews, referrals, subscriptions and the app stack behind them.</description><link>https://ayra.one</link><language>en</language><atom:link href="https://ayra.one/rss.xml" rel="self" type="application/rss+xml"/><item><title>Why we built Ayra</title><link>https://ayra.one/blog/why-we-built-ayra</link><guid isPermaLink="true">https://ayra.one/blog/why-we-built-ayra</guid><description>We spent years gluing Shopify retention apps together for clients. The problem we kept meeting, why the customer record comes first, and what is in beta.</description><pubDate>Wed, 14 Oct 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;I have been building on Shopify for over ten years, first as a developer, then as the person agencies call when the stack stops making sense. For the last few of those years, almost every engagement we took at &lt;a href=&quot;/about&quot;&gt;Tetralogicx&lt;/a&gt; that had “retention” in the brief followed the same script. This post is about that script, and why we decided to stop running it by hand.&lt;/p&gt;
&lt;h2 id=&quot;the-audit-we-ran-every-time&quot;&gt;The audit we ran every time&lt;/h2&gt;
&lt;p&gt;A merchant would come to us with a reasonable goal: get more second orders. The first week was always an audit of what was already installed. The list rarely varied much. A loyalty app. A reviews app. A wishlist app, sometimes with back-in-stock bolted on. An email tool with its own flows. Often a subscriptions app. Occasionally a referral app that was separate from the loyalty app, even though both of them handed out rewards.&lt;/p&gt;
&lt;p&gt;Each of these apps was good at its job. That was never the problem. The problem was that each one had built its own picture of the customer. Loyalty knew the points balance but not that the customer had left a one-star review last week. Reviews knew about the review but not that the customer was a VIP. The wishlist app knew what the customer wanted but had no idea a win-back discount was going out that afternoon.&lt;/p&gt;
&lt;p&gt;Six apps, six partial customers. And at the end of the month, six dashboards, each attributing the same orders to itself.&lt;/p&gt;
&lt;aside class=&quot;ay-callout border-l-[3px] px-5 py-4 text-[0.95em] border-border-strong bg-overlay&quot; role=&quot;note&quot;&gt; &lt;p class=&quot;ay-eyebrow !text-[11px] text-fg&quot;&gt;&lt;svg xmlns=&quot;http://www.w3.org/2000/svg&quot; width=&quot;14&quot; height=&quot;14&quot; viewBox=&quot;0 0 24 24&quot; fill=&quot;none&quot; stroke=&quot;currentColor&quot; stroke-width=&quot;2&quot; stroke-linecap=&quot;round&quot; stroke-linejoin=&quot;round&quot; class=&quot;text-accent-fg&quot; aria-hidden=&quot;true&quot; focusable=&quot;false&quot;&gt;&lt;circle cx=&quot;12&quot; cy=&quot;12&quot; r=&quot;10&quot;/&gt;&lt;path d=&quot;M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3&quot;/&gt;&lt;path d=&quot;M12 17h.01&quot;/&gt;&lt;/svg&gt; What this looked like in practice&lt;/p&gt; &lt;div class=&quot;mt-2 [&amp;&gt;*+*]:mt-3&quot;&gt;&lt;p&gt;One store we worked with sent a review request, a referral nudge and a 15% win-back offer to the same customer within a single Tuesday. Three apps, three good ideas, nobody in charge of the whole conversation.&lt;/p&gt;&lt;/div&gt; &lt;/aside&gt;
&lt;h2 id=&quot;the-glue-we-kept-writing&quot;&gt;The glue we kept writing&lt;/h2&gt;
&lt;p&gt;So we wrote glue. That was the engagement, really. Sync points balances into customer tags so the email tool could segment on them. Suppress review requests for anyone with an open support ticket, which meant polling the helpdesk and writing tags again. Delay the referral push if a discount had gone out in the last few days. Reconcile the revenue reports so the merchant could see one number instead of six.&lt;/p&gt;
&lt;p&gt;Some of it was Shopify Flow. Some of it was small apps we hosted. All of it was fragile, because it sat between tools that did not know it existed. When a vendor changed a webhook payload, the glue broke. When the merchant’s team changed a flow in the email tool, the glue broke. And when we rolled off the project, nobody was left who understood it.&lt;/p&gt;
&lt;p&gt;We did this enough times to notice two things. First, the glue was the same from store to store. The names of the apps changed; the logic did not. Second, every piece of it existed to compensate for one missing thing: a single customer record that all the retention logic could read from and write to.&lt;/p&gt;
&lt;h2 id=&quot;the-customer-record-has-to-come-first&quot;&gt;The customer record has to come first&lt;/h2&gt;
&lt;p&gt;At some point the honest answer to “which app should we add next” stopped being an app name. The customer record has to come first. Loyalty, reviews, referrals, wishlist, subscriptions and flows are all things you do &lt;em&gt;to&lt;/em&gt; a customer, based on what you know &lt;em&gt;about&lt;/em&gt; that customer. If the knowledge is split six ways, the actions will collide.&lt;/p&gt;
&lt;p&gt;That is the whole idea behind Ayra. One profile per customer, resolved across email, phone, customer ID and device. Every module writes its signals to that profile and reads from it before it acts. And in front of the shopper, one decision layer that looks at everything the modules want to do and picks the single next best action, which can be nothing at all. We call that layer &lt;a href=&quot;/how-it-works#journey-guard&quot;&gt;Journey Guard&lt;/a&gt;, and it is the part we are most careful about, because it is the part that stops retention from turning into noise.&lt;/p&gt;
&lt;p&gt;We wrote the whole model up on the &lt;a href=&quot;/how-it-works&quot;&gt;how it works&lt;/a&gt; page, including the loop and a glossary of the guards. It is deliberately written to be read in a few minutes.&lt;/p&gt;
&lt;h2 id=&quot;what-is-in-the-private-beta&quot;&gt;What is in the private beta&lt;/h2&gt;
&lt;p&gt;We are not launching everything at once, and we would rather be clear about the order than pretend.&lt;/p&gt;
&lt;div class=&quot;ay-steps my-8&quot;&gt;&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;Loyalty &amp;amp; Rewards.&lt;/strong&gt; Points, store credit and VIP tiers, running on Shopify’s native store credit and discounts rather than a separate wallet. This is the module most of our clients needed first.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Referrals.&lt;/strong&gt; Two-sided rewards that read the same profile as loyalty, so a referral reward and a loyalty reward never double up.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Customer Account Hub.&lt;/strong&gt; The customer-facing side, built as customer account UI extensions rather than a separate portal.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Segmentation.&lt;/strong&gt; Segments built on the full profile: tier, lifecycle stage, intent, review history, open tickets.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Retention Analytics.&lt;/strong&gt; Repeat purchase rate, lifetime value, cohorts, and revenue attributed once per order across modules.&lt;/li&gt;
&lt;/ol&gt;&lt;/div&gt;
&lt;p&gt;Wishlist, back in stock, pre-order, reviews, subscriptions and lifecycle flows follow. The ones that come from products the team has already shipped, like our wishlist and back-in-stock work, will arrive faster than the ones we are building fresh.&lt;/p&gt;
&lt;div class=&quot;not-prose my-8&quot;&gt;&lt;a href=&quot;/features/loyalty&quot; class=&quot;group ay-card ay-card-link flex h-full flex-col gap-5 p-6&quot;&gt; &lt;div class=&quot;flex items-center justify-between&quot;&gt; &lt;span class=&quot;ay-icon-tile&quot;&gt;&lt;svg xmlns=&quot;http://www.w3.org/2000/svg&quot; width=&quot;20&quot; height=&quot;20&quot; viewBox=&quot;0 0 24 24&quot; fill=&quot;none&quot; stroke=&quot;currentColor&quot; stroke-width=&quot;2&quot; stroke-linecap=&quot;round&quot; stroke-linejoin=&quot;round&quot; aria-hidden=&quot;true&quot; focusable=&quot;false&quot;&gt;&lt;rect x=&quot;3&quot; y=&quot;8&quot; width=&quot;18&quot; height=&quot;4&quot; rx=&quot;1&quot;/&gt;&lt;path d=&quot;M12 8v13&quot;/&gt;&lt;path d=&quot;M19 12v7a2 2 0 0 1-2 2H7a2 2 0 0 1-2-2v-7&quot;/&gt;&lt;path d=&quot;M7.5 8a2.5 2.5 0 0 1 0-5A4.8 8 0 0 1 12 8a4.8 8 0 0 1 4.5-5 2.5 2.5 0 0 1 0 5&quot;/&gt;&lt;/svg&gt;&lt;/span&gt; &lt;span class=&quot;inline-flex items-center gap-1.5  border px-2.5 py-1 font-mono text-[10px] uppercase tracking-[0.1em] border-accent/40 bg-accent-soft text-accent-fg&quot;&gt; &lt;span class=&quot;size-1.5  bg-accent&quot; aria-hidden=&quot;true&quot;&gt;&lt;/span&gt; Private beta &lt;/span&gt; &lt;/div&gt; &lt;div&gt; &lt;h3 class=&quot;text-xl text-fg&quot;&gt;Loyalty &amp;amp; Rewards&lt;/h3&gt; &lt;p class=&quot;mt-2 text-fg-muted&quot;&gt;Points, store credit and VIP tiers that know who the customer is.&lt;/p&gt; &lt;/div&gt;  &lt;span class=&quot;ay-link text-sm&quot;&gt;Explore Loyalty &lt;svg xmlns=&quot;http://www.w3.org/2000/svg&quot; width=&quot;16&quot; height=&quot;16&quot; viewBox=&quot;0 0 24 24&quot; fill=&quot;none&quot; stroke=&quot;currentColor&quot; stroke-width=&quot;2&quot; stroke-linecap=&quot;round&quot; stroke-linejoin=&quot;round&quot; aria-hidden=&quot;true&quot; focusable=&quot;false&quot;&gt;&lt;path d=&quot;M5 12h14&quot;/&gt;&lt;path d=&quot;m12 5 7 7-7 7&quot;/&gt;&lt;/svg&gt;&lt;/span&gt; &lt;/a&gt;&lt;/div&gt;
&lt;h2 id=&quot;what-we-are-not-claiming-yet&quot;&gt;What we are not claiming yet&lt;/h2&gt;
&lt;p&gt;A few things we want to be straight about, because the category is full of claims that do not survive contact with a real store.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;The engine is rules, not a model.&lt;/strong&gt; At launch, opportunity types, eligibility and scoring are explicit rules you can read. Every decision has a reason recorded in the customer timeline. We will layer prediction on top of this later: churn, repeat-purchase likelihood, best send time. We are building the decision infrastructure first because a prediction with nowhere to act is just a report.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;We do not have lift numbers to show you.&lt;/strong&gt; We have years of agency work that tells us where the collisions happen and what fixing them did for individual clients, but we are not going to turn that into a headline percentage. When beta merchants have run on Ayra long enough to measure, we will publish what we see, with the method.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Switching is not free, even when migration is.&lt;/strong&gt; We import from the apps we replace, and migration is free during the beta. But moving a loyalty program is a customer-facing change and deserves a plan. Our &lt;a href=&quot;/compare&quot;&gt;comparison pages&lt;/a&gt; say where each app is genuinely better and when you should stay put, because we would rather lose a signup than a merchant’s trust.&lt;/p&gt;
&lt;div class=&quot;not-prose my-8&quot;&gt;&lt;a href=&quot;/compare/smile-io&quot; class=&quot;group ay-card ay-card-link flex h-full flex-col gap-4 p-6&quot;&gt; &lt;div class=&quot;flex items-center justify-between&quot;&gt; &lt;span class=&quot;font-mono text-[11px] uppercase tracking-wider text-fg-subtle&quot;&gt;Loyalty&lt;/span&gt; &lt;svg xmlns=&quot;http://www.w3.org/2000/svg&quot; width=&quot;18&quot; height=&quot;18&quot; viewBox=&quot;0 0 24 24&quot; fill=&quot;none&quot; stroke=&quot;currentColor&quot; stroke-width=&quot;2&quot; stroke-linecap=&quot;round&quot; stroke-linejoin=&quot;round&quot; class=&quot;text-fg-subtle transition-all group-hover:translate-x-0.5 group-hover:text-accent-fg&quot; aria-hidden=&quot;true&quot; focusable=&quot;false&quot;&gt;&lt;path d=&quot;M5 12h14&quot;/&gt;&lt;path d=&quot;m12 5 7 7-7 7&quot;/&gt;&lt;/svg&gt; &lt;/div&gt; &lt;div&gt; &lt;h3 class=&quot;text-xl text-fg&quot;&gt;Ayra vs Smile.io&lt;/h3&gt; &lt;p class=&quot;mt-2 text-fg-muted&quot;&gt;a loyalty and referral program app for Shopify with points, VIP tiers and a free plan to 200 orders.&lt;/p&gt; &lt;/div&gt; &lt;p class=&quot;mt-auto border-t border-border pt-4 font-mono text-[11px] uppercase tracking-wider text-fg-subtle&quot;&gt;Compared 2026-10-14&lt;/p&gt; &lt;/a&gt;&lt;/div&gt;
&lt;h2 id=&quot;why-an-agency-is-building-this&quot;&gt;Why an agency is building this&lt;/h2&gt;
&lt;p&gt;People ask whether an agency should be building a product. The honest answer is that this product only exists because of the agency. We did not guess at the problem; we were paid to solve it, badly, many times. The engineers building the loyalty and wallet pieces are the ones who shipped our order management and tracking products. The people building the storefront extensions built our wishlist app. Tetralogicx stays an agency, and Ayra is a product team inside it, funded by that work.&lt;/p&gt;
&lt;p&gt;If you run a Shopify store and the “six apps, six records” story sounds familiar, the &lt;a href=&quot;/#waitlist&quot;&gt;waitlist&lt;/a&gt; is at the bottom of this page. We are onboarding in small batches so that we can watch every store closely, and we would like one of them to be yours.&lt;/p&gt;</content:encoded><category>Product</category><category>ayra</category><category>retention-platform</category><category>customer-360</category><category>private-beta</category><author>hello@ayra.one (Ahmad)</author></item><item><title>Repeat purchase rate on Shopify: how to measure it and what moves it</title><link>https://ayra.one/blog/repeat-purchase-rate-shopify</link><guid isPermaLink="true">https://ayra.one/blog/repeat-purchase-rate-shopify</guid><description>What repeat purchase rate is, the formula, how to read it from Shopify&apos;s own reports, why benchmarks mislead, and the five levers that reliably move it.</description><pubDate>Mon, 12 Oct 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;Repeat purchase rate is the retention metric most Shopify merchants look at first, and the one most often misread. The number itself is simple. The decisions around it, which customers, which window, which denominator, are where stores go wrong. This article covers the definition, the calculation, where to find it in Shopify, why benchmarks mislead, and what actually moves it.&lt;/p&gt;
&lt;h2 id=&quot;what-repeat-purchase-rate-is&quot;&gt;What repeat purchase rate is&lt;/h2&gt;
&lt;p&gt;Repeat purchase rate is the percentage of customers who have placed more than one order. Written out:&lt;/p&gt;
&lt;pre class=&quot;astro-code github-light&quot; style=&quot;background-color:#fff;color:#24292e;overflow-x:auto&quot; tabindex=&quot;0&quot; data-language=&quot;text&quot;&gt;&lt;code&gt;&lt;span class=&quot;line&quot;&gt;&lt;span&gt;repeat purchase rate = customers with 2+ orders / all customers with 1+ orders × 100&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;That is the whole formula. The variables are in the words “customers” and “orders”, because both depend on a time window and on how you count people.&lt;/p&gt;
&lt;p&gt;Three choices change the number materially:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;The window.&lt;/strong&gt; All-time repeat rate is a different metric from twelve-month repeat rate, which is different again from “customers acquired in Q1 who reordered within 90 days”. Longer windows always look better, because customers have had more time.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;The denominator.&lt;/strong&gt; “All customers” includes people who bought once three years ago. A cohort denominator, customers who placed their first order in a given month, is the one you can act on.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Identity.&lt;/strong&gt; Guest checkouts, a second email address and a phone-only POS sale can all turn one person into three customers. Every split inflates the denominator and deflates the rate.&lt;/li&gt;
&lt;/ul&gt;
&lt;aside class=&quot;ay-callout border-l-[3px] px-5 py-4 text-[0.95em] border-success/40 bg-success-soft&quot; role=&quot;note&quot;&gt; &lt;p class=&quot;ay-eyebrow !text-[11px] text-fg&quot;&gt;&lt;svg xmlns=&quot;http://www.w3.org/2000/svg&quot; width=&quot;14&quot; height=&quot;14&quot; viewBox=&quot;0 0 24 24&quot; fill=&quot;none&quot; stroke=&quot;currentColor&quot; stroke-width=&quot;2&quot; stroke-linecap=&quot;round&quot; stroke-linejoin=&quot;round&quot; class=&quot;text-accent-fg&quot; aria-hidden=&quot;true&quot; focusable=&quot;false&quot;&gt;&lt;path d=&quot;M9.937 15.5A2 2 0 0 0 8.5 14.063l-6.135-1.582a.5.5 0 0 1 0-.962L8.5 9.936A2 2 0 0 0 9.937 8.5l1.582-6.135a.5.5 0 0 1 .963 0L14.063 8.5A2 2 0 0 0 15.5 9.937l6.135 1.581a.5.5 0 0 1 0 .964L15.5 14.063a2 2 0 0 0-1.437 1.437l-1.582 6.135a.5.5 0 0 1-.963 0z&quot;/&gt;&lt;path d=&quot;M20 3v4&quot;/&gt;&lt;path d=&quot;M22 5h-4&quot;/&gt;&lt;/svg&gt; Write your definition down&lt;/p&gt; &lt;div class=&quot;mt-2 [&amp;&gt;*+*]:mt-3&quot;&gt;&lt;p&gt;Decide the window and the denominator once, write them into the report title, and keep them. A repeat rate that drifts because someone changed the window is worse than no repeat rate at all.&lt;/p&gt;&lt;/div&gt; &lt;/aside&gt;
&lt;h2 id=&quot;repeat-purchase-rate-versus-returning-customer-rate&quot;&gt;Repeat purchase rate versus returning customer rate&lt;/h2&gt;
&lt;p&gt;Shopify’s own reporting uses the phrase &lt;strong&gt;returning customer rate&lt;/strong&gt;. In Shopify’s definition, a returning customer is one who placed an order in the period and had placed at least one order before it. That makes returning customer rate the share of &lt;em&gt;orders in a period&lt;/em&gt; that came from existing customers, which is not the same as the share of &lt;em&gt;customers&lt;/em&gt; who ever reordered.&lt;/p&gt;
&lt;p&gt;Both are useful. Returning customer rate tells you how much of this month’s business came from people you already had. Repeat purchase rate tells you how good you are at turning first orders into second ones. Mixing them up is the most common reason two people at the same company quote different numbers for “retention”. Shopify documents its customer reports in the &lt;a href=&quot;https://help.shopify.com/en/manual/reports-and-analytics/shopify-reports/report-types/default-reports/customers-reports&quot;&gt;Help Center&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id=&quot;how-to-read-it-from-shopify&quot;&gt;How to read it from Shopify&lt;/h2&gt;
&lt;p&gt;You do not need an app to get a first number. Shopify Analytics exposes the returning customer rate directly, and the customer reports let you rebuild a cohort view by hand.&lt;/p&gt;
&lt;div class=&quot;ay-steps my-8&quot;&gt;&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;Open Analytics.&lt;/strong&gt; In the Shopify admin, go to Analytics. The overview shows &lt;strong&gt;Returning customer rate&lt;/strong&gt; for the selected date range, with a comparison to the previous period.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Set a sensible range.&lt;/strong&gt; Pick a full month or quarter. A seven-day range will swing wildly with a single campaign.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Open Reports, then Customers.&lt;/strong&gt; The &lt;strong&gt;Customers over time&lt;/strong&gt; report splits new and returning customers by day, week or month. This is the series to chart.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Build a cohort.&lt;/strong&gt; Use the &lt;strong&gt;First-time vs returning customer sales&lt;/strong&gt; report, or export orders with the customer ID and first order date, and group customers by the month of their first order. For each cohort, count how many placed a second order within 30, 60 and 90 days.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Segment by first product.&lt;/strong&gt; Group the same cohort by the product in the first order. The spread between products is usually larger than any month-to-month change in the headline number.&lt;/li&gt;
&lt;/ol&gt;&lt;/div&gt;
&lt;p&gt;The export step is tedious, which is why most stores stop at the headline number. It is also where the useful information is.&lt;/p&gt;
&lt;h2 id=&quot;why-benchmarks-mislead&quot;&gt;Why benchmarks mislead&lt;/h2&gt;
&lt;p&gt;Every retention article offers a benchmark, and almost none of them agree, because they are measuring different things. A benchmark built on all-time repeat rate across every store on a platform will be higher than a 90-day cohort benchmark for a single category. A consumables brand with a monthly replenishment cycle and a furniture brand with a seven-year one are not comparable on any window, and a blended industry average tells neither of them anything.&lt;/p&gt;
&lt;p&gt;Rather than quote a number here that would be wrong for your store, a more reliable approach:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Compare the store to itself.&lt;/strong&gt; Trend the same cohort metric month over month. A change in your own number under a fixed definition is real; a gap to someone else’s average may not be.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Compare products to products.&lt;/strong&gt; The first product a customer buys predicts repeat behavior more than almost anything else you can measure early. Rank your entry products by 90-day repeat rate.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Compare channels to channels.&lt;/strong&gt; Customers acquired through referrals, subscriptions and organic search often repeat at different rates from paid social. Keep the window fixed and the comparison becomes meaningful.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;If you want external context, use sources that publish their definition alongside the figure, and check that the definition matches yours before you compare.&lt;/p&gt;
&lt;h2 id=&quot;five-things-that-move-it&quot;&gt;Five things that move it&lt;/h2&gt;
&lt;p&gt;These are the levers we have seen move repeat rate consistently across the stores we have worked on. None of them is a trick, and each one is more effective when it reads the same customer record as the others.&lt;/p&gt;
&lt;h3 id=&quot;1-follow-up-on-delivery-not-on-order&quot;&gt;1. Follow up on delivery, not on order&lt;/h3&gt;
&lt;p&gt;Most post-purchase flows fire on a timer from the order date. The customer’s experience starts when the parcel arrives. A review request or a “how is it going” message timed from the delivery event lands when the product is in hand, and it is suppressed automatically if there is an open support ticket. Timing from fulfillment events is one of the simplest changes with a visible effect on second orders.&lt;/p&gt;
&lt;h3 id=&quot;2-give-the-customer-a-reason-to-come-back-before-they-need-one&quot;&gt;2. Give the customer a reason to come back before they need one&lt;/h3&gt;
&lt;p&gt;Points, store credit and tier progress are reasons to return that exist before the product runs out. The important part is that the reason is visible: in the account, at checkout and in the follow-up message, with the same balance everywhere. A loyalty balance the customer cannot see does not change behavior.&lt;/p&gt;
&lt;div class=&quot;not-prose my-8&quot;&gt;&lt;a href=&quot;/features/loyalty&quot; class=&quot;group ay-card ay-card-link flex h-full flex-col gap-5 p-6&quot;&gt; &lt;div class=&quot;flex items-center justify-between&quot;&gt; &lt;span class=&quot;ay-icon-tile&quot;&gt;&lt;svg xmlns=&quot;http://www.w3.org/2000/svg&quot; width=&quot;20&quot; height=&quot;20&quot; viewBox=&quot;0 0 24 24&quot; fill=&quot;none&quot; stroke=&quot;currentColor&quot; stroke-width=&quot;2&quot; stroke-linecap=&quot;round&quot; stroke-linejoin=&quot;round&quot; aria-hidden=&quot;true&quot; focusable=&quot;false&quot;&gt;&lt;rect x=&quot;3&quot; y=&quot;8&quot; width=&quot;18&quot; height=&quot;4&quot; rx=&quot;1&quot;/&gt;&lt;path d=&quot;M12 8v13&quot;/&gt;&lt;path d=&quot;M19 12v7a2 2 0 0 1-2 2H7a2 2 0 0 1-2-2v-7&quot;/&gt;&lt;path d=&quot;M7.5 8a2.5 2.5 0 0 1 0-5A4.8 8 0 0 1 12 8a4.8 8 0 0 1 4.5-5 2.5 2.5 0 0 1 0 5&quot;/&gt;&lt;/svg&gt;&lt;/span&gt; &lt;span class=&quot;inline-flex items-center gap-1.5  border px-2.5 py-1 font-mono text-[10px] uppercase tracking-[0.1em] border-accent/40 bg-accent-soft text-accent-fg&quot;&gt; &lt;span class=&quot;size-1.5  bg-accent&quot; aria-hidden=&quot;true&quot;&gt;&lt;/span&gt; Private beta &lt;/span&gt; &lt;/div&gt; &lt;div&gt; &lt;h3 class=&quot;text-xl text-fg&quot;&gt;Loyalty &amp;amp; Rewards&lt;/h3&gt; &lt;p class=&quot;mt-2 text-fg-muted&quot;&gt;Points, store credit and VIP tiers that know who the customer is.&lt;/p&gt; &lt;/div&gt;  &lt;span class=&quot;ay-link text-sm&quot;&gt;Explore Loyalty &lt;svg xmlns=&quot;http://www.w3.org/2000/svg&quot; width=&quot;16&quot; height=&quot;16&quot; viewBox=&quot;0 0 24 24&quot; fill=&quot;none&quot; stroke=&quot;currentColor&quot; stroke-width=&quot;2&quot; stroke-linecap=&quot;round&quot; stroke-linejoin=&quot;round&quot; aria-hidden=&quot;true&quot; focusable=&quot;false&quot;&gt;&lt;path d=&quot;M5 12h14&quot;/&gt;&lt;path d=&quot;m12 5 7 7-7 7&quot;/&gt;&lt;/svg&gt;&lt;/span&gt; &lt;/a&gt;&lt;/div&gt;
&lt;h3 id=&quot;3-make-the-second-order-offer-specific&quot;&gt;3. Make the second-order offer specific&lt;/h3&gt;
&lt;p&gt;A blanket 10% off for everyone is easy to run and easy to ignore. An offer that references what the customer bought, what they wishlisted, or what sold out and is now back is noticeably different. The information to do that exists in most stores already; it is just spread across apps.&lt;/p&gt;
&lt;h3 id=&quot;4-time-replenishment-to-the-product&quot;&gt;4. Time replenishment to the product&lt;/h3&gt;
&lt;p&gt;For consumables, repeat rate is mostly a timing problem. If a product lasts about six weeks, the reminder should arrive in week five, not week two and not week ten. Subscriptions solve this structurally; for everything else, a replenishment flow keyed to the product’s actual cycle does most of the work.&lt;/p&gt;
&lt;h3 id=&quot;5-remove-the-friction-you-cannot-see&quot;&gt;5. Remove the friction you cannot see&lt;/h3&gt;
&lt;p&gt;A customer who has to re-enter an address, hunt for their order status, or email support to use a reward is a customer who will consider buying elsewhere. The account hub, order tracking and reward redemption at checkout are retention features even though none of them looks like a campaign.&lt;/p&gt;
&lt;h2 id=&quot;how-ayra-reports-it&quot;&gt;How Ayra reports it&lt;/h2&gt;
&lt;p&gt;Ayra’s &lt;a href=&quot;/features/analytics&quot;&gt;Retention Analytics&lt;/a&gt; module reports repeat purchase rate and returning customer rate side by side, with the definitions printed on the report, so the two are never confused. Cohorts are built automatically by first-order month and by first product, with 30, 60 and 90-day windows, and revenue from each repeat order is attributed to at most one module or flow, so loyalty, flows and reviews cannot each claim the same second order. The same profile that powers the report powers the actions above, which is the point: the metric and the levers read the same customer.&lt;/p&gt;
&lt;p&gt;If you want to see your own numbers under these definitions, join the &lt;a href=&quot;/#waitlist&quot;&gt;waitlist&lt;/a&gt;. If you are weighing a loyalty app that ships its own retention reporting, our &lt;a href=&quot;/compare/loyaltylion&quot;&gt;comparison with LoyaltyLion&lt;/a&gt; covers where it still wins.&lt;/p&gt;</content:encoded><category>Retention</category><category>repeat-purchase-rate</category><category>retention-metrics</category><category>shopify-reports</category><category>analytics</category><author>hello@ayra.one (Ahmad)</author></item><item><title>Back-in-stock alerts: a checklist before you switch them on</title><link>https://ayra.one/blog/back-in-stock-alerts-checklist</link><guid isPermaLink="true">https://ayra.one/blog/back-in-stock-alerts-checklist</guid><description>Back-in-stock alerts only work when the inventory signal, the customer record and the send rules agree. Seven things to check before the first alert goes out.</description><pubDate>Sat, 10 Oct 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;A back-in-stock alert looks like the simplest message a store sends: an item is available again, tell the people who asked. In practice it sits on top of three systems that rarely agree, which is why so many stores switch alerts on and then quietly switch them off. This is the checklist we run through with merchants before the first alert goes out.&lt;/p&gt;
&lt;h2 id=&quot;check-the-inventory-event&quot;&gt;Check the inventory event&lt;/h2&gt;
&lt;p&gt;Which event fires the alert? A purchase order received at a warehouse is not the same as a variant becoming purchasable online. Decide whether a single unit counts, or whether you want a minimum quantity before you tell anyone. Confirm which locations count, especially if one location only serves retail.&lt;/p&gt;
&lt;h2 id=&quot;check-the-customer-record&quot;&gt;Check the customer record&lt;/h2&gt;
&lt;p&gt;The person who clicked “notify me” as a guest and the person who logs in a week later are usually the same shopper. If your alert tool keeps its own list, it cannot see the order history, the tier or the open support ticket that should change what you send. Resolve the request to one profile first.&lt;/p&gt;
&lt;h2 id=&quot;check-the-send-rules&quot;&gt;Check the send rules&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Who gets the alert when there are five units and forty requests?&lt;/li&gt;
&lt;li&gt;Which channel goes first, and how long before the next one?&lt;/li&gt;
&lt;li&gt;Does the alert carry an incentive, and does that incentive stack with something the customer already has?&lt;/li&gt;
&lt;li&gt;When does the request expire?&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Write the answers down before the tool asks you for them in a settings screen.&lt;/p&gt;
&lt;h2 id=&quot;check-what-happens-next&quot;&gt;Check what happens next&lt;/h2&gt;
&lt;p&gt;An alert that converts should credit the restock, not the email that happened to arrive the same afternoon. If you cannot say which message earned the order, you cannot tune the rules later. Decide how attribution works before you need it.&lt;/p&gt;</content:encoded><category>Retention</category><category>back-in-stock</category><category>inventory</category><category>alerts</category><author>hello@ayra.one (Ahmad)</author></item><item><title>Review requests: when to ask, and what to do with the answer</title><link>https://ayra.one/blog/review-requests-timing</link><guid isPermaLink="true">https://ayra.one/blog/review-requests-timing</guid><description>Timing matters more than the subject line. Tie the review request to delivery, ask once, and treat a poor review as a support ticket before a public reply.</description><pubDate>Thu, 08 Oct 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;Most review tools let you send a request a fixed number of days after the order. That number is a guess about delivery, and it is wrong for every order that ships late, ships early or ships in two parcels. The better trigger is the delivery event itself, plus a short pause so the customer has actually opened the box.&lt;/p&gt;
&lt;h2 id=&quot;tie-the-ask-to-delivery&quot;&gt;Tie the ask to delivery&lt;/h2&gt;
&lt;p&gt;Shopify exposes fulfilment and delivery events. Use the delivered event, wait a day or two depending on the product, then ask. For products that need time to judge, a skincare routine or a pair of running shoes, wait longer. The request should arrive when the customer has an opinion, not when your calendar says so.&lt;/p&gt;
&lt;h2 id=&quot;ask-once&quot;&gt;Ask once&lt;/h2&gt;
&lt;p&gt;A request and one reminder is the whole sequence. If the customer has not answered after that, the answer is no. Keep the door open on the account page, where a customer can leave a review whenever they like, and stop sending.&lt;/p&gt;
&lt;h2 id=&quot;decide-what-a-bad-review-triggers&quot;&gt;Decide what a bad review triggers&lt;/h2&gt;
&lt;p&gt;A one-star review is a support ticket that happens to be public. Route it to a person before you route it to the storefront. The reply you post later should say what you did, not what you feel.&lt;/p&gt;
&lt;h2 id=&quot;stop-asking-people-who-already-told-you&quot;&gt;Stop asking people who already told you&lt;/h2&gt;
&lt;p&gt;If the same customer reviewed the same product last month, do not ask again. If they opened a support ticket about this order, pause the request until it is closed. Both of these need the review tool to see the rest of the customer record, which is the argument for keeping reviews inside the same profile as everything else.&lt;/p&gt;</content:encoded><category>Reviews</category><category>reviews</category><category>post-purchase</category><category>timing</category><author>hello@ayra.one (Ahmad)</author></item><item><title>Referral programs that do not reward the wrong people</title><link>https://ayra.one/blog/referral-rewards-wrong-people</link><guid isPermaLink="true">https://ayra.one/blog/referral-rewards-wrong-people</guid><description>Self-referrals, refund farming and duplicate accounts drain referral budgets quietly. The rules that keep rewards for real advocates and catch the rest.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;Referral programs are easy to launch and easy to lose money on. The losses rarely come from a big fraud ring. They come from ordinary shoppers who notice that a second email address earns a discount, and from refunds that leave the referrer holding a reward for an order that no longer exists.&lt;/p&gt;
&lt;h2 id=&quot;reward-on-the-right-event&quot;&gt;Reward on the right event&lt;/h2&gt;
&lt;p&gt;An order placed is a promise. An order delivered and kept is a sale. Pay the advocate when the referred order clears the return window, or at least on delivery. If your tool can only pay on order placed, treat the reward as a loan you may need to recall.&lt;/p&gt;
&lt;h2 id=&quot;match-people-not-addresses&quot;&gt;Match people, not addresses&lt;/h2&gt;
&lt;p&gt;An email address is the weakest identifier a store has. Match on phone number, shipping address and the device that placed the order before you call someone new. A referral from one person to the same household is a judgement call; a referral to the same device is not.&lt;/p&gt;
&lt;h2 id=&quot;claw-back-on-refunds&quot;&gt;Claw back on refunds&lt;/h2&gt;
&lt;p&gt;When the referred order is refunded, the reward should be reversed without anyone opening a spreadsheet. The same applies to points earned on the order. Put the rule in the program terms so the reversal is expected rather than surprising.&lt;/p&gt;
&lt;h2 id=&quot;keep-the-advocates&quot;&gt;Keep the advocates&lt;/h2&gt;
&lt;p&gt;None of this should make the program feel suspicious to the people it is for. Show advocates what they earned and why, pay promptly once the checks pass, and keep the share link simple. The checks run in the background; the experience stays generous.&lt;/p&gt;</content:encoded><category>Referrals</category><category>referrals</category><category>fraud</category><category>rewards</category><author>hello@ayra.one (Ahmad)</author></item><item><title>Subscription skips are a signal, not a loss</title><link>https://ayra.one/blog/subscription-skips-are-a-signal</link><guid isPermaLink="true">https://ayra.one/blog/subscription-skips-are-a-signal</guid><description>A skipped delivery says something about timing, product or budget. How to read skips, what to offer instead of a discount, and when to leave people alone.</description><pubDate>Sat, 03 Oct 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;Subscription dashboards treat a skip as a small churn event. It is closer to a customer telling you, politely, that something about the next delivery does not fit. Reading it that way changes what you send next.&lt;/p&gt;
&lt;h2 id=&quot;what-a-skip-usually-means&quot;&gt;What a skip usually means&lt;/h2&gt;
&lt;p&gt;The common reasons are mundane: there is still product left, the customer is travelling, or money is tight this month. Each has a different fix. Only one of them is helped by a discount, and it is the one you can least afford to fix with discounts every month.&lt;/p&gt;
&lt;h2 id=&quot;offer-a-change-first&quot;&gt;Offer a change first&lt;/h2&gt;
&lt;p&gt;The first response to a skip should be an offer to adjust: push the next date out, drop to a smaller size, swap the flavour or scent. These keep the subscription alive without lowering its value. Save the price offer for the moment the customer actually reaches for the cancel button.&lt;/p&gt;
&lt;h2 id=&quot;watch-the-pattern&quot;&gt;Watch the pattern&lt;/h2&gt;
&lt;p&gt;One skip is noise. Two in a row is a pattern, and three is a cancellation that has not been filed yet. At two, the next message should come from a person, or at least read like one, and it should ask a question rather than make an offer.&lt;/p&gt;
&lt;h2 id=&quot;know-when-to-stop&quot;&gt;Know when to stop&lt;/h2&gt;
&lt;p&gt;Some customers want to pause for a season. Let them, make resuming a single click, and stop sending reminders while they are paused. A subscriber who comes back after a quiet summer is worth more than one who was nagged into cancelling in July.&lt;/p&gt;</content:encoded><category>Subscriptions</category><category>subscriptions</category><category>churn</category><category>save-flows</category><author>hello@ayra.one (Ahmad)</author></item><item><title>Points, store credit and vouchers: one wallet or three ledgers?</title><link>https://ayra.one/blog/points-credit-vouchers-one-wallet</link><guid isPermaLink="true">https://ayra.one/blog/points-credit-vouchers-one-wallet</guid><description>Points, store credit and vouchers usually live in three tools with three balances. What breaks when they are separate, and what one wallet must get right.</description><pubDate>Thu, 01 Oct 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;Ask a support agent what a given customer “has” and watch them open three tabs: the loyalty app for points, Shopify for store credit, and the discount list for a voucher someone issued after a late delivery. The customer sees the same three fragments on three different pages, if they can find them at all.&lt;/p&gt;
&lt;h2 id=&quot;what-breaks-when-balances-are-separate&quot;&gt;What breaks when balances are separate&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;A refund reverses the order but not the points it earned.&lt;/li&gt;
&lt;li&gt;A voucher and a points redemption stack on the same order because neither tool knows about the other.&lt;/li&gt;
&lt;li&gt;The account page shows one balance, the email shows another, and support quotes a third.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;None of these are edge cases. They are the normal state of a store running separate tools.&lt;/p&gt;
&lt;h2 id=&quot;what-one-wallet-has-to-get-right&quot;&gt;What one wallet has to get right&lt;/h2&gt;
&lt;p&gt;A single balance the customer can see is the goal, but it has to be built on separate ledgers underneath. Points, credit and vouchers have different rules for expiry, transfer and reversal, and an auditor, or a tax adviser, will want to see each one on its own.&lt;/p&gt;
&lt;p&gt;The wallet also has to be the place where guards live. A grant that would push a customer past a cap, or stack with an incentive they already received, should be refused by the wallet rather than caught later by a report.&lt;/p&gt;
&lt;h2 id=&quot;the-refund-test&quot;&gt;The refund test&lt;/h2&gt;
&lt;p&gt;The quickest way to judge any wallet is to refund an order and look at what happens. If the points, the credit and the voucher that touched that order are all reversed, with a line in the history saying why, the wallet works. If a person has to fix any of it by hand, it does not.&lt;/p&gt;</content:encoded><category>Loyalty</category><category>loyalty</category><category>store-credit</category><category>wallet</category><author>hello@ayra.one (Ahmad)</author></item></channel></rss>