Skip to content

Basket study 03

The 7-step install that became the entire product

Friction as filter. 11% of users, ~55% of measured GMV.

The bet

Apple buries Safari extensions behind seven setup steps. The conventional reading: extensions are dying, so drop the surface and ship mobile-only. The data said the opposite. Extension users tracked nearly 10× the GMV of everyone else (n=185,813) – the people who pushed through the install were the most valuable in the product. The install wasn’t a bug. It was the filter.

Two design judgements

Don’t fight the friction. The instinct is to cut install steps so more people get in. Wrong here: the steps self-select committed users, and easing them would dilute the exact cohort that drives the GMV. The work belongs on making the install worth surviving, not shorter.

It deepens, it doesn’t acquire. Most installers already had saves before install day (funnel below). New users are the share sheet’s job (see case 02); the extension exists to deepen people who already save and want it passive across the web.

Cohort comparison

Same shape on every metric. BigQuery all-time: 20,556 users with the extension, 165,257 without.

Avg saves / user7.1×15221Avg retailers374.1Tracked GMV9.9×£123£1290-day active41.4%5.9%Active span4.6×301d65dHas extension (n=20,556)No extension (n=165,257)
Each metric on its own scale. Friction-as-filter framing – selection bias acknowledged.

Design moves that follow

  • Demo-item onboarding. When the user first enables the extension, a sample product drops into their basket. They feel auto-capture before they grant permissions. item_added_demo_safari fires once per onboarding.
  • Invisible capture post-install. No badges, no prompts, no overlays on retailer pages. Every product page view fires item_added_auto with method=extension silently.
  • Visible reward layer. The extension panel surfaces monetisation moments – found-cheaper cards, coupon attempts, earnings counter, recent saves digest. These are why users open the extension; saves are not.
  • Respect the host. Compact side panel rather than full-page overlay. Other extensions in the same space hijack the retailer’s checkout; Basket deliberately doesn’t.

The install funnel

Most installers were already savers before they installed.

StepUsers% of installers
application_installed14,487100.0%
Had save before install8,48558.6%
Net-new savers (proxy)~1,546~10.7%
Never registered a save4,45630.7%

540-day window

Caveat

Friction is the filter, not a confirmed cause. The 7-step install self-selects committed users, so the multipliers reflect both design and self-selection; causal direction isn’t measurable without an A/B test. And the strict post-install save funnel (% of installers saving within 1h / 1d / 7d of the install timestamp) is approximated here, not directly measured.

How this fits the platform

The Safari extension is one of five live input surfaces in Basket’s polyglot save model (case 02), and the most engaged of them – deepest by saves per user (894), highest first-touch retention (74.4% at 180d). The platform is the schema, not any one surface. This is just the surface that goes deepest.

What I’d do next

  • Auto-coupon retailer thresholds. The coupon detector fires 784K times a year: 62% dismissed, 1.9% applied. It earns its place on beauty retailers and is noise on Amazon and ASOS. Until thresholds ship, it trains people to ignore the extension’s most visible surface – the opposite of the trade we made on the install.
  • Share-sheet → extension graduation. 6,421 users on both surfaces retain at 57% 90d. There’s no graduation prompt in the product. A share-sheet first-toucher with N+ saves should see “install the extension for auto-capture” at the right moment.
  • Strict post-install save funnel. Worth the extra instrumentation – would let us measure whether the demo item actually advances the install-survival rate, or whether it’s decoration.