In brief
An embedded app wins on setup and at checkout, because the store already knows who the customer is and can discount the basket. A standalone wins the moment the program has to work somewhere the Shopify checkout is not.
The short answer
If your business is a Shopify store and nothing else, install a Shopify loyalty app. It reads your order history without a sync, it knows who the customer is because they logged in to buy, and it can take the reward off the basket at checkout. A standalone platform is the right answer when the program also has to work at a physical counter, run across an online store and several shops at once, or outlive the platform you are on today.
Both are legitimate. This post is written by a standalone vendor, so the section explaining what an embedded app does better is the one worth reading closely.
What an embedded app does that a standalone cannot
It applies the reward at checkout, natively. The customer clicks redeem and the basket total changes. No code to copy, no email to find, no member of staff to involve. A standalone tool sitting outside the store can generate a discount code, and a discount code is a worse version of the same thing: it can be shared, it can be pasted into a forum, and it gets abandoned at the payment step more often than a total that is simply lower.
It reads order history without an integration. Installed into the store, the app already has the orders. Nothing is synced, so nothing can be out of sync. That single architectural fact removes an entire class of problem, and it is the same problem a till integration creates in a physical shop, described in connecting loyalty to your POS and CRM.
Identity is free. The hardest part of any loyalty program is knowing which human is in front of you. An online checkout solves it before the program starts, because the customer typed their email to receive the order. A shop counter never gets that for free.
Setup is an afternoon. Install, choose an earning rate, choose a reward, publish. Searches for the best loyalty app for Shopify are usually looking for exactly this, and for a store with no physical presence, the search is well aimed.
What a standalone does that an embedded app cannot
It works where there is no checkout. A market stall, a counter, a treatment room, a delivery round. An embedded app earns on an order in the store, and there is no order in the store when someone buys a coffee with a contactless card.
It survives a replatform. An app installed into a store is scoped to that store. Move to another platform and the program moves with the customer list only if the app lets you take the balances out, which is the section below.
It runs one program across everything you own. A website and three shops is one business to the customer and two systems to a store-scoped app. Stamps earned in the shop on Tuesday should count towards the same reward as an order placed on Thursday. Doing that from inside a store app means pushing counter activity into the store as fake orders, which pollutes your revenue reporting to make your loyalty reporting work. Running one program across several locations has its own decisions, set out in running one program across several shops.
It has no opinion about what you sell through. A standalone tool is indifferent to whether payment happened through a website, a card reader or cash, because it counts something else. That indifference is the whole product, and it is also its limitation: a tool that counts visits will not discount an online basket, and NeoLoyal, which counts visits, does not.
The comparison
| Embedded Shopify app | Standalone platform | |
|---|---|---|
| Works online | Yes, natively | Usually through a discount code |
| Works at a counter | No | Yes |
| Identifies the customer | The checkout does it | A scan, a code, or a phone number |
| Applies the reward | On the basket, at checkout | By hand, or by a code |
| Order history | Already there | Not available |
| Setup | An afternoon | Longer, and involves staff training |
| If you replatform | Ends with the install | Continues |
| One program across shops and a site | Awkward | The reason to choose it |
The table has no winner in it, which is the point. Read down the column that matches where your customers actually pay.
Data portability is the question that decides it
Everything above is a feature comparison, and feature comparisons change every release. The question that does not change is what you can take out.
Three things belong to you, and they come apart separately:
- The customer list. Names, emails, consent. Almost every tool exports this, because almost every merchant asks.
- The balances. How many points or stamps each customer holds right now. Fewer tools export this cleanly, and it is the one that matters, because a balance you cannot export is a promise you cannot keep somewhere else.
- The history. Every earn and every redemption, dated. Rarely offered, and the thing you need if you ever want to know whether the program worked.
An embedded app is not automatically worse at this than a standalone, and some are considerably better. The difference is what happens by default when the relationship ends. Uninstall a store app and the connection to your orders ends immediately. Stop paying a standalone and you are negotiating with a company whose only remaining asset in the conversation is your data. Neither is comfortable. Both are answerable in advance, in writing, before you have three thousand people carrying balances.
Ask for the export before you install. Not a description of the export, the file.
The signal that you have outgrown a Shopify-only app
There is one, and it is specific. A customer asks whether their points work in the shop.
That question means the program has crossed out of the store. Every reasonable answer to it is bad: no, which reads as a smaller program than they thought; yes, once someone types the order in manually, which is a job nobody keeps doing past week three; or a second program at the counter, which is two schemes and two balances for the same person.
Two weaker signals point the same way. You have started exporting orders to a spreadsheet to work out who deserves something. Or you are about to open a physical location and nobody has asked yet what happens to the program when you do.
Until one of those appears, an embedded app is doing its job and replacing it costs more than it returns. That calculation is the same one in what a loyalty program actually costs: the software line is the small one, and switching adds a migration to it.
If you sell online only
Then the embedded app is the answer and this comparison is easy. The one decision left is the mechanic rather than the vendor. Spend-based points fit ecommerce well, because the checkout knows the basket total and a points balance is an issued currency the store can price. Visit-based stamps fit poorly online, because there is no visit to observe, only an order.
Where it stops being easy is the day the business is loyalty programs for ecommerce business plus a physical unit, plus a market stall, plus a pop-up. That is a different question from the one the app was chosen to answer, and the answer to it is rarely the same product.
Two things to do this week, in this order. Install the app you are considering on its free trial and export a customer list on day one, including balances. Then send yourself a test order, earn a reward, and try to redeem it. If the export is missing, or the redemption needs an email from support, you have learned the most useful thing about the tool before a single customer has joined.