QR code analytics: what enterprise buyers should require

Forty-eight countries, covering 88% of world GDP, are piloting the migration to 2D barcodes at retail point of sale. As QR codes move from campaign accessory to product infrastructure, the data they generate matters to more teams than marketing: trading, compliance, IT and legal all end up reading it. Yet most buying processes still evaluate analytics by watching a polished demo for ten minutes. This article lists the analytics requirements an enterprise should put in writing before choosing a QR code platform: the filters, the retention, the exports and the governance that decide whether scan data becomes usable evidence.

Analytics app overview on the Unitag Dashboard

The third pillar, and the easiest to under-specify

An enterprise QR code platform does three jobs: it generates codes at scale, it governs who may change them, and it measures what happens after the scan. Buyers tend to specify the first two carefully, then accept the third on sight because the demo dashboard looked complete. The gap shows up a year later, when someone asks for a year-on-year comparison and discovers the data was aggregated, expired or trapped inside the interface.

Who reads the data has changed too. A scan report used to answer a campaign question for one marketing team. On a multi-brand deployment it now feeds trading reviews, proves that a compliance page was reachable in a given market, and gives IT the traffic patterns it needs for capacity planning. Requirements written by marketing alone will miss what those other readers need.

The volumes involved are rising on a schedule. Under GS1’s Sunrise 2027 programme, retailers will need to be able to accept QR codes carrying GS1 Digital Link at point of sale by the end of 2027, which means codes printed on packs by default and scan counts that dwarf anything a campaign produced. An enterprise agreement signed in 2026 should treat measurement with the same rigour as generation and governance. The six requirements below are written to be pasted into a requirements document and scored.

Requirement 1: filters by language, device and country

Filters do two jobs on a serious platform, and you should require both in the same clause.

The first job is routing. One printed code should serve every market correctly: by language, so a pack sold in Belgium opens in French or Dutch; by country, so a promotion that is only legal in one market never appears in another; by device, so the page renders properly on the phone in hand. This is what allows a single international print run instead of one artwork per market. Unitag applies these rules per QR code, at scan time.

The second job is reading. Every dimension the platform routes on must also be a dimension you can segment reports by. If the platform can send German scanners to a German page, it must also tell you how many German scanners there were, on which devices, over which weeks. Write the requirement as a pair: “the platform shall route scans by language, device and country, and shall report scan volumes segmented by the same dimensions.”

The pairing matters in practice. A beverage brand running one printed code across 12 markets needs the routing to keep the legal pages straight, and the reporting to show whether scan behaviour in Spain justified the Spanish landing page it paid for. Vendors often demo the first half and stay quiet about the second, which is exactly why the clause names both.

Requirement 2: retention and history

Ask two blunt questions: how long is scan data kept, and in what form? Some platforms aggregate raw scans into daily totals after a few months; others expire history with the subscription tier. Neither is acceptable if your reporting cycle is annual, because a year-on-year comparison needs at least two full years of comparable history.

Be precise about the difference between raw and aggregated history. Aggregated daily totals will answer “how did October perform”, but only scan-level detail can answer “did the promotion shift weekend behaviour in German cities”. You do not need raw data forever; you do need the contract to say when it becomes aggregate and what survives the conversion.

Require the retention period to be stated in the contract, together with the level of detail retained. Then extend the requirement to configuration history: the platform should record what each code pointed at and when the destination changed. When a customer complains about a promotion in week 32, or an auditor asks what a pack linked to last spring, the change log is the answer. A platform that cannot produce it leaves you reconstructing history from screenshots and old emails.

Requirement 3: exports and API access

Scan data earns its keep when it leaves the platform and meets your other data. The interesting questions are joins: scans against sales by region, scans against media spend by campaign, scans against stock movements by store. Those joins happen in your BI stack, so the platform must feed it.

Require three things in writing:

• Scheduled exports in a standard format, so reporting runs without a human downloading files every Monday.
• Documented API access to scan data, so your BI team can pull programmatically rather than scrape. Ask for the API documentation during the evaluation, before any contract is signed.
• No penalty for taking your own data out: export volume and API calls should not turn into a surprise on the invoice.

