https://yelmeatlas.com/blog How YelmeAtlas turns app store reviews into honest findings: the algorithms, the thresholds, the engineering. en https://yelmeatlas.com/blog/en/01-a-map-for-thousands-of-reviews https://yelmeatlas.com/blog/en/01-a-map-for-thousands-of-reviews An app with a few thousand reviews produces more free text than any one person can reasonably read — yet most teams still decide based on two numbers: the star average, and whatever anecdote came up last in a meeting. This article describes the problem behind that gap, why the obvious workarounds (read more, stare at the stars, rent a generic sentiment dashboard) don't fix it, and how YelmeAtlas instead builds a small, auditable pipeline of collecting, counting, clustering and rule-based reporting — no language model, no developer account required, and an honesty floor that's allowed to say "the data isn't enough for that." https://yelmeatlas.com/blog/en/02-topics-that-earn-their-name https://yelmeatlas.com/blog/en/02-topics-that-earn-their-name Automatically grouping free text into topics sounds like a solved problem — TF-IDF and k-means have been around for decades. Applied naively, though, the method lies in three distinct ways: it turns the app's own name into a "topic," it collapses into one giant cluster on small samples, and it can be pushed out of balance by over-aggressive filtering. This article shows the three additional rules that decide whether a topic is allowed to keep its proposed name — backed by the measured before/after comparisons that led to each rule. https://yelmeatlas.com/blog/en/03-getting-data-without-a-developer-account https://yelmeatlas.com/blog/en/03-getting-data-without-a-developer-account Two barriers normally stop anyone from analysing a different app's reviews: the developer account, which only the app's owner holds — and the stores' own short memory, which lets old reviews vanish from their public feeds. This article shows how YelmeAtlas gets around both: a single input field that figures out on its own which store is meant, and a nightly archiving run that secures reviews before the store forgets them — with a clear rule for the failure case: one stuck app must never cost every other app its day of history. https://yelmeatlas.com/blog/en/04-complaint-rate-and-days-that-stand-out https://yelmeatlas.com/blog/en/04-complaint-rate-and-days-that-stand-out A star average moves sluggishly — a single bad day gets absorbed into it long before it noticeably shifts the mean. This article shows how YelmeAtlas defines a complaint, how a complaint rate gets computed over a time window, and the one arithmetically simple rule that marks a day as "unusual" — the same rule that feeds both the API and the PDF report, so the two can never disagree. https://yelmeatlas.com/blog/en/05-the-report-that-can-say-no https://yelmeatlas.com/blog/en/05-the-report-that-can-say-no Many analytics tools always deliver an answer — even when the underlying data is genuinely too thin for one. That creates false confidence. This article shows how the YelmeAtlas report does the opposite: below 30 reviews it deliberately withholds recommendations, and every recommendation it does make cites a number from the same report — including a counter-calculation that shows exactly what happens if you act on the advice. https://yelmeatlas.com/blog/en/06-two-apps-one-look https://yelmeatlas.com/blog/en/06-two-apps-one-look "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. https://yelmeatlas.com/blog/en/07-the-bug-behind-227-green-tests https://yelmeatlas.com/blog/en/07-the-bug-behind-227-green-tests All 227 automated tests were green — and yet every review saved through what would later become the web dashboard vanished, without a trace, the next time the server restarted. This article isn't about an algorithm; it's about a challenge: how a bug can exist that a green test run simply cannot show, which three fixes we weighed against each other, and why the one we chose doesn't just patch the symptom but makes repeating the mistake structurally impossible. https://yelmeatlas.com/blog/en/08-two-writes-that-must-never-come-apart https://yelmeatlas.com/blog/en/08-two-writes-that-must-never-come-apart Every incoming review has to trigger two things at once: get saved — and notify the rest of the system that it exists. If the process crashes exactly between these two steps, the worst case is a saved review nobody else ever learns about, or a notification about a review that was never actually saved. This article shows the challenge, three approaches we weighed against each other, and the so-called outbox pattern we settled on. https://yelmeatlas.com/blog/en/09-direct-or-indirect-what-store-reviews-can-tell-you https://yelmeatlas.com/blog/en/09-direct-or-indirect-what-store-reviews-can-tell-you Customer feedback management draws a line between direct feedback — actively requested, such as surveys or post-purchase questionnaires — and indirect feedback — unsolicited, public, offered without anyone asking for it. App store reviews sit squarely on the indirect side: writing one is a choice, and most dissatisfied users never make it — they simply switch, silently. Even among those who do write, not every text is a complaint: a bug report, a feature suggestion, a support experience, a question, and genuine praise belong at five different desks, not in one shared complaint bucket. This article shows how YelmeAtlas reads feedback kinds out of raw reviews, why an unanswered review is itself a source of complaints — and what a review can never, structurally, show.