Keyword Cannibalisation: When Your Own Apps Fight Each Other

A client sent a spreadsheet asking why two of their apps ranked differently for the same term, and whether both could rank at the top.

I asked one question first: are these two apps for the same people? Yes — one was the main app, the other a stripped-down version built to test the waters.

That changes the question. They cannot rank together because they are fighting for the same slot.

The short version

Cannibalisation comes in two shapes, and confusing them leads to the wrong fix.

The first is several of your own apps fighting over one term. The second is one app whose own fields, or its own language builds, fight over one term. The first usually means the product line was never thought through. The second means character budget is being wasted.

The fixes are opposite. The first needs splitting. The second needs merging.

The common mistake is treating the second as if it were the first: teams build differentiated positioning for two apps, then find the volume they lost came from the main app undercutting itself.

The store does not know you are one company

Ranking logic has no concept of "same publisher". It knows how well this app matches this term, and how popular this app is.

So two of your apps fighting over one term have exactly the relationship of two competitors fighting over it. You win and lose against yourself, and the total does not double because you shipped a second app — result slots are fixed, and so is the user's patience for scrolling.

The bigger cost is operational. Ad budget, review management, release cadence, all split across two apps. Each looks underfunded alone. Together they add up to one app done badly.

Internal cannibalisation is harder to spot

This shape is sneakier because it never shows up in a report.

An English build and a Chinese build of one app targeting the same English long tail will crowd each other in some markets. What you see is "we had two positions and one dropped", easy to blame on an algorithm shift. In reality a sibling pushed it down.

Title, subtitle and keyword field all carrying the core term is the same pattern at smaller scale: three withdrawals of character budget for one deposit of index signal. The association is binary — written three times or once, it lands in the same place.

The signature is that nothing errors, nothing visibly drops, and efficiency quietly leaks. Which is why it survives for years.

Language builds are the case that looks like a bug

Multiple language builds exist to cover users in different languages. But language and region are not the same axis: an English build may ship in several English-speaking markets, a Chinese build may serve several regions. When two builds are reachable in one market and both fill their fields with the same terms, they collide.

The symptom looks like a weighting change: impressions for a term rise while installs stay flat, or one build drops a position as another rises and the sum does not move. Two of your own builds swapped seats.

In some markets users search in a second language, and an English build next to a local-language build can be correct — but only if their fields serve different search habits, not if one term list was pasted into both.

When multiple apps is genuinely a strategy

Multi-app coverage is not a sin. Two cases hold up.

One is audience difference too wide for one app. A build for professionals and a build for beginners differ in depth, interface complexity and pricing. Cramming both into one leaves both sides unhappy.

The other is a use case demanding a different first impression. A utility and a content community should look like different things when a user searches different terms.

The test is not "can I build a second app". It is: is there a term only this app can win? If the two term lists overlap heavily, the second app's reason to exist is in question.

Splitting is also not the same as keeping two apps alive identically. A second app with half the features and a new skin is still the same product — building one product twice, cost doubled, ceiling unchanged.

How to tell if you are doing it

Three signals, coarse to fine.

Put every app's target term list side by side and look at the overlap. If it sits on a few head terms, you are stepping on yourself.

Search that term and count how many of your own apps appear. Two appearances, both mid-page, is double waste rather than double insurance.

Then look at user overlap. If the same person plausibly installs both, they are duplicates inside your portfolio. That is the most convincing signal and the hardest to get data for; the first two can be judged from public results.

The fix is splitting, not deleting

The tempting move is to have each app delete half its terms. That makes both weaker, not both stronger.

Split instead. Give each app an intent range it suits and keep both inside their lanes. A main app takes category head terms and brand terms. A lite build takes modifier-style long tail: lightweight, minimal, low storage. The first group of searchers wants completeness, the second wants to be left alone.

There is a useful side effect. Splitting forces each app's positioning to become explicit. The fuzziness was survivable while overlapping terms covered for it. Remove the cover and you have to decide what each app is.

The brand term exception

One overlap is legitimate: the brand term.

When a user searches your brand, seeing all your apps is normal, arguably correct. There is no cannibalisation — the user already knows they want you, they are choosing rather than discovering.

The precondition is that the brand is something people actually search. Without recognition, a brand term in your fields is pure cost. Multiple own apps in a brand search is fine as long as each listing makes clear what it does. Not being able to tell them apart is the real problem.

When to ignore this entirely

If you have one app, read the internal-waste sections and stop. If the category has not been built and search volume is thin, arguing about shared terms is pointless — grow the category term first.

The criterion is simple: what share of your installs comes from the overlapping terms? Small share, leave it. Large share, deal with it — this is the one kind of waste where you work in the right direction and the total does not move.

This is also never finished. Every new app and every new language build recreates the overlap. Put it on the pre-launch checklist.

What to do next

1. Put every app's target term list side by side and mark the overlap. One table is enough. 2. For each overlapping term, run the search once and note how many of your own apps appear and where. 3. Write one sentence per app: which terms can only this app win? If you cannot write it, its reason to exist is not settled. 4. After splitting, record the terms each side gave up and check their impressions a month later. If the total held, the overlap was waste all along.