A short technical companion to the jewelry wishlist page. Why generic Shopify wishlist apps don’t do variant fidelity well, and what the alternative looks like.
The variant explosion problem
A single jewelry product can have 4 metal options × 3 stone options × 8 ring sizes = 96 variants. A customer saves “this ring” to their wishlist. Three weeks later they come back, click the saved item, and… see the default variant. Not the 14k yellow gold with diamond at size 7 they actually wanted.
This is the variant fidelity problem. Most off-the-shelf wishlist apps store the product handle (or product ID), not the variant ID. The customer assumes the wishlist remembers their selection. It doesn’t.
Why off-the-shelf apps don’t fix it
Most wishlist apps are built generic — for a t-shirt store where the variant is just a color and a size, storing the variant ID would clutter the wishlist UX. So they default to storing the product. For 90% of Shopify stores this is fine. For jewelry it’s broken.
A few apps support variant storage as a premium feature, but the UX is usually wrong — they show the variant in the wishlist as “Product Name (variant 14k YG / 0.5ct / size 7)” with no visual representation of what the customer actually saved. For a high-AOV jewelry brand, the wishlist is part of the brand experience; a generic widget is a trust killer.
What variant-aware actually means
Three properties:
1. Storage by variant ID, not product handle. Each saved item is a (product ID, variant ID, custom properties) triple. Custom properties capture things like engraving text or ring size if the variant model is too coarse.
2. Visual fidelity in the wishlist. The wishlist shows the variant image (not the product’s default image), the variant attributes (metal, stone, size), and any custom properties (engraving). The customer sees exactly what they saved.
3. Clean re-add to cart. Clicking the wishlist item adds the exact variant + custom properties to cart, no re-configuration needed.
Persistence across login states
The other place generic apps fall down: anonymous-to-logged-in transitions. Customer saves three items while browsing anonymously. Later, they create an account or log in. A good wishlist merges the anonymous list (from localStorage) with the customer’s saved list (from their customer metafield). A bad one wipes the anonymous list silently.
Pattern that works: localStorage for anonymous, customer metafield for logged-in, merge on login with deduplication. Promote anonymous-only items to the customer’s saved list automatically.
Shareable lists
Jewelry has a specific shape: engagement-ring shoppers want to share with their partner (“does this one feel right?”); gift-givers want to send a link to the recipient. Generic wishlist apps either don’t do this or do it badly (the share link is a clunky URL that breaks on email clients).
Pattern that works: unique shareable URL per wishlist, server-rendered preview (so it works in email previews + on link cards), recipient can add to their own wishlist or buy from the list. Optional “private” mode for surprise gifts.
Klaviyo integration
Wishlist items push as profile properties on add: wishlist_items, wishlist_value, wishlist_recent_add_timestamp. Klaviyo flows trigger automatically: back-in-stock alerts on wishlist-saved items, price-drop alerts on wishlist-saved items, wishlist-abandonment series (24h, 7d, 30d), anniversary-gift reminders (timed off-saved-date).
These are among the highest-conversion flows for jewelry stores. The wishlist app that doesn’t push to Klaviyo is leaving meaningful revenue on the table.
Build, don’t buy (for jewelry specifically)
For generic apparel stores the off-the-shelf wishlist is fine. For jewelry, custom is the right answer — the variant fidelity, share UX, and Klaviyo integration are deep enough that the build pays back inside year one and the brand experience stays consistent. See /shopify-wishlist-jewelry/ for the build details.
