Short Link Click Events
What an Ours Privacy short link records on every scan or click: the event name, the campaign and device properties captured, how visitor identity is resolved, and how consent and bot filtering apply.
Use this page to understand exactly what a scan or click records, so you can find it in Analytics, filter on it, and map it to a destination.
A short link click is an ordinary first-party event. Nothing about it is special-cased downstream, which is the whole point: it behaves like every other event you collect.
The event name
There is no fixed event name. Each short link emits an event named after the link.
A link called Spring Postcard QR records events called Spring Postcard QR. A link left with its default name records events called Redirect, which is why renaming before you publish matters.
This is what you select when you:
- Filter or trend the event in Web Analytics.
- Add an event condition in Audiences.
- Create a destination mapping for link clicks.
What is captured
Every click carries the following, without any configuration on your part.
Campaign properties
The five campaign tags you set on the link, recorded as first-party campaign properties: campaign, source, medium, term, and content. Empty fields are simply absent.
Approximate location
Derived from the request, not from device GPS:
- Country and country name
- Region and region name
- City
- Postal code and metro code
- Approximate latitude and longitude
- Time zone
City-level and finer values are approximations from network location and should be read as such.
Device and client
- Device type, model, and vendor
- Browser name and version
- Operating system name and version
- Rendering engine name and version
- CPU architecture
- Whether the request came from a mobile, tablet, desktop, smart TV, iOS, or Android viewer
Bot signals
A bot flag, a bot score, and the signals that produced them. See Bots below for how they are used.
Source attribution
The link's identity travels with the event, so you can tell which specific link produced a click even when several links share a campaign or an event name.
What is not captured
- Referrer. The redirect path does not capture the referring page. If you need to distinguish placements, create a separate link per placement rather than relying on referrer.
- Scan versus click. A QR scan and a browser click are indistinguishable, because the code encodes the same URL as the copy button. See Reporting.
- Anything from the destination page. The click event ends at the redirect. What happens on the landing page is captured by the Web SDK on that page, as a separate event.
Visitor identity
When the person opening the link already has an Ours Privacy cookie for your account, the click is attached to that existing visitor. The scan then joins the rest of their timeline: earlier sessions, later conversions, and everything in between.
When they do not, the click creates a new visitor, and later activity on your site stitches to it in the normal way.
Practically, this means:
- A QR scan from a brand new person starts a visitor record at the moment of the scan, and the landing page visit continues it.
- A click from someone who has been on your site before, on the same device and browser, extends the record you already have.
- Print-to-web attribution works because the click and the subsequent site behavior are the same visitor rather than two unrelated records.
Serving links from a branded domain materially improves this, for the same reasons it improves the rest of your tracking.
If you need to attach a known identity to a redirect, for example on a per-recipient email link, the Redirect Tracking surface exposes identity parameters that the Short Links editor does not.
Consent
The click event is always recorded. Consent governs what happens next.
Downstream delivery to destinations is checked against the visitor's consent choices at dispatch time, exactly as it is for every other event. A click from a visitor who has declined the relevant category is captured in your own account and is not forwarded onward.
This matches how the rest of the platform behaves, so short links do not need their own consent configuration. See Cookie Consent for how categories are defined and enforced.
Bots
Automated traffic reaches short links the same way it reaches everything else. Link previewers in messaging apps, email security scanners, and crawlers all follow redirects.
Bot hits are recorded as events with their bot signals attached, and short link reporting excludes them by default. That means:
- The Total clicks and Unique clicks numbers on the Analytics tab reflect filtered traffic.
- The raw events remain in your account, so an ad-hoc query in Web Analytics that does not filter on the bot flag will show a higher number.
The gap between the two is usually a link previewer, not a discrepancy. Email clients in particular fetch every link in a message.
Using clicks downstream
Because a click is a normal event, everything the platform can do with an event applies:
- Analytics: trend the event, break it down by campaign or country, and put it in a funnel with what happens after the landing page.
- Audiences: build a group of everyone who scanned a given code, or who arrived through a campaign but never reached a confirmation page. See Event conditions.
- Attribution: a scan can serve as the first touch in a conversion journey. See Attribution.
- Destinations: map the click to a CRM, an ad platform, or your warehouse alongside its campaign properties. See Destinations.
- Data governance: the event passes through your allow list, governance rules, and mappings like any other, so it obeys the same controls. See Understanding events.
Because event names come from link names, add new links to your allowed events list if your account restricts which events are accepted. See Allow listing events.
Next Steps
- Short link reporting: the built-in per-link report.
- Campaigns and UTM tags: what the campaign properties contain.
- Recipes: worked configurations that use these events downstream.
How is this guide?

