How People Use IngrediCheck: Anonymized Usage Data

The denominators matter. A user is not a scan, and a family record is not necessarily a household or a set of separately registered people. The verdict table also has a narrower denominator than the complete scan population because it excludes completed rows that did not map to the current verdict vocabulary.

You can download the complete privacy-safe aggregate dataset. It includes the dated method, category definitions, exact disclosed counts, denominators, rounding, privacy rules, and limitations used on this page.

The observation window contains 90 complete UTC days, beginning April 30, 2026 and ending after July 28, 2026. We froze the population, categories, exclusions, verdict mapping, and minimum cell size before inspecting any aggregate result.

An eligible person needed a real iOS, iPadOS, or Android device registration on an app version beginning with 2 and at least one non-deleted mobile barcode, photo, or barcode-plus-photo scan during the window.

We excluded:

• internal users and devices
• App Store Review traffic
• people without an eligible version 2.x mobile device registration
• deleted scans
• web-page scans, because this report concerns the shipped mobile workflow

The production query returned aggregate rows only. It did not select or export identifiers, email addresses, locations, IP addresses, barcodes, source URLs, Food Notes, product or ingredient data, image data, analysis explanations, feedback, comments, or other free text.

The privacy rule

We publish an exact user-level cell only when it represents at least 20 distinct eligible users. A family-level cell must represent at least 20 distinct eligible family records. Twenty is a conservative IngrediCheck publication rule, not an official standard, legal safe harbor, or guarantee of anonymity.

We also reviewed the article, tables, totals, percentages, and downloadable data together. This checks whether a hidden value could be reconstructed by subtracting other published figures. Every predeclared cell selected for this release passed the applicable threshold, so no primary or complementary suppression was required.

This release design follows a simple principle reflected in official statistical privacy guidance: removing names is not enough. The public output, its combinations, and what someone could infer from other available information all matter.

For each eligible user, we counted distinct UTC dates with at least one included scan.

The most defensible wording is that 172 eligible people were observed scanning on multiple days in the fixed window. Calling this a retention rate would overstate the result. Someone who first appeared near July 28 had much less time to return than someone who first appeared in May. The measure also does not separate a planned later shopping trip from repeated attempts during one unresolved task.

It would be tempting to call multi-day activity loyalty or satisfaction. The events do not measure either. They show repeat observed use, nothing more.

IngrediCheck accepts a barcode, a label photo, or a stored combined barcode-plus-photo path. The 3,899 included scans split this way:

The distinct-user column overlaps. A single person can use a barcode on one product and a photo on another, so those user counts should not be added together.

The event distribution does not establish that users prefer one input. It also does not prove that a barcode or image was recognized correctly. It says only which stored path produced each included scan. For the practical difference between those paths, see our guide to barcode scans versus current label photos.

IngrediCheck can keep separate member profiles inside a family record. Among 496 eligible family records associated with the scanning population:

This answers a structural product question: multi-profile records were used during the window and the cell was large enough to disclose. It does not tell us how many people lived together, whether each profile represented a separately registered user, or why the profiles were created.

User and family-record counts do not reconcile one to one. The family analysis uses its own denominator and should not be compared directly with the 532-user total. Readers exploring the broader workflow can start with the food ingredient checker or browse the ingredient checker and food scanner guides.

For every included scan, we selected the latest stored analysis row at extraction time. Of 3,899 scans:

No analysis row is not a failure rate. The aggregate does not distinguish a barcode with no usable product record, an abandoned flow, or another route that produced no analysis row. It would be misleading to collapse all of those possibilities into “the app failed.”

The verdict view uses only completed latest analyses with no stored error and an overallMatch value that maps to the current Matched, Unmatched, or Uncertain vocabulary.

There were 2,963 completed, error-free latest analyses. Of those, 2,855, or 96.4%, mapped to the current vocabulary. The remaining 108 were excluded from the verdict denominator.

Again, distinct-user counts overlap. One person can have scans in more than one verdict category.

These stored verdicts are personalized to the Food Notes applied at scan time. “Matched” means the stored analysis matched those rules under the product workflow. It does not mean the food was independently classified as safe, healthy, allergy-proof, or correct for everyone.

The usage events do not independently test whether a verdict was correct, whether declared ingredients were complete, whether cross-contact occurred, or whether a product was safe for a specific person. They also do not measure user satisfaction or health outcomes. The ingredient checker app guide explains the workflow and its practical limits in more detail.

This release can support descriptive statements about observed app activity. It cannot support claims about:

• why users returned or chose an input
• whether users were satisfied
• whether an individual verdict was accurate
• whether a scanned product was safe
• whether IngrediCheck changed a health or shopping outcome
• whether the eligible population represents all users or the public
• whether one observed factor caused another

The results do not show that one factor caused another. A relationship between repeat use, input type, profile structure, or verdict category would need a different study design and more evidence.

The report also stays separate from the anonymized usage stories shown elsewhere on the site. Those stories illustrate first-party context. This aggregate report measures operational events. They are not testimonials or independent validation, and neither should be presented as third-party proof.

• Ingredient Checker App: Food Ingredient Checker and Label Scanner
• Best Food Allergy Apps for 2026: Yuka Alternatives Compared
• Barcode Scan vs Label Photo: Which Should You Trust?
• Food Label Scanner vs Nutrition App: What's the Difference?

First-party data can be useful when its owner, method, denominator, and limits are visible. It can show whether a product capability appears in real aggregate activity without inventing quotes or implying that usage equals endorsement.

The tradeoff is restraint. A smaller honest claim is more useful than a broad one the data cannot support. Here, the supportable findings are that multi-day use occurred, all three scan-input paths appeared, some eligible family records contained multiple profiles, and the stored analysis and verdict categories had observable aggregate distributions.

For readers comparing food-scanner workflows, our 2026 food allergy app comparison keeps product facts and editorial judgments separate. This page adds a different evidence type: first-party operational aggregates about IngrediCheck itself.

IngrediCheck helps people compare packaged-food labels with the rules and preferences they have saved. This report does not ask readers to trust that promise because of a testimonial. It shows a privacy-safe slice of how the shipped barcode, label-photo, family-profile, and three-state verdict workflow appeared in aggregate activity, together with the boundaries needed to interpret it honestly.