QR codes that bring offline customers online, and tell you which ones came

A card goes into every parcel with a QR code on it. The code points at the homepage. Six months later the analytics show a lump of direct traffic and nobody can say whether the cards did anything. We have seen the same story with codes printed on GST invoices, on in-store standees, on shelf strips and on product labels. The code was the cheap part. Deciding what sat behind it was skipped.

India is an easy market for this. Anyone who has paid at a chai stall with UPI knows how to point a camera at a square, so the scan itself is not the friction. Everything after the scan is.

Send the scan to a page built for the place the code lives

Never the homepage. The person scanning is standing somewhere specific, holding something specific, and the page should answer the question that place raises. One code, one job.

• Parcel insert: a reorder page for the product they just received, a care guide, or a review request for that order. The customer has the product in hand, so the page can assume that.
• Receipt or invoice: a warranty registration, a WhatsApp opt-in, or the loyalty sign-up. The purchase is done; the job now is the second purchase.
• Store signage and counter cards: the online catalog of what this branch stocks, or a pincode-specific delivery offer for people who want it sent home instead of carried.
• Product label: the product's own page with the manual, the size chart, the ingredients list, or a video the packaging had no room for.

Each of these pages is opened on a phone, often on mobile data, often in a hurry. Keep it light, keep the action above the fold, and do not put a cookie wall or an app-install banner between the scan and the content.

Tag the destination so the scan is its own channel in the report

An untagged scan arrives as direct traffic, indistinguishable from someone typing the address. Tag the destination URL with UTM parameters before the code exists. Put qr in utm_medium so every offline code in the business groups into one row, use utm_source for the placement (packaging, receipt, store, label), and utm_campaign for the run or the branch. The conventions for spelling and case are covered in our UTM guide and apply here unchanged; the UTM Builder catches capital letters, stray spaces and duplicate parameters before you print anything.

One placement, one set of tags. Two codes on the same insert, one for reorder and one for reviews, get different utm_content values so the report can tell them apart.

Encode a short URL you control, never the destination itself

Ink cannot be edited. A print run of inserts lasts months, a shop standee lasts years, and a label on a product with a long shelf life outlives every campaign you planned when you designed it. If the code encodes the destination directly, every product page that moves, every campaign that ends and every domain change leaves dead codes in circulation with no way to recall them.

Encode a short path on your own domain instead, and have that path redirect to the tagged destination. The printed code stays valid forever; only the redirect table changes. The redirect carries the UTM parameters, so the printed URL stays short and clean and the tagging lives in a file you can edit.

# printed on the insert:  https://example.in/r/insert-reorder
# redirect rule (Apache .htaccess):
Redirect 302 /r/insert-reorder https://example.in/pages/reorder?utm_source=packaging&utm_medium=qr&utm_campaign=insert-2026-q3

# printed on the counter card:  https://example.in/r/store-andheri
Redirect 302 /r/store-andheri https://example.in/collections/in-store?utm_source=store&utm_medium=qr&utm_campaign=andheri

A short URL also makes a better code. Fewer characters means fewer modules, and fewer modules means each square is larger at the same printed size, which is what makes a code scan at distance. A URL with forty characters of UTM tags baked in produces a dense code that struggles on a small label. Use a 302 while the destination might still change, and use your own domain, because a third-party shortener adds its domain, its interstitial page and its lifetime to something you printed.

Size and contrast decide whether it scans from where the customer stands

The rule we size by: the code's width should be at least one tenth of the distance it will be scanned from. A code on a counter card, scanned from a hand's length, can be small. A poster read from a metre away needs a side of around ten centimetres. A banner across a shop front needs to be much larger than looks reasonable on the design file.

Leave the quiet zone alone. The QR standard asks for a clear margin of four modules on every side, and border art, rounded frames and text that crowd into it cause misreads. Keep dark modules on a light background. An inverted code, or brand colours with little contrast between them, reads on a flagship phone and fails on the budget one your customer owns. A logo in the centre is fine when the code is generated at error correction level H, which can recover up to thirty percent of damaged modules, but the logo has to stay inside the area that allowance covers and it makes the code denser, so it should be reserved for larger prints.

Export at the size you will print. The QR Code Generator sets foreground and background colours, drops a centred logo in, and exports a PNG up to 2048 pixels on a side, which is enough for a standee. Send the printer the large file, not a screenshot from the design tool.

Test on the cheapest phone you can find, in the light the code will live in

1. Scan the printed proof, not the screen. Screens glow; paper, lamination and curved bottles do not behave the same way.
2. Use a budget Android with the stock camera app, and a phone a few years old. The designer's phone proves nothing.
3. Try it under the shop's tube light and in daylight through a window. Glossy lamination throws glare that hides a whole quadrant.
4. Scan from the real distance. A counter card from across the counter, a poster from where a customer stands.
5. Follow the scan through. Confirm the redirect fires, the UTM parameters survive it, and the visit lands in analytics as the channel you intended.

Payment codes and link codes are different things

A UPI QR encodes a upi://pay intent and opens a payment app with the payee filled in. A URL code opens a browser. A single square cannot do both, and a customer who scans your reorder link with a UPI app expecting to pay gets an error. On a counter or a receipt, print both and label them. The UPI QR Code Generator turns a UPI ID into a standard intent code, and leaving the amount blank lets the payer type their own at the counter.

What should a QR code on product packaging link to?

A page built for someone holding that product: a reorder page, a care guide or a review request, never the homepage. Encode a short redirect URL on your own domain so the destination can change after printing, put UTM tags on the destination so scans appear as their own channel, and size the code for the scanning distance.