Two Apps, One Look

Part 6 of the "Behind the Map" series — how two apps get evaluated side by side, without a second account for the one you don't own

Abstract

"Is our complaint rate bad, or is that just the whole category?" is a question that can't be answered without a comparison number — and both your own app and a competitor's run into the same structural barrier from part 3: no developer account for an app you don't own. This article shows how the two-app comparison in the dashboard works: two independent, fault-tolerant queries, and a single sentence that names the difference in words — never just in colour.

1. Diagnosis: a number alone has no scale

30 % complaint rate — is that a lot? A little? Without a reference point, any single metric is context-free. The exact same number can be normal in a category with notoriously dissatisfied users (streaming, mobile carriers) and a clear warning sign in another (productivity-focused niche apps). Without a reference value, that judgment can't be made — and the most obvious reference value is your own competition.

The structural barrier stays the same as in part 3: anyone wanting to see a competitor's complaint rate gets no access at all through the official developer consoles — the reviews are public, but nobody makes them comparable by default.

2. Existing approaches and their limits

• Buy a market research report. Expensive, rarely current, rarely fit to your own small niche.
• Manually install the competitor's app and form an impression. Not measurable, not repeatable, not backed by a number.
• Rent a tool with its own developer access. Only solves this for your own app, never for a competitor's (see part 3).

3. The YelmeAtlas approach

The principle: two fully independent single-app evaluations, merged into one view. There's no separate "comparison engine" — the same mechanism that evaluates a single app (parts 2–5 of this series) simply runs twice in parallel, for two app IDs at once. The only genuinely new part is merging the result into one sentence.

4. The algorithm in detail

flowchart TD
    A["User enters two app IDs"] --> B1["Evaluate app A<br/>(independent call)"]
    A --> B2["Evaluate app B<br/>(independent call)"]
    B1 --> C{"Both done?"}
    B2 --> C
    C --> D["One sentence: the difference in words<br/>never just in colour"]
    B1 -.-> W1["Both apps join the watchlist —<br/>from now on the competitor<br/>accumulates history too"]
    B2 -.-> W1

Two independent calls, deliberately uncoupled. If the two queries were technically chained together (say: "wait for both, then show something"), a store outage on app A's side would cost the answer for app B too — even though B would have been available on its own. The two runs are deliberately separate pipelines: a failure on one side has no effect on the other.

The comparison sentence. Once both sides have answered, exactly one sentence forms across both columns. On a tie:

"A tie: both at {percent} % complaints."

On a difference, verbatim from the translation file:

"{worse app} is {gap} points worse: {higher rate} % against {lower rate} % at {better app}."

The rule behind it is deliberate: the difference is always named in words, never carried by colour alone — a red tile on its own doesn't say how much worse, and isn't reliably readable for anyone with colour vision deficiency.

The side effect that doesn't stay a side effect. The moment two apps get compared, both automatically join the watchlist — including the one you don't own. From that point on, the nightly archiving run from part 3 starts collecting history for the competitor's app too. A comparison repeated next month then shows an actual trend instead of today's same snapshot. This side effect is deliberately built so that a failure in it (say, from an exhausted trial period) never costs the actual comparison answer — it runs quietly in the background and is allowed to fail without the user ever noticing.

5. A measured example

Two apps at 44 % and 8 % complaint rate in the same window produce the sentence: "App A is 36 points worse: 44 % against 8 % at App B." A single number — 44 % — reads as alarming or harmless depending on what you expected. Set against 8 %, the direction of the judgment becomes immediately clear.

6. Limits of the method

• The comparison works for exactly two apps at once, not a whole category — evaluating an entire market of competitors is a different, larger problem.
• Topics are not automatically matched between the two apps — what's compared are metrics (rate, trend over time), not whether "advertising" carries the same weight at app A as at app B. Avoiding that on purpose prevents a false impression of equivalence between topics that are, in substance, different.
• The first evaluation of a newly compared competitor shows only the current snapshot — the trend over time only emerges once the comparison is repeated, as the nightly archive grows.

7. Conclusion

The competitor comparison doesn't need new evaluation logic — it only needs permission to run the same logic twice in parallel, without a failure on one side dragging down the other. And it needs the discipline to name the difference in one sentence anyone can read — not in a colour that only signals "better" or "worse," but not by how much.

That closes out the first round of this series. It follows the same idea from start to finish: not more intelligence, but more discipline — collect without a barrier, archive before the store forgets, count instead of summarise, and stay honestly silent when the numbers don't support a claim.

The second round shifts perspective: not algorithm after algorithm anymore, but two concrete engineering challenges we worked through — which paths we considered, and why we chose differently. → Part 7: The Bug That Hid Behind 227 Green Tests

← Part 5: The Report That's Allowed to Say No · Back to the overview