How do you keep track of which tag holds what?
With a record built while the tags are being applied rather than reconstructed afterwards. Without it you retain the ability to change any destination and lose the ability to know which physical object you are changing, which removes most of the value of a redirect deployment.
Why it matters more than it seems
A deployment where every tag redirects through your own domain is flexible only if you know which tag is which. Otherwise you can change where identifier forty seven points and have no idea which door, shelf or machine that is.
The flexibility was the reason for the redirect pattern in the first place. Losing the record does not break the tags, it removes the benefit you paid for.
What to record
Three fields are enough for most deployments, and a fourth helps more than expected.
The identifier written to the tag, or the factory identifier where mirroring is used. The physical location, described the way someone unfamiliar would find it rather than the way you think of it. The date of installation.
And a photograph. A picture of the tag in place answers questions a text description never will, particularly two years later when the person who installed it has left.
The timing is the whole trick
Record during application, one line per tag, as the tag goes on.
Every attempt to reconstruct the mapping afterwards fails or costs more than the deployment. Walking a building tapping every tag to discover what it holds is a full day for a hundred tags, and it produces a record you then have to keep anyway.
The practical method is a phone in one hand and a spreadsheet on the other, or a numbered label applied to the tag backing before installation so the number is visible at the moment of fixing.
Number the physical tag, not just the record
A small printed number on or beside the tag turns every future question into a lookup rather than a survey. It costs nothing at production time and saves the deployment later.
Reconstructing a lost record
Possible and unpleasant. Walk the estate, tap each tag, note what it returns and where it is.
Two things make it faster. If the tags redirect through your domain, the server logs show which identifiers are being tapped, which at least tells you which ones are alive. And if mirroring is used, the identifier is the factory one, so a reading tool shows it without needing the network.
What cannot be reconstructed is which tags were never installed. A batch where some tags went on walls and some stayed in a drawer will produce a record with gaps that nobody can explain, which is a good argument for recording at the moment of application rather than at the moment of writing.
Frequently asked questions
Is a spreadsheet enough?
For most deployments yes, provided it is kept somewhere the whole team can find it rather than on the installer's laptop. The format matters far less than the survival.
Can I use the factory identifier as the key?
Yes, and it is the most reliable choice since it cannot be changed or duplicated by accident. It requires reading each tag at installation, which you are doing anyway to verify it.
What if tags are moved after installation?
The record has to be updated, and nothing enforces that. This is the main reason records rot, so a short procedure for moves is worth writing down alongside the record itself.
Do server logs replace a record?
They show which identifiers are active and never say where they are. Logs complement a record and cannot substitute for one.