Ask for a sample export file during the evaluation as well. Column names, encodings and timestamp formats are dull until your BI team meets them, and a ten-minute review of a real file catches problems that no requirements clause anticipates.

API access is typically an enterprise-tier feature, so confirm which tier carries it on the enterprise offer you are actually buying, and have the answer written into the order form rather than remembered from the sales call.

Requirement 4: benchmarks and context

A scan count on its own says very little. Five thousand scans might be a triumph for a niche product in one market and a failure for a national launch. The requirement to write down is comparative reporting: the platform must let you compare campaigns against campaigns, countries against countries and brands against brands inside your own account, over time windows you choose.

Ask each vendor two further questions. First, what context can it provide beyond your own data, and on what basis? Treat any industry benchmark figure with care and ask how it was computed before you rely on it internally. Second, how does the platform handle the comparison you will actually run every January: this year against last year, per market? The answer loops back to retention, which is why the requirements travel together in one document.

Internal comparability also depends on consistent structure inside the account. If each team names its campaigns its own way, the comparison view degrades into guesswork, so pair this clause with naming conventions in the governance section of your wider evaluation. The year-end comparison is only as good as the discipline behind it.

Requirement 5: UTM governance

Scan traffic that arrives in your web analytics unlabelled gets filed as direct traffic, and the QR code programme loses credit for everything it drives. The fix is UTM tagging, and at enterprise scale the fix needs governance rather than goodwill.

Left to individual teams, UTM conventions drift within a quarter: one team writes “qr_code”, another “QRcode”, a third forgets the tags entirely, and the resulting reports cannot be reconciled. Require the platform to apply UTM parameters automatically at code level, following a convention an administrator defines once and every team inherits. Require too that the convention can be updated centrally, because your web analytics setup will change over the life of the contract.

This is a small clause with a long reach. It is the difference between a marketing director who can state what the packaging codes contributed this quarter and one who can only say the codes were scanned.

Testing it takes two minutes in a demo. Scan a code and follow the visit into your own web analytics property: the session should arrive with the right source, medium and campaign, without anyone having typed the tags by hand.

Requirement 6: privacy posture

Scan data is behavioural data collected from the public, so the privacy questions belong in the requirements document rather than in a later legal review. Require written answers on four points: where scan data is processed and stored, what is collected about the person scanning, which sub-processors are involved, and how the platform supports your GDPR obligations, including a data processing agreement.

Hosting location is the anchor. Unitag is hosted in the EU and operates under GDPR, with a French and English team based in London and Toulouse; whatever vendor you evaluate, ask for the equivalent facts in writing. For codes on consumer packaging the stakes are concrete, because the scanning public never signed up to anything. A platform that reports in aggregates and is transparent about what it collects protects the brand printed on the pack.

One further clause earns its place: require notification of changes to sub-processors or processing locations during the contract term. Scan data flows for as long as the packs are on shelves, and the posture you approved in year one should not drift quietly by year three.

Writing the requirements into the RFP

The six requirements above are one section of a larger evaluation. Identity, hosting, GS1 Digital Link scope, governance, exit terms and support each deserve the same written treatment, and we have published a companion RFP checklist that covers the full structure section by section. Analytics earns its own detailed clause because it is the pillar that demos flatter most and contracts describe least.

Two practical habits carry the day. Ask for written answers to every requirement, because written answers can be compared, scored and held onto. And test the claims on live data before signing: a workspace with your own codes, scanned by your own team across a fortnight, tells you more about the analytics than any slide.

What to do now

Turn the six requirements into a one-page annex and circulate it to the teams who will consume the data: BI, trading, legal and brand. Each will sharpen a clause you would have left vague. Put the annex to every vendor on your shortlist and refuse to score verbal answers. Then pick the two strongest responses and validate them in a live demo against real scan data. If a full evaluation is further out, run the annex against your incumbent platform first: the gaps you find will sharpen both the requirements and the business case for the wider review. An afternoon of diligence here decides whether, three years from now, your scan history is an asset your analysts query or a number in a slide nobody can trace.

Related articles

• How to evaluate QR code vendors: an RFP checklist
• Best QR code platform for retail: the 2026 buyer’s guide
• GS1 Digital Link on packaging: where to start