Catalog rules
How we keep the catalog honest
Matchbox lists products automatically from public app stores, launch platforms and open-source registries. That means the catalog contains things we haven’t looked at by hand. Here is what we do about it, and what we never do.
We deactivate, we don’t delete.
A listing goes inactive when its site is gone (checked twice, at least three days apart — a timeout alone never counts), or when it is a duplicate of another listing. Deactivated listings keep their address and point to the listing they were merged into. A listing whose maker has claimed it is never deactivated automatically.
Duplicates and clones.
Two listings for the same product (same operator, same function, different URL or store) are merged; the claimed one wins, otherwise the more complete one, otherwise the older one. Copies of a product under a different domain are treated the same way. Free and Pro editions, or an iOS and an Android app from the same maker, stay separate listings but are grouped.
Thin wrappers stay listed but grouped.
A product that is recognisably another model with a different interface, no identifiable maker and no stated difference stays in the catalog, but is shown collapsed under its approach, ranked after products with a verified maker. If you built a wrapper and it does something different: claim it and say so. That is all it takes to be shown on its own.
App families.
When one publisher lists dozens of near-identical apps that differ only by topic, we show one representative listing for the family. A studio with genuinely different apps keeps all of them.
How results are grouped.
The matcher scores fit; that score is never touched. When it draws the shortlist it judges, at most two listings per website and one per near-duplicate group get a slot, so look-alikes can’t crowd out a genuinely different approach. Where two listings fit equally well, a maker-verified listing, then one with stated pricing, then one with a real description goes first — a tie-breaker, not a boost. Results are then grouped by approach: one starting point per approach, the rest one click away.
Three trust signals, kept apart.
Semantic fit is the matcher’s judgment for your problem. Maker verified means the maker claimed and checked the listing. Human verified means a person installed the product for a specific problem and published what happened (the first verdicts are being prepared). They are shown side by side and never blended into one number.
Store ratings: shown, never weighed.
Where an app is in the App Store or on Google Play, the listing shows what the store publishes: stars, how many people rated it, and on Play the download range. Store ratings differ by country and Apple publishes no global figure, so we show the storefront where the app has the most ratings and name it. We read these the way a search engine does and refresh them regularly. They are a fact for you, not an input for the matcher: ratings never move a product up or down in the results, and a new product with no ratings yet is not ranked lower for it. Apple publishes no download numbers, so we show none.
What is never for sale.
Ranking, placement, a verdict, or a place in the queue for human verification. Verification order follows what people actually search for. Negative verdicts are published like positive ones. Paid tiers buy insight - into demand, and into why a listing ranks where it does - never the rank itself. The rank follows the matching profile, which every maker can edit for free.
Spotted a wrong deactivation or merge? Tell Ben — listings are reinstated by hand.