Three values, and only three
A Marker's address can carry a source parameter, written src. It takes exactly three values, and they line up with the three ways a visitor can reach you.
| Value | Reads as | Where it comes from |
|---|---|---|
nfc | NFC tap | A phone held against the Marker. |
qr | QR scan | A camera reading a printed or on-screen code. |
direct | Link | A link that travelled by copy, paste or share. |
Why a missing value means a tap
The NFC chip inside a Marker holds a bare address with no parameters at all, just /m/ and the Marker's code. The printed QR holds the same address with ?src=qr appended.
That asymmetry is deliberate and it is not going away. Tags were being written and Markers were going into walls before tap-versus-scan was ever measured, and those Markers cannot be rewritten. So on a Marker address, the absence of a source is itself the NFC signal.
What follows from that
- Markers printed before the source parameter existed count as taps, whichever way they were actually opened. The split was not measurable on those Markers before either, so nothing was lost, but a very old installation will read as tap-heavy.
- Typing a Marker address by hand counts as a tap. There is no way to distinguish it, and it is rare enough not to matter.
- Use Copy link to share a Marker. The Copy link action writes
directinto the address, so a link you paste into an email is filed correctly instead of inflating your tap count. - An on-screen QR is not a Marker scan. The share widget's QR encodes the Experience's own address, not the Marker's, so it shows up under Builder QR against the Experience, with no Marker attached.
What gets recorded
Alongside the resolved source, a Marker visit carries the Marker's code, so the visit is counted against both the Experience and the Marker. That is what makes it possible to ask which of six Markers pointing at the same Experience is actually earning its wall space. The code only counts when that Marker points at the Experience that opened. A Marker's code added by hand to a link for some other page is recorded as an ordinary visit, with no Marker attached.
A short-lived scan token is also minted at the moment of the redirect. It exists to tell a genuinely new tap apart from a phone restoring a tab it had open yesterday: a distinction no other client-side signal can make, because a restored tab looks identical to a fresh visit in every other respect.
Example
Reading Cedar Hollow's numbers
Cedar Hollow's trail Markers split 71% NFC tap, 24% QR scan and 5% Link. The Link share is not a mistake: the education team sends the trail Experience to visiting schools by email using the Copy link action, and those visits are correctly filed as links rather than as phantom taps at the otter rail. The QR share is highest at the two Markers mounted above the reach of younger visitors, which is a placement finding, not an attribution one.
Can I turn off attribution?
There is nothing to turn off. The source parameter records how the page was opened, not who opened it.
Why does one Marker show taps I cannot account for?
Check whether its address has been pasted anywhere public. A hand-typed or stripped address resolves to a tap, so a Marker whose link is on a printed flyer will report taps nobody made at the Marker.
Do dead ends get attributed too?
Yes. A tap on a Marker that is unlinked or unrecognised is still recorded with the source it actually arrived with, so a decommissioned Marker that people keep tapping is visible rather than invisible.
Does this match what Google Analytics shows?
The two are kept deliberately parallel: NearField's own source parameter is the first-party record, and campaign parameters are added alongside it, never in place of it. If they ever disagree, the source parameter is the one to trust for Marker attribution.