An airline loses your bag. You file a report. Someone at a counter three cities away eventually finds a black suitcase with no working identification on it.
That gap — between "bag located" and "bag returned" — is not a logistics problem. It is an identifier problem, and it is the same one you hit in any distributed system where two parties hold partial state and neither can resolve the other.
I have spent the last year building profile infrastructure for exactly this kind of lookup, so this post is about what actually breaks in the handoff.
The failure is at the identifier layer
A luggage tag stores a value. Usually a name, sometimes a number, occasionally an address.
That value has three properties that make it useless as an identifier:
It is not unique. "R. Sharma, Mumbai" resolves to a large set. So does most of what people write on tags.
It is not resolvable. A finder holding a name has no lookup mechanism. There is no directory they can query. The value is inert.
It is not addressable at write time. You wrote it in January. Your number changed in March. Every tag you own now holds a stale value and there is no invalidation path.
Compare with what a working identifier needs: uniqueness, a resolution mechanism, and a mutable target. A stamped tag has none of these.
What airlines actually use, and why it doesn't help you
Airlines assign a bag tag number at check-in. That is a proper identifier — unique, resolvable against their system, tied to a PNR.
But it has a scope problem. The identifier is only resolvable inside the airline's system, and only for the duration of the journey. A stranger who finds your bag on a train platform cannot resolve it. Neither can a hotel. Neither can you, once the journey is closed.
You get a working identifier for exactly the window where you least need one, and nothing for the window where you do.
The pointer pattern
The fix is the one you already use everywhere else: stop storing the value, store a pointer to it.
A travel profile is the target. The tag carries a URL encoded as a QR code. The tag itself holds no personal data — it holds an address.
This changes the properties in the ways that matter:
- Unique — the URL resolves to exactly one record
- Resolvable — any phone with a camera is a client, no app required
- Mutable — you edit the record, every tag you have ever printed is now current
The last one is the interesting property. It means the physical object does not need to be reissued when the data changes. You are decoupling the identifier from the payload, which is the same reason you do not store denormalised user data in six tables.
The access-control problem
Now the harder part, and the one most implementations get wrong.
The finder needs enough information to act. You need to not publish your home address to whoever picks up your bag.
Those are in tension, and the naive solution — encode a phone number directly in the QR — solves neither. It is a stamped tag with extra steps, and it leaks your number to anyone who scans it, including anyone who photographs it in transit.
What works is a resolution layer between them:
- Finder scans, gets a page — not a data dump
- Page exposes a contact action, not contact details
- Call or message routes through the system
- Your actual number is never rendered client-side
The finder can reach you. The finder cannot save, sell, or reuse your identity. The permission is scoped to the interaction.
This is just capability-based access control applied to a physical object, and it is why "put a QR code on it" is not the whole solution.
What it is not
Worth being direct about this, because the category gets muddled in marketing copy.
This is not tracking. There is no GPS, no beacon, no location. A scannable tag is passive — it does nothing until a human interacts with it. If you want to know where your bag is right now, you want a Bluetooth tracker, and it is a different product with different tradeoffs (battery, range, network density).
This is not recovery. It does not increase the probability that your bag is found. It increases the probability that a found bag gets back to you, which is a different conditional.
Being clear about which problem you are solving matters. A smart luggage tag optimises the return path, not the search path.
The engineering constraints nobody mentions
If you are building or evaluating something in this space:
No app on the finder side. This is non-negotiable. Your resolution client is a stranger in an airport with 4% battery. Any install step and the resolution fails. Camera-to-URL is the only viable path.
Graceful degradation. Print a short human-readable fallback URL under the code. Codes get scratched. Wet cardboard does not scan.
The physical layer is a real constraint. The tag goes through a baggage system designed to move heavy objects quickly. Adhesive fails, laminate peels, thermal print fades. Most failures I have seen are material failures, not software ones.
Don't over-render. The finder's page should load fast on bad airport wifi and show one action prominently. Every additional element is a chance for them to close the tab.
The general shape
The pattern generalises past luggage. Anywhere you have a physical object that needs to be reunited with an owner — a bag, a bike, a laptop, a set of keys, a pet — the structure is identical:
Object holds pointer. Pointer resolves to owner-controlled record. Record exposes an action, not data.
Once you see it that way, "smart tag" stops being a product category and starts being a fairly boring application of indirection.
More on the implementation at ProfileTap.
Top comments (0)