SA daily-deals marketplace · Daily deals, South AfricaMaking the saving explicit, with numbers that match the backend
Strikethrough retail price and a 'you save' line on the product page, plus savings lines and badges on listing cards. The interesting part was getting a percentage that agreed with the store's own badge.
- The product page showed no was-price, and listing cards had no absolute saving.
- Computed percentages drifted from the native badge because display prices are already rounded.
- The initial page payload goes stale on SPA navigation, so it can only be trusted when its product ID matches the URL.
Stating the saving explicitly, as retail price, amount saved and percentage, will increase add-to-cart and conversion.
- PDP: red strikethrough retail price beside the deal price with a retail and you-save line. On mobile the price block moves from the sticky bar to a row under the title and the call to action goes full width.
- PLP: green you-save line, save-percent badge, cart-button overlay, restyled pills, best-seller badge and equal-height cards.
- A savings map built from the page data and keyed by product ID, with a priority chain of backend value, hidden native badge text, then computed value. Value and source are logged for QA.
- When the payload is stale, the product HTML is re-fetched and parsed instead.
Two sources of truth
The backend's fixed saving is percent-derived and rounded, so it differs from exact price maths by a rand. The client switched preference once, then back. Lesson recorded: get written confirmation before changing the source of truth.
Finding the mobile grid
The target container was located by walking up from the add-to-cart button to the ancestor whose grid areas include the carousel.
Measured on add-to-cart, conversion rate, aov. Test results belong to the client and are shared in conversation, with their permission, rather than published here.
More experiments
View all →Global FMCG group · The quantity selector a bigger agency refused to build
A prospective enterprise client set a challenge before signing: build the homepage test another agency had declined as infeasible. We shipped it, and they became a client.
The hard part. No backend access. The cart had to be driven through its own undocumented API, per product, with the right quantity, from inside the testing tool.
SA tiles & bathroom retailer · Two tests that only worked on a cold cache
A bathroom-set selector and a 'complete your bathroom' panel both showed the same symptom: visible on the first load, gone on the next page and on Back. The bug was in how the experiments were activated, not in the variants.
The hard part. The testing tool's own caching changed the timing. Once its script was cached, it ran before the product form existed, so the activation condition failed and real visitors were silently under-bucketed.