CRO · RETENTION · APPS · 12 MARCH 2026 · 6 MIN READ
Wishlist, save for later, and the intent you are ignoring
A wishlist is a retention feature that most teams buy as a conversion feature. That mismatch is why so many of them end up with a heart icon nobody measures and a dataset nobody reads.
For most stores, no — not as the first thing you build. A wishlist captures deferred intent, so it only pays back when your catalogue actually produces deferral: high consideration prices, gifting, size uncertainty, seasonal collections, or repeat B2B ordering. If people buy on the same visit they arrive, a wishlist adds a button, a login prompt and a dataset nobody reads. The intent you are more likely ignoring is cheaper to capture: back-in-stock alerts for the item you could not sell, a cart that survives the week, and a reason to hand over an email address. Do those first, measure whether saving behaviour appears anyway, and build the wishlist when the demand is evidenced rather than assumed.
IN SHORT
- A wishlist is a retention and merchandising instrument, not a conversion one — the value arrives on a later visit, so judging it by same-session conversion rate will always make it look like a failure.
- A wishlist that survives a device change needs a login, so the real cost is the account you are now asking every saver to create.
- Customer metafields can hold saved items natively, with Customer Account API access set per definition to `read`, `read_write` or `none`, which keeps saved data inside Shopify rather than inside an app vendor’s database.
- Customer account UI extensions can render a full custom page in the logged-in account, with a compiled bundle limit of 64 KB for block targets and 128 KB for full-page extensions.
- An app that accesses customer data needs Shopify’s protected customer data access approved before it can go live, which makes a wishlist a compliance decision as well as a feature.
- Back-in-stock alerts, a persistent cart and a working email capture cover most of the intent a wishlist would have caught, and all three are cheaper to ship.
What a wishlist is actually for
A wishlist records that somebody wants a thing and is not buying it today. That is a genuinely useful signal, and it is not the same signal as an abandoned cart. A cart abandonment says "I nearly bought this and something stopped me" — usually shipping cost, a delivery date, or a checkout problem. A save says "I want this later", and later is doing all the work.
This distinction decides how you should measure it. Wishlist value shows up as return visits, as email performance, and as the demand signal that tells merchandising what to restock. It does not show up as this week's conversion rate, and a team that installed a wishlist app expecting it to will conclude within a quarter that it did nothing.
It also explains the most common failure mode. A wishlist built as a conversion feature gets a heart icon on the product card and nothing else: no email when the price drops, no email when stock returns, no report anybody reads. The intent gets captured and then thrown away, which is worse than not capturing it, because now you have a feature to maintain and a dataset that constitutes personal data.
The question that decides it: does your catalogue create deferral?
Before any of the implementation questions, answer this one honestly. Some catalogues produce deferred intent structurally and some do not.
- Price high enough to think about. Furniture, jewellery, bikes, technical kit. Someone returning three times over a fortnight is normal, and giving them somewhere to put the shortlist is obviously useful.
- Gifting. People build lists for other people and share them. This is the case where a wishlist is not a nice-to-have — it is the product.
- Size or fit uncertainty. Apparel shoppers save several options while they decide, and a save is often a "check whether my size comes back" in disguise.
- Seasonal or drop-based catalogues. Wanting something that is not purchasable yet is deferred intent by definition, and there is nowhere else for it to go.
- B2B and repeat ordering. This one is not really a wishlist; it is a saved order template, and it is the highest-value version of the feature by a distance.
The login problem nobody costs properly
A wishlist held in browser storage is not a wishlist. It survives until the shopper opens their laptop instead of their phone, clears their browser, or waits long enough for storage to be evicted — and it cannot trigger a single email, because you do not know who they are. It is a UI flourish that produces no retention and no data.
A wishlist that survives is attached to a customer account. Which means that the moment somebody taps the heart, you are asking them to create an account, and account creation is one of the most reliable places to lose people on an ecommerce site. That is the real price of the feature, and it is rarely in the business case.
There are two honest responses. The first is to accept it and make the account worth having — order history, saved addresses, reorder, saved items in one place, so signing up buys the shopper something beyond your convenience. The second is a hybrid: save locally without an account, then prompt for an email at the moment the save becomes valuable, such as when the item goes out of stock or drops in price. The second asks for identity at the point where the shopper gets something for it, rather than at the point where they are only browsing — and it requires the notification machinery to exist, which returns us to the point that the notifications, not the list, are the feature.
The cheaper things that capture the same intent
If the goal is to stop losing people who wanted something and did not buy it, a wishlist is the most expensive of the available answers and rarely the first one to try.
Back-in-stock alerts. This is deferred intent with a known trigger, a known recipient and an obvious email. It is the single highest-return version of "save this for me", and it is not a wishlist — it is one field and one webhook.
A cart that survives. Plenty of stores discover that their shoppers were already using the cart as a wishlist, badly, and that the useful change is making the cart persist reliably and be visible on return rather than adding a second list beside it.
Recently viewed. No account, no data protection question, no maintenance. It handles the "where was that thing" case, which is a decent share of what people use a wishlist for, and it is a theme change.
A working reason to give you an email address. The wishlist is often a proxy for wanting an email list. If that is the actual goal, pursue it directly and spend the budget on the welcome sequence rather than on saved-item UI.
The order matters more than any individual item on that list. Sequencing these correctly — cheapest reversible change first, measured, then the next — is most of what [conversion rate optimisation](/services/optimize/shopify-conversion-rate-optimization) is, and it is why we would talk most stores out of the wishlist as a first project.
If you do build it, where the data should live
The default answer is an app, and the default app keeps your customers' saved items in the vendor's database. That is a reasonable trade for a small store and a poor one for a brand that treats its customer data as an asset — you cannot query it alongside orders, you cannot easily leave, and it is one more processor to name in your privacy documentation.
The native alternative is customer metafields. A defined metafield on the customer holds the saved product references, and the definition's Customer Account API access setting — read, read_write or none — controls what the logged-in session may do with it. The data sits in Shopify next to the orders it is meant to explain, and the storefront access setting stays at none so nobody's wishlist is readable through a public API.
For the interface, customer account UI extensions let you put a saved-items page inside the logged-in account: Shopify supports block, full-page and static targets, with compiled bundle limits of 64 KB, or 128 KB for full-page extensions. That is a small budget, which is a useful discipline — a wishlist page is a list, a picture, a price and a button.
One thing to settle before any of it: Shopify requires that an app accessing customer data has protected customer data access approved before it can go live. A wishlist is customer data. Treat that as part of the build, not as a launch-week surprise.
The part that makes it worth having
Assume you have built it. The list itself changes nothing; four things done with it do.
- Notify on stock return and on price drop. These are the two emails a saver actually wants, and they are the reason the data was collected.
- Surface saved items on return — in the header, in the account, and in the cart when a saved item is in stock again.
- Report saved-but-not-bought to merchandising weekly. It is the cleanest demand signal on the site, and it is usually the first thing to lapse.
- Keep consent straight. A wishlist is personal data and an email about it is marketing, so it needs the same consent basis as anything else you send — and a saver must be able to see and delete their list.
The honest position
We have built wishlists and we would ask you three questions before building another one. Does your catalogue create deferral, or are you hoping it does? Who sends the stock and price emails, and is that person funded? And what will you do differently in six months because of the saved-items report?
If the answers are thin, the money is better spent on the things a shopper hits before they ever want to save anything. If the answers are solid, build it properly — accounts, notifications, native data, reporting — because the half-built version is the one that costs maintenance and returns nothing.
Questions this raises
Does a wishlist increase conversion rate?
Not in the session it is used, and expecting that is the usual reason these projects are judged a failure. Its return comes from return visits and from the emails triggered by saved items going back in stock or dropping in price. If those emails do not exist, the wishlist has no mechanism by which it could pay for itself.
Can I have a wishlist without forcing customers to log in?
You can save locally without an account, but that list dies with the browser and cannot trigger any notification. A reasonable middle path is to allow the save anonymously and ask for an email at the moment it becomes useful — when the item sells out or the price changes — so you are trading identity for something the shopper wants rather than for your convenience.
Should I use a wishlist app or build one?
An app is the right call for most small catalogues. Consider building when the saved data needs to sit alongside your orders and customers — customer metafields plus a customer account UI extension keep it inside Shopify — or when the feature is really a saved order template for B2B buyers, which no generic wishlist app models well.
Is a wishlist the same as an abandoned cart?
No, and treating them the same produces bad emails. An abandoned cart means something blocked a purchase that was nearly made; the follow-up should address the blocker. A save means the purchase was deliberately deferred; the follow-up should wait for a reason — stock, price, a season — rather than nagging.
What does a wishlist mean for data protection?
Saved items tied to a person are personal data, so they sit inside your existing obligations: a lawful basis for holding them, marketing consent for anything you send about them, deletion when the customer asks, and inclusion in your retention policy. If you use an app, the vendor is another processor to document.
What should we build instead if we skip it?
Back-in-stock alerts first — same intent, clear trigger, far less surface area. Then make sure the cart persists and is visible on return, since many shoppers are already using it as a wishlist. Recently viewed handles most of the rest and needs no account at all.
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.