A bounding box around a package is useful, but a retail team usually needs to know more: which product it is, whether the match is credible, what price tag belongs to it, and how that product's recorded prices changed over time. Our Retail Analytics application connects those tasks instead of treating image recognition as an isolated demo.
We developed the application for a private client workflow. The public Retail Analytics case study shows the capabilities without linking visitors to the client's operational system.
Move from a photograph to an inspectable product record
The application has two connected working areas. The image processor handles shelf photographs, detections, product matches, and review. The data-delivery workspace handles the product catalog, structured attributes, reference imagery, and linked price history. A user can move between the visual observation and the catalog record it refers to.
That connection is the important product decision. A detected item is not just a colored rectangle; it can carry a proposed SKU, catalog details, and an associated price observation. The interface makes those pieces available for inspection rather than asking the operator to accept a label with no supporting context.
Separate the stages that can fail differently
The recognition workflow distinguishes product detection from price-tag detection and exposes their confidence controls separately. That reflects the scene: a package boundary, a small shelf label, and a catalog match are different problems. Adjusting one stage should not require pretending all uncertainty belongs to a single universal confidence score.
The application supports more than one input image, with a stitching path for a combined view. Its processing settings also include planogram and traditional-trade modes. These are explicit workflow options, rather than a claim that one fixed interpretation works for every shop format.
After processing, the workspace summarizes detected items, unique products, and elapsed processing time. Those are observations from the current run. They help an operator inspect the result, but they are not a substitute for evaluating recognition quality on a reviewed dataset from the intended environment.
Put the predicted match beside the evidence
The review interface places the cropped shelf product beside the predicted reference image. Users can enlarge the images, inspect similarity, and correct the crop when the detected boundary is unsuitable. This gives a person a practical way to distinguish a poor localization from a wrong catalog match.
When the proposed identity is wrong, the user can search and select a different SKU. Recommended candidates and catalog details help keep that correction inside the same workflow. The goal is to make the next useful action available at the point where the operator notices a problem.
The application also supports adding an accepted product crop to the reference index and reversing that addition. Indexed images have explicit verification states such as correct, incorrect, unclear, and unverified. That turns reference maintenance into a visible activity rather than allowing an ever-growing collection of unchecked examples to become invisible model infrastructure.
Keep visual identity connected to structured data
The data-delivery workspace provides search and filters for brand, category, family, and record ownership, alongside product-detail editing. An operator can inspect a product's standard name, SKU, imagery, and category relationships without opening an unrelated administration tool.
That structured layer matters because catalog data changes independently of photographs. Packaging can be updated, naming conventions can be corrected, and related source records may need to point to the same catalog product. A usable recognition application needs a place to manage those relationships, not just a model endpoint.
Reference images and catalog records play different roles. An image is evidence for a visual match; the product record is the application identity. Keeping those roles distinct allows several useful reference views to support one product without turning each photograph into a different SKU.
Connect the recognized product to observations over time
A catalog product can link to one or more source-product records for price history. The interface lets users search for those records and inspect a combined history. This is especially useful when different collection sources or naming variations would otherwise leave related observations scattered across separate entries.
The indexing workflow preserves the date, store, city, currency, and source context associated with an observation. It sorts history deterministically and removes repeated observations according to the application's defined key. A chronological chart becomes more useful when an analyst can understand what each point represents.
The distinction between an observed shelf label and a historical catalog price also remains important. One belongs to the current image-processing result; the other comes from recorded source data. Connecting them enables comparison without implying that every historical price was read from the photograph currently on screen.
Make the output useful outside the application
The image processor can export structured results for the processed photographs. The export includes the image name, processing date, family, category, brand, product name, SKU, detected price, and counts per image and across the processed collection.
This creates a concrete handoff from visual analysis to a downstream reporting workflow. A person can review the identities in the application and then work with a tabular result rather than manually transcribing tooltips from a shelf image.
Those counts describe detected visible instances. They should not be described as a complete physical inventory of stock hidden behind the front row. Similarly, a product match that still needs review should not acquire a stronger meaning simply because it appears in a CSV file.
Treat synchronization as an observable job
The application includes operational controls for synchronizing source data and maintaining price-history indexes. The settings interface exposes the current stage, progress, logs, completion timestamps, and whether a stop has been requested. Scheduled and manual runs can be distinguished.
That visibility matters when the catalog and historical observations are larger than a one-off demonstration. If a synchronization job fails or is still running, the operator needs to understand that state before interpreting a missing product or an incomplete history as an analytical conclusion.
Keeping recognition and data maintenance connected also makes troubleshooting more specific. A missing match may require a reference image, a corrected catalog relationship, or a completed index update. Retraining a detector is not automatically the right response to every missing result.
Enrich the prediction without rewriting it
The recognition handler accepts one encoded image or a list of images. For a list, it first calls the stitching service and uses the returned combined image for recognition. The recognition request carries separate product and price-tag confidence parameters and the traditional-trade flag. These parameters belong to the integration contract; the application does not manufacture a new confidence interpretation after the service responds.
When detections return, the handler extracts proposed SKU labels and fetches their catalog details in a batch. The catalog lookup deduplicates requested identifiers, matches SKU or product identity and prefers records carrying a price-history relationship when grouping candidate records by SKU. It then attaches structured product details to each result. A missing catalog match remains a missing enrichment, rather than silently becoming proof that the visual detection failed.
The response cleanup recursively turns non-finite floating-point values into nulls so the output can be represented as JSON. That is a small but useful boundary between numerical inference and application data: an undefined numeric value should not break serialization or appear as a misleading price. The planogram option wraps the result with the image; it does not establish an automated compliance score.
An accepted crop is a reference, not a retraining claim
There are two related correction paths. Verification changes the status of an existing reference example through an explicit set of states: unverified, correct, incorrect or unclear. Adding a product example sends image bytes, a selected SKU and status to the reference-index integration, with the image-processor source recorded in that request.
Those operations give accepted visual evidence a place in the recognition workflow. They should not be described as training a new detector after every click. Changing a crop, changing the assigned SKU, accepting an example and updating a model are different activities. The application supports the first three through its review and reference-management integration; the repository does not establish an automatic model-retraining loop or a measured improvement from each correction.
This separation also makes an uncertain example useful. An operator can retain an unclear status rather than forcing a binary answer. Reviewing localization and identity independently helps prevent a well-cropped wrong product from being accepted simply because its boundary looks convincing.
Define what makes two price observations the same
The history builder creates a normalized observation from each priced source record. It converts source dates to a calendar-date string and carries the source collection, record identity, city, store and currency into the observation. Records without a usable price are skipped. Internal file-path metadata is removed before the history document is assembled.
Deduplication uses city, store, price, source and date. Sorting then uses date first, followed by source, record identity, city, store and price as deterministic tie-breakers. The difference matters: record identity participates in ordering but not in the deduplication key. Two repeated source records can therefore collapse into one observation even when their underlying database identifiers differ.
Observation context:
date · source · city · store · price · currency
Duplicate comparison fields:
city · store · price · source · date
Chronological order:
date → source → record identity → city → store → price
This is a conceptual field summary of the implemented indexing rules, not a sample of private records. Currency remains available as context, but it is not included in that duplicate comparison. The rule should not be promoted as universal financial reconciliation or currency conversion. Its value is that the application's behavior is explicit and repeatable, including the cases an analyst needs to interpret carefully.
The indexer also builds a state hash from product metadata and a stable representation of price history. That provides a content comparison for synchronization work rather than relying only on a product's display name. The resulting chart is a projection of linked source observations, not an independently measured market price. Preserving those distinctions lets the application connect recognition and history without implying that the image processor created every point on the timeline.
Build the correction path as carefully as the prediction path
The application demonstrates a complete retail vision workflow: shelf input, localization, identity proposals, review, catalog maintenance, historical context, and export. The distinctive capability is the path between those stages. An operator can inspect why a result looks wrong and correct the relevant piece without leaving the product.
We do not need an invented accuracy percentage or sales-uplift claim to explain that engineering. The workflow itself shows the scope. Visit the Retail Analytics case study for a visual walkthrough, read our retail detection article for the model-level background, or contact AlgoFly about a custom recognition and review application.