Test Before You Build: How to Validate a Save for Later Feature

We've all had frustrating online shopping experiences where we find something we like, open it in a new tab to come back to later, and keep browsing. Save for later features help by letting shoppers save the products they like and easily return to them later.  

The catch is that it's a big feature that takes a lot of developer time to build properly. You need to let people save products from several places across the site, store each shopper's list, make it easy to get back to, and keep the product details up to date. Before investing resources and costs, you want to be sure people on your site will actually use it. 

This is where testing comes in. At Hookflash, we've built successful save for later features as A/B tests for four brands, on different testing platforms. It puts a working MVP in front of real customers and gives you real data on whether the full build is worth it. 

Making products easy to save

The save button belongs wherever people browse and weigh up products, which usually means product listing pages (PLPs) and product detail pages (PDPs). On a PLP, put it on each listing card and make it big enough to tap comfortably on a phone. On a PDP, put it near the title or price. 

When someone taps it, show them straight away that it worked. The button switches to its active style, the label changes to "Saved", and the count in the header ticks up. That last bit quietly tells people where their shortlist lives before they go looking for it. 

Helping shoppers find their saved products

The saved list needs to be reachable from any page, so the header is the natural home, next to the basket or account icons. A saved icon with a count badge works well. Headers often differ between mobile and desktop, so expect to add it in two places. 

In this MVP, we will need to open the list in a panel rather than a new page, based on the nature of testing functionality. Each item should show its image, title, price, and key details, and most importantly link back to its PDP. Make items easy to remove too.

A frontend A/B test can't add a database, but there is a way around this as part of an MVP. Our builds keep the saved list in the visitor's own browser using local storage, which survives page loads and return visits. That's enough to prove whether the feature improves the user experience. 

Each saved item keeps everything the saved list needs to display it: the product's link, title, image, key details, current price, any "was" price, and the date it was saved. Because the browser already holds everything the list needs, it can show saved items straight away, without first loading product details from the site. 

The save date lets you expire old items. Our builds quietly drop anything older than 60 days, so a product saved months ago doesn't sit in the list forever.

Know the limits of browser storage

Browser storage belongs to one browser on one site, which has some consequences:

• Saves don't follow the person. Being signed into Chrome on two devices doesn't sync it, so a product saved on a phone won't appear on a laptop. 
• Safari clears it after 7 days without a visit. For some Safari users, the 60-day expiry is really 7 days. You can account for this in reporting by segmenting results by browser. If Safari visitors save as often but return and buy less, the storage limit is the likely cause, not the feature. 
• Clearing browsing data or browsing privately loses everything. 

None of this stops the test from telling you something useful, but it could potentially mean the results understate what a fully synced version would do.  

This approach assumes that you will need to read product data from the page because no API is available. If the site does expose one, use it instead. Store only each product's ID and save date, then fetch the details when the saved list opens. 

This makes the build simpler. Prices are always current, so there's nothing to refresh, and API data is usually cleaner than what's displayed on the page. The trade-off is that the list has to wait for a network request before it can show anything, so plan a loading state and a fallback for when the request fails. 

The rest of this post covers the page-reading approach, which works on any site.

With no product database to call, the build reads titles, prices, images, and key details straight from the listing cards and product pages. 

Here are our key areas to watch out for: 

• Use the product URL as the ID - It appears on both listing cards and product pages, and is reliable. Avoid IDs the site generates for its layout, which often change when someone sorts or filters. 
• Expect messy data - The same value, such as a price, can be formatted differently on listing cards and product pages, so some standardisation might be needed before you store it. 
• Price changes - It's possible that prices can change between when the item was saved and when it is viewed again. Without a refresh the saved list could show a price the site no longer offers. It's important to put guardrails in-place that regularly refresh the price while the information is stored locally in the browser. Once the feature is built into the site and reads from the product database, prices are always current and none of this applies. Until then, we refresh prices in two ways. 
  • Update from the page when you can - Whenever a saved product is already on screen, as a listing card or as its own product page, the build reads its current details and updates the saved price. 
  • Check in the background when the list opens - For products the visitor hasn't seen again, the build quietly loads each product page behind the scenes and reads the current price. To keep this light on the site, check each product no more than once per session. 

Filtering, sorting, pagination, and lazy loading all swap listing cards out without a page load, so a save button added once on page load disappears after any of these events. The fix has three parts: 

• Watch the results list for changes. A MutationObserver on the container that holds the listing cards fires whenever cards are added or replaced. 
• Add a button wherever one is missing. Each time the observer fires, check every card and add a save button to any card that doesn't have one. 
• Guard against duplication. Testing platforms can run code more than once, and observers can fire several times for one change, so always check a card doesn't already have a save button before adding one.

Save for later won't move the needle significantly on every site. It tends to work best for expensive, considered purchases, where people compare a few options and come back several times before they buy.

Even if your site fits that description, you can't be sure customers will use the feature until you put one in front of them, and that's worth knowing before you commit to a full build. A test gets you that answer without the full development cost. 

If you'd like help building one, get in touch with our team.