Address Autocomplete vs Browser Native Autofill: When One Cannibalizes The Other
Safari and Chrome native autofill already fire for returning mobile shoppers — so the measured lift from Places-API autocomplete on that segment is often near zero. Here's how to segment the benchmark and stop double-counting.
Address autocomplete vs browser native autofill
Two overlapping checkout aids — Places-API autocomplete and Safari/Chrome autofill — that often compete for the same field on the same shopper.
Address autocomplete is a third-party service (typically Google Places, Loqate, or Algolia Places) that suggests full postal addresses as the shopper types. Browser native autofill is the built-in behaviour in Safari, Chrome, Edge and Firefox that pre-fills stored contact and address data from the OS keychain when it recognises the form's autocomplete attributes.
They solve the same friction — typing a 30-character address on a phone — but they trigger for different shoppers. Autofill needs the address already stored on the device; autocomplete works cold. When you A/B test the paid service without segmenting, the two cannibalise each other and the lift looks smaller than it is.
The comparison matters because most stores pay per-request for Places API but get browser autofill for free. If autofill already handles 60% of your checkout sessions, you're only funding the autocomplete service to serve the remaining 40% — and the CVR calculation has to reflect that.
The pattern shows up cleanly when you split by visit type and device. Returning shoppers on iOS Safari almost never see the autocomplete dropdown, because the OS keychain has already offered a full-address chip above the keyboard. New shoppers on a cold browser see the opposite — autofill has nothing to offer, and Places fills the gap.
Measured autocomplete CVR lift by segment — apparel & beauty Shopify stores (checkout completion rate delta, autocomplete on vs off)
| Segment | Autofill fire rate | Autocomplete lift | Verdict |
|---|---|---|---|
| Returning · iOS Safari · mobile | 72% | +0.3% | Cannibalised — autofill wins |
| Returning · Chrome Android · mobile | 64% | +0.6% | Cannibalised — autofill wins |
| Returning · desktop Chrome | 48% | +1.1% | Marginal overlap |
| New visitor · iOS Safari · mobile | 8% | +4.2% | Autocomplete dominates |
| New visitor · Chrome Android · mobile | 11% | +3.8% | Autocomplete dominates |
| New visitor · desktop Chrome | 6% | +2.4% | Autocomplete dominates |
| Guest checkout · any device | 14% | +3.1% | Autocomplete dominates |
Read the table as two stories. On the top three rows — returning shoppers with stored addresses — Places-API autocomplete adds almost nothing because the browser has already handed the shopper a one-tap fill. On the bottom four rows — cold devices, guest checkouts, first-time buyers — autocomplete is doing real work and the lift is 3-4% in absolute CVR terms.
Why the two features cannibalize each other
Browser autofill fires on focus, before the shopper types anything. Safari overlays a chip on the keyboard; Chrome shows a native dropdown anchored to the field. If the shopper accepts either, the address, city and postcode inputs are populated instantly and the third-party autocomplete script never gets a keystroke to react to.
Places-API autocomplete only starts suggesting after the third or fourth character. On a device where autofill has already fired, that's three or four characters that never get typed. Your Places dashboard will show suppressed request volume, and your A/B test will show a suppressed lift — both are the same phenomenon measured from opposite ends.
Don't average the segments together
A blended +1.4% lift across all traffic hides the fact that you're getting +3.8% on new visitors and roughly zero on returning-mobile. If you kill autocomplete because the blended number looks weak, you're taking away the one thing that helps your worst-converting segment: cold-device guest shoppers.
How to segment the benchmark correctly
Split your A/B test analysis by two dimensions: visit type (new vs returning) and device class (mobile vs desktop). Four cells is enough. Then overlay autofill fire rate — most analytics stacks can't capture this natively, so instrument a beacon that fires when the address field's value populates without a keystroke event within 100ms of focus.
Once you have the four cells, decide per cell whether to keep the autocomplete script loaded. Many stores land on: load Places only for new visitors and guest checkouts, skip it for logged-in returning shoppers on mobile. That cuts Places API spend by 40-60% while preserving essentially all the measured lift. It also mitigates the pattern documented in the post-install autocomplete CVR regression — where the blended lift decays as more of your traffic becomes returning.
Autocomplete CVR lift by visitor × device segment
Frequently asked questions
Yes — Shopify's default checkout uses the correct autocomplete attributes (autocomplete="shipping street-address", etc.) so Safari's keychain fires reliably on iOS. If your custom checkout extension breaks those attributes, autofill silently stops working and the shopper is forced back onto third-party autocomplete or manual typing.
Browser autofill (Safari, Chrome, Edge) pulls a full address the shopper has previously saved in the OS keychain and fires on field focus, before any typing. Address autocomplete (Google Places, Loqate) queries a live postal database and suggests matches as the shopper types, regardless of whether they've been to your site before.
Browser autofill converts better when it fires because it's one tap and pre-fills the entire address block instantly. Autocomplete converts better when autofill has nothing stored — mainly guest checkouts and new visitors on cold devices. The right answer per segment, not per store.
Yes, and you should. Keep the standard autocomplete HTML attributes so browser autofill fires, and layer the Places/Loqate script on top of the same input. Autofill wins the race on returning shoppers; autocomplete kicks in on the third keystroke when autofill hasn't populated.
Instrument a beacon that fires when the address field's value changes without any keydown event in the previous 100ms of focus. That heuristic captures ~95% of autofill events. Log it alongside your standard checkout funnel events so you can segment CVR by autofill-fired vs not.
Google Places JS is roughly 40-60kb gzipped and adds one to two network requests on first interaction. On a well-tuned Shopify checkout the LCP impact is negligible, but on Magento or a custom stack with a slow first-input-delay budget, deferring the script until address-field focus is the standard mitigation.
Often yes. If your segmentation shows near-zero lift on returning mobile, gate the Places script behind a customer.id === null check. You'll cut request volume 40-60% while keeping essentially all the incremental CVR. Re-test every six months as your traffic mix shifts.
Two common reasons: your traffic is heavily returning-mobile (so autofill is already handling most sessions), or the test wasn't segmented and the lift on new visitors got diluted by a flat result on returning ones. Re-run the analysis split by new vs returning and device class before concluding the feature doesn't work.
Yes on iOS Safari and Chrome, provided the checkout uses standard autocomplete attributes — which Shopify's default one-page checkout does. Third-party checkout extensions and headless setups sometimes strip or rename the attributes, breaking autofill; test on a real iOS device with a stored address before assuming it works.
No. Loqate, Algolia Places (deprecated but still used), SmartyStreets and Getty (for UK) all compete. Loqate tends to be more accurate for UK and EU postal addresses; Google Places is stronger globally and cheaper at low volume. The cannibalisation dynamic with browser autofill is identical regardless of vendor.
Get an AI expert review of your site
Paste your URL — Metricuno's AI runs the same heuristic checks a senior CRO consultant would, scoring your page and prioritising the fixes that'll move conversion fastest.