1,610 receipt submissions in the campaign report

The situation

Visual note: the opening image is an illustrative reconstruction based on the documented workflow. Its sample receipt values and interface details are not campaign records.

Musgrave's Northern Ireland campaign covered its SuperValu and Centra brands. BrandFire led the campaign relationship and brought RaftLabs in to deliver the web platform. The recorded project period was about 2-3 months.

The shopper journey was bounded: register, submit a receipt image, receive a campaign decision, and enter the relevant prize draw when approved. Behind that flow, the product had to identify the store, apply campaign rules, stop an exact transaction from being entered twice, and preserve a status that operators could act on.

The post-campaign report records 1,062 users and 1,610 receipt submissions. At the reporting snapshot, 1,158 submissions were AI approved, 409 were AI rejected, 4 were manually approved, 10 were manually rejected, and 29 remained processing. Those statuses reconcile to all 1,610 submissions.

The same report lists 471, 316, 273, and 201 participants across the four competition periods. These are period-level participation counts. The report does not define cross-period uniqueness, so they should not be added together and presented as unique users.

One engineering result needs a tighter boundary. The project team internally reported store matching improving from roughly 80% to near 99% after simplifying the store identifiers sent to the model. The retained evidence does not include the sample, scoring method, or error breakdown. It is a store-matching measure, not OCR accuracy, final campaign-decision accuracy, or an audited result.

The product decisions a retail buyer should examine

• Define accuracy at the field and decision level

  Receipt scanning is not one binary task. A system can read text correctly but match the wrong store, or extract the right fields and still apply the wrong campaign rule. Buyers should separate image readability, field extraction, store matching, rule evaluation, and the final approve-or-reject decision.

  For Musgrave, the documented change addressed store matching. The team replaced 128-bit UUIDs with short sequential integers in the model input, then mapped the returned integer back to the application's internal identifier. The team reported the matching measure moving from roughly 80% to near 99%.

  The record does not state how many receipts were tested, which receipt conditions were represented, or how errors were scored. We therefore do not describe that figure as OCR accuracy or use it as a general performance benchmark. A new engagement should define a labelled evaluation set, field-level measures, false approvals, false rejections, abstentions, and manual-review rate before launch.

• Separate exact replay controls from broad fraud prevention

  The delivered replay check used a composite key built from store address, store ID, POS machine ID, brand, and transaction timestamp. When all five values matched an existing record, the later submission could be treated as the same recorded transaction even if the shopper uploaded another photograph.

  That is a specific duplicate control. It is not evidence that the platform detected every altered, synthetic, stolen, or coordinated submission. Those risks require separate signals, thresholds, review rules, evidence retention, and a shopper-support process.

• Treat store data as part of the AI system

  The post-campaign report documents practical data problems: some addresses were not captured, duplicate road names made matching ambiguous, and Centra address mapping needed attention. These are not cosmetic data-cleaning issues. If the store reference list is incomplete or ambiguous, a model can return a plausible value that still maps to the wrong campaign record.

  For another grocery campaign, we would make store-reference quality an acceptance criterion: normalize addresses, define stable internal IDs, test duplicate place names, preserve the original model response, and route uncertain matches to review. This is a recommendation based on the recorded issues, not a claim that every one of those controls shipped in the Musgrave release.

• Verify the production AI path before launch

  Project notes record that Google AI Studio API requests which had worked during development failed in production during the first campaign week. The retained evidence does not record the final remediation, the production endpoint configuration, or a completed migration to Vertex AI. This page therefore does not claim one.

  The buyer lesson is concrete: test production credentials, quotas, regional availability, timeouts, retry behavior, and a manual fallback before opening a receipt campaign. Development success is not production acceptance evidence.

1. The shopper flow connected a receipt to a competition

   Illustrative reconstruction: the controls, copy, and values shown in this image are examples, not campaign records.

   A shopper registered and submitted a grocery receipt image. The application used the extracted receipt details and campaign configuration to record a status for that submission. Approved receipts could proceed into the relevant competition workflow; rejected and unresolved receipts remained distinguishable in the operating record.

   For a new campaign, the definition of done should include minimum image quality, supported receipt formats, resubmission behavior, rejection messages, manual-review triggers, and the support path when a shopper disputes a result.

   

2. Short identifiers made store matching more constrained

   Illustrative reconstruction: the receipt, extracted values, and interface shown in this image are sample content.

   During development, long UUID store identifiers made the model's choice harder to constrain. The team replaced them with sequential integers in the model request and mapped the selected integer back to the internal UUID afterward.

   The team associated that change with an internally reported store-matching improvement from roughly 80% to near 99%. Because the retained record has no evaluation set or scoring method, the figure remains directional project evidence. It does not establish OCR accuracy or end-to-end approval accuracy.

   

3. The composite key guarded against exact transaction replay

   Illustrative reconstruction: the transaction values and dashboard states shown in this image are examples.

   The application compared store address, store ID, POS machine ID, brand, and transaction timestamp with existing records. A complete match identified an exact recorded transaction replay. Unlike pixel comparison, this approach could catch another photograph of the same transaction when those fields were extracted consistently.

   The limitation matters: extraction errors can weaken the key, and the rule does not cover every fraud pattern. We would treat replay, image alteration, account velocity, impossible purchase combinations, and operator review as separate acceptance-test groups for a new grocery loyalty program build.

   

4. One operating view covered four competition periods

   Illustrative reconstruction: store, entry, and winner values shown in this image are sample UI values and should not be read as campaign evidence.

   The recorded campaign ran four competition periods across SuperValu and Centra. The post-campaign report lists 471, 316, 273, and 201 participants respectively. It also records 76, 77, 78, and 77 winners for those periods.

   The report surfaced operational gaps as well as totals. It calls out address-capture problems, duplicate road names, Centra address mapping, shortlist confusion, and minor interface bugs. Those findings are useful to a buyer because they identify the next acceptance tests: reference-data quality, unambiguous review states, and operator workflows that explain why a receipt or participant is in each queue.