From US-only to localized: routing visitors to the right App Store

Udgivet af The Language Level Check team

A small bug today, with what we think will be a meaningfully large impact.

We were looking through analytics this week and noticed something odd. We were getting consistent web traffic from a handful of non-US countries, but the app installs we were seeing from those same countries were a much smaller fraction than the traffic suggested. The web-to-install ratio for several specific countries was dramatically worse than our overall average.

We’d assumed the gap was because users in those regions were unfamiliar with the brand and bouncing. The actual cause was less interesting and more fixable.

The bug

Every Apple App Store badge on our marketing site, on the per-language landing pages, in the footer, and in the header nav was a link to https://apps.apple.com/app/id6755918623. That URL doesn’t specify a country. On a phone, that doesn’t matter; Apple’s App Store app opens to your local storefront regardless of what the URL says. But on a desktop browser, that URL redirects to the US App Store. Every time.

So when a non-US desktop visitor tapped our localized download button, Apple sent them to the United States App Store, which showed our app listing in English with US dollar pricing. Conversion at that point is what you’d guess.

The badge image was localized. We’d been swapping the App Store badge SVG to the correct locale variant on the corresponding page. The href wasn’t. The visible language of the button matched the user’s locale; the destination was American.

A meaningful share of our web traffic is desktop, and a meaningful share is non-US. The math says this has been quietly costing us installs since launch.

The fix

Two changes today.

First, every store link on the site now includes a locale-specific country code. The Apple URL is now https://apps.apple.com/{country}/app/id6755918623. For Japanese visitors, /jp/. For German, /de/. For Chinese (Simplified), /cn/. And so on across all 33 locales we support. Google Play links similarly include the hl display-language parameter and the gl storefront-country parameter, so a Spanish visitor lands on the Spanish version of the Play Store page with Spanish pricing.

The country codes aren’t always the obvious match to the language code. Some examples where they differ:

  • Czech (cs locale) → Apple cz storefront
  • Greek (el locale) → Apple gr storefront
  • Ukrainian (uk locale) → Apple ua storefront
  • Norwegian Bokmål (nb locale) → Apple no storefront
  • Catalan (ca locale) → Apple es storefront (no separate Catalan store)
  • Arabic (ar locale) → Apple sa storefront (Saudi Arabia, the largest Arabic-speaking App Store)

These are storefront identifiers, not language identifiers. They’re the result of one team member spending an evening cross-checking ISO 3166 codes against Apple’s actual storefront URLs.

Second, the blue “Download App” button in the header now points to a new /download page instead of going straight to the App Store. The /download page shows the same call-to-action block as the homepage: both the Apple and the Google Play badges, presented as an explicit choice rather than a guess based on the user’s device. Visitors who came to the site on a desktop and want the Android version can finally get to it from the header.

What we expect

We expect a measurable lift in download conversion from non-US desktop traffic. The exact size is hard to predict; we haven’t had this instrumented before.

We added a locale property to our outbound store-click events. Going forward, we can see locale-by-locale whether click-through behavior shifts on the new build. We’ll probably write a follow-up post once we’ve had a few weeks to compare.

What we’re kicking ourselves about

This bug was visible in our raw analytics for months. The pattern (high traffic from a country, low installs from that country) was obvious in retrospect. We assumed the cause was something else without checking. The check, in the end, was a single curl command against the unparameterized App Store URL. Three minutes of work. We should have done it in week one.

General lesson: when a metric looks bad and you have a quick explanation in your head, write the explanation down, then go test it. We didn’t, for too long.

Anyway. If you’re reading this from outside the United States and you’ve ever tapped one of our App Store buttons and ended up on a US listing, sorry about that. The button now goes where it says it goes.