Per-SKU packaging: a code on the box that opens that product's setup
Companion apps for physical products. The code on the box should land on the setup, manual or refill screen for the thing in the box.
Updated Sep 3, 2026
Who runs this
- Mobile product teams
- Growth marketers
What it uses
- QR code generation
- Deferred deep linking
- Smart routing
- Per-link source and placement tagging
Someone unboxes a product with a companion app. The box says 'download the app to get started'. They do. The app opens on a screen that asks which product they have, from a list of everything you've ever made. The answer was printed on the box they're holding.
What problem does this solve?
The code on the packaging should land on the setup flow for that exact product — or its manual, or its refill order, depending on where on the packaging the code is. The app should know what's in the box before the person is asked. And by SKU, you learn which products actually drive app adoption, which is usually not the ones you'd guess.
How do you set the links up?
One link per SKU, per placement on the packaging if there is more than one. The QR is generated from the link. The payload carries the SKU and what the code is for; the source tag carries where on the packaging it sits, so a code on the quick-start card can be compared with one on the box itself.
{
"deepLinkPath": "/setup/kettle-k2",
"customData": {"sku": "K2-BLK", "step": "pair", "src": "quick-start-card", "batch": "2026-08"}
}Why per placement, not per product?
| Placement | Lands on | Tells you |
|---|---|---|
| Quick-start card | Setup and pairing | How many buyers set up the app at unboxing |
| Inside lid | Manual for this SKU | Whether people look for help, and when |
| Refill pack | Reorder for this SKU | Whether packaging can drive repeat purchase |
| Retail shelf tag | Product page, pre-purchase | Whether the app sells the product |
Same product, four codes, four different questions answered. Printing one code and pointing it at the home screen answers none of them.
What about the batch field?
Packaging is printed in runs. Putting the run in the payload costs nothing and means that when a batch has a printing defect, a wrong insert, or a product recall, you can see exactly which owners were affected and reach them in the app. It's one of the rare cases where a tracking field is also a safety feature.
Which metric should you watch?
Setup completion rate by SKU, from the code. Products where the code is scanned but setup isn't completed have an onboarding problem specific to that product, and you'll only see it if each product has its own link.
Related use cases
Offline to app
Offline to app: a QR code that lands on the thing next to it
Posters, table tents, event badges, receipts. The scan is easy; landing on the right screen after install is the part that fails.
Support links
Support deep links: 'go to Settings → Privacy → Export' loses half your readers
A support reply that opens the app on the exact screen instead of describing the route to it. Unglamorous, and it measurably cuts tickets.
Every one of these depends on the same two things: link context surviving an install, and an honest answer to which click produced it. The scoring model is published in full on our methodology page, and you can check any domain's association files with our free link validator.