Why almost everything is done twice
Expert: with sources and numbers. Plain: the same, without them, for beginners.
The multiplication that makes ASO an operational problem rather than a writing problem, and how to keep it tractable.
ASO is not hard because any single decision is hard. It is hard because every decision multiplies.
The multiplication
Two platforms. Different fields, different release binding, different evidence base (00-05).
Times localizations. A Every App Store text field is set per localization, and Apple’s reference lists 50 languages and locales. (App Store localizations, verified 2026-09-18) Play listings localize too.
Times surfaces. Search results, product page, charts, editorial, in-app events, custom pages. Each reads different parts of what you wrote (00-02, 00-03).
Times cadence. A iOS indexed text moves only with a release; Play’s largely does not (10-09, 20-07).
Ten markets on two platforms is not twenty pieces of work. It is twenty field sets, on two schedules, measured in two consoles whose numbers do not agree (80-03).
What this does to a team
Three failures follow from the multiplication, and they are the ones worth designing against.
Partial updates. The primary locale gets revised, the others do not. Then the aggregate result gets read as if it were one change, and someone draws a conclusion about the algorithm. This is the most common way ASO measurement goes wrong.
Drift. Nobody can hold twenty field sets in their head. Without an export, the current state of your own metadata becomes unknown, and the next refresh starts by rediscovering it.
Everything at once. Metadata, creative and a release ship together, and nothing can be attributed to anything. You get a number and no learning.
How to keep it tractable
Keep a current export. Every field, every locale, both platforms, dated. Without it you have no baseline, and without a baseline you can measure nothing (runbooks/quarterly-keyword-refresh). At four or five markets this stops being optional. See 98-08.
Separate the two schedules deliberately. iOS indexed text batches to the release train; Play does not have to wait. Running them on one artificial cadence wastes the flexibility Play gives you.
Tier your markets. A handful get real research and localized creative; the rest get correct, unembarrassing metadata. Attempting fifty markets at equal depth produces fifty mediocre ones. Which tier a market sits in is a business decision, record it, and record why.
Change one class of thing at a time. Metadata this release, creative next, or accept that the quarter produces no clean learning. This is the hardest discipline to hold and the one that most determines whether you learn anything (50-03).
Write down decisions, not just changes. Six months on, the useful record is not what the subtitle said. It is why that term was chosen and what was expected to happen.
What goes wrong
Treating ASO as a writing task. The writing is the small part. The operational load is per-locale state, two release cadences, and attribution.
Scaling by adding markets. Each new locale adds permanent maintenance. An unmaintained localization is worse than none, because it is stale text that users still see.
One process for both stores. Guarantees either an iOS release window is missed or Play changes are held for no reason.
No baseline. Then every result is an anecdote, and every explanation is a story.
In short
Every fact on this page in one line, with its evidence tier, source and verification date, 3 A. Generated from the claim register, so it cannot drift from the page above.
None of this is hard because any single decision is hard. It's hard because every single decision multiplies.
Where the multiplying comes from
Two centres. Different fields, different timing rules, different amount of honest guidance available (see The real differences between the two centres).
Multiplied by every country. Every single field on Apple's side is set separately for each country's version of the sign, and there are a great many of them. Google's listings get translated per country too.
Multiplied by every room. The desk, your window, the busiest-shops boards, editorial picks, time-limited posters, specially-dressed windows. Each one reads a different part of what you've written (see the tours of Apple's centre and Google's centre).
Multiplied by timing. On Apple's side the words the desk reads only move when you do a scheduled refit. On Google's side they mostly don't wait for one (see What requires a refit on Apple's side and What changes without waiting on Google's side).
Running the same shop in a handful of countries across both centres isn't a handful of pieces of work. It's dozens of separate field sets, on two different schedules, tallied by two counters that don't agree with each other (see Where the two centres' numbers don't line up).
What this does to a shop owner
Three failures follow directly from all that multiplying, and they're the ones worth actually planning against.
Half-finished refreshes. The main country's version gets updated, the rest don't. Then someone reads the combined result as if it were one clean change and draws a conclusion about how the desk decided. This is the single most common way a shop owner ends up fooling themselves.
Drift. Nobody can hold dozens of field sets in their head at once. Without keeping a written record, you stop knowing what your own shopfront currently even says, and the next refresh starts by rediscovering it from scratch.
Changing everything at once. The wording, the window photos, and a shop refit all ship together, and afterwards nothing can be credited to anything. You get a result and no actual lesson.
How to keep it manageable
Keep a current written record. Every field, every country, both centres, dated. Without it you have no baseline, and without a baseline there's nothing to measure (see Doing a seasonal refresh of your sign words). Past four or five countries this stops being a nice-to-have. See Managing a shopfront at real size.
Keep the two timetables deliberately separate. Apple's words wait for a refit; Google's don't have to. Forcing both onto one artificial schedule throws away the flexibility Google's side actually gives you.
Sort your countries into tiers. A handful get real attention and locally-made window displays; the rest get correct, unembarrassing basics. Trying to give every country the deep-attention treatment produces a pile of mediocre ones instead. Which tier a country sits in is a business call. Write it down, and write down why.
Change one kind of thing at a time. Wording this refit, window display next, or accept that the quarter teaches you nothing clean. This is the hardest discipline to hold to, and the one that decides most of whether you actually learn anything (see Designing a real test).
Write down the decision, not just the change. Six months later, what the line beneath your sign used to say isn't the useful record. Why that particular wording was chosen, and what you expected to happen, is.
What tends to go wrong
Treating this as a writing task. The writing is the small part. The real weight is keeping track of every field in every country, two separate timetables, and working out what actually caused what.
Growing by just adding more countries. Every new country you add becomes permanent upkeep. An abandoned, stale listing is worse than none at all, because shoppers still see the stale version.
Running one process for both centres. You will either miss Apple's refit window, or hold Google's side back for no good reason.
Having no baseline. Then every result is a story you're telling yourself, and every explanation is a guess dressed up as an answer.