Methodology · how this is made

How every number on this site is made

TrackGap reads public App Store reviews and sells the analysis. If you're evaluating it for a company — or writing the memo that says yes — this page is the receipt: where the data comes from, what gets kept, how complaints get classified, and where the method stops. Every figure on it is injected from the dataset when the site is built, so there is nothing here for a human to remember to update.

Data 19 Sep 2026 Reviews collected 22 Sep 2025 – 19 Sep 2026 46 apps · 3 app groups Source: Apple's public review data, US App Store
46
apps tracked across 3 groups
18,145
written reviews in the pool
12,469
of them are 1–2★ — the negative pool
7,000
matched a category (56.1%)
19 Sep 2026
corpus date — never the build date

Where the data comes from

Two public Apple surfaces, and nothing else:

US App Store storefront. No logins, no App Store Connect access, no private data, nothing circumvented. The pipeline is read-only: it fetches public endpoints, it operates no accounts, it has no write path — nothing is ever sent to a reviewer, on anyone's behalf, by this system. Every input is re-fetchable: point the same public endpoints at the same apps and you get the same raw material. Any complaint rate we publish can be recounted on the app's own App Store page.

What gets kept — and what never leaves the machine

What we publish: counts, percentages, ranks, and functional phrases of at most a few words. "cancel subscription" describes a feature; it is not anyone's sentence. No review text, no usernames, no avatars — not on free pages, and not in paid reports either.

What stays private: the fetched review text is working material. It sits in a private directory on the build machine, is used to compute the classifications, and is excluded from every deploy by explicit exclusion lists — raw data files are never packaged into the site.

Enforced, not promised. Before anything ships, an automated leak check diffs every published page against the entire raw review corpus — whole passages and any run of eight consecutive words — and fails the build on a match. The legal red line is guarded by a script that runs on every build, not by anyone's memory.

We do not resell or forward review data to anyone — including your competitors.

How a complaint gets its category

Classification is a fixed rule set in one file: hand-written phrase patterns per category, tuned and spot-checked against real samples (the rule file documents what each pattern was tightened to exclude). No language model anywhere in the pipeline — nothing drifts between runs, and your report and your competitors' are produced by the identical rules, which is what makes a gap between you and them arithmetic rather than narrative.

The current corpus exercises 16 categories:

crashes & stabilitymissing featurespricing subscription & cancellationbilling & charge errors broken by an updateunresponsive supportslow performance beaten by a named rivalconfusing interfacesign-in problems sync failureswrong datatoo many ads

Each negative review gets one primary category, by a fixed priority order — so category counts always sum to the classified total, and two apps' breakdowns can be compared line by line. When a review matches several categories, the priority decides; the rule file is versioned, so last quarter's numbers and this quarter's are auditable against the same rules that produced them.

The number most vendors would hide

Of the 12,469 one- and two-star reviews in the current pool, 7,000 matched a category. That is 56.1%. The remaining 5,469 are reported as unclassified — never forced into the nearest bucket.

We print this because an unclassified complaint is information: usually a real category we haven't built yet. Forcing it into an existing bucket would make every percentage prettier and every category noisier. Per-app coverage currently runs 21%–80%, and every page and report prints its own coverage figure, so you can recompute it yourself.

One corollary: if a review-analysis vendor shows you 100% classification coverage, ask what they did with the remainder. Someone has to be counting it.

Limits we print rather than manage around

How fresh any of this is

The pool-wide numbers on this page describe the corpus as of Data 19 Sep 2026; written reviews were collected between 22 Sep 2025 – 19 Sep 2026. Each app group is collected on its own day, and every page prints the collection date of the corpus it was computed from — that date comes from the dataset itself, never from the day the site happened to be rebuilt.

The site is static and rebuilt from the corpus: numbers change when the corpus changes, and are never edited in place. And a difference only gets reported as a change once there are two observations to subtract — one data point is not a trend, so we don't present it as one.

Lines we don't cross

That's the whole trick

Public data, fixed rules, published coverage, printed limits. What you'd be paying for is that someone already ran it on the apps you care about — and will show you the arithmetic.