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.
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_safarifires once per onboarding. - Invisible capture post-install. No badges, no prompts, no overlays on retailer pages. Every product page view fires
item_added_autowithmethod=extensionsilently. - 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.
| Step | Users | % of installers |
|---|---|---|
application_installed | 14,487 | 100.0% |
| Had save before install | 8,485 | 58.6% |
| Net-new savers (proxy) | ~1,546 | ~10.7% |
| Never registered a save | 4,456 | 30.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.