How we measure

How attribution works

tmgo.to uses single-touch, operator-confirmed attribution. We credit the tagged link, QR code or campaign that delivered the visit in which a lead was captured. Outcomes and values are the ones you record. We do not observe your sales, and we do not divide credit across multiple touches.

In practice: somebody opens a tagged link or scans a QR code, lands on your Link Page, and fills in your form. We record which placement delivered that visit. You tell us what happened to the lead and what it was worth. The report joins the two together.

A lead that arrives with no tag, no link, no QR code and no campaign is reported as unattributed, on its own line. We never quietly file it under “direct”, because we do not know that it was direct — we know that we do not know.

What “unique” means

A unique visitor is one distinct hashed address inside the period you are looking at — not per day, and not for all time. The same person visiting on Monday and on Friday is one unique visitor in a report covering that week, and one in each of two daily reports. Uniques from different periods therefore cannot be added together.

One figure works differently again: the Unique Visitors tile on a link's own page is always the last 90 days and does not follow the period you selected on that page. An unbounded count of distinct addresses has no ceiling, so that one is fixed rather than free.

A QR code's unique-scan counter works differently, and it is the one exception: it is a lifetime set of the hashed addresses that have scanned that code, so somebody who scans it every day bumps it exactly once, ever.

We do not identify people, so “unique” means “an address we could not tell apart from itself”, not “a human being”. Ten people behind one office connection can look like one visitor. One person on a phone and a laptop is two. We will not close that gap, because closing it means tracking individuals across devices, which we do not do.

What counts as a bot

Every request is classified from its user agent and its HTTP method into one of six kinds: a person, a link preview, a bot, a scripted fetch, a bare probe, or unknown. Your click and scan figures count people and unknowns. Everything else is excluded from those figures and from every breakdown built on them.

• Bots — search crawlers, corporate email and link security scanners that open every URL in an inbox, uptime monitors, SEO and archiving crawlers, headless browsers, and anything that names itself as automation.
• Scripted fetches — curl, wget, and HTTP client libraries.
• Link previews — the fetch a chat app makes to build a preview card when somebody pastes your link. Excluded from visits and reported separately as “Shared into chats”, because a preview means somebody shared your link. It is a signal worth having, and it is not a visit.
• Bare probes — a HEAD request that no other rule already identified, including one carrying no user agent at all. Excluded like a preview, but never counted as a share: an uptime monitor polling your link is not somebody sharing it.

Unknown is counted, deliberately. When we cannot tell what something is, we would rather show you a visit that might not have been a person than delete a person who was. An over-eager filter removes real customers silently, and you cannot audit a number that is not there.

This filter started on July 27, 2026. Click and scan counters are cumulative and were not corrected backwards — nothing recorded what a past bump was, so there was nothing to correct from. A total that includes traffic from before that date still contains the bots, previews and mail-security scans of that period, and figures either side of it are not comparable.

Your own traffic

Visits from your own workspace are excluded: checking your own short link, or scanning your own QR code at the print shop while signed in, no longer inflates your numbers. Two gaps we have not closed:

• Branded domains. A request to your own hostname is a different origin and never receives our session cookie, so we cannot tell that it is you. Your own visits on a branded domain still count.
• Link Pages. A public Link Page is served before any session is read, on purpose — a public page should not pay the cost of decrypting a signed-in session for every anonymous visitor. So a view or a tap on your own Link Page still counts.

Both are written here rather than fixed quietly, because a filter you believe in and that does not actually run is worse than no filter at all.

Cookieless, and IP addresses are never stored

A redirect, a QR scan and a Link Page view set no analytics cookie and run no tracking script. There is no consent banner because there is nothing following anybody.

To recognise a returning visitor at all we need something stable, so we take the address the request came from, mix it with a secret only our server holds, hash it, keep the first 64 bits, and throw the address away. Your visitor’s raw address is never written to a database, never written to a log, and never leaves the process that handled the request.

One thing is deliberately not covered by that sentence, so we will say it here rather than let you find it: when somebody signs in to a tmgo.to account and changes something — creates a link, edits billing, invites a colleague — we record that action with the address it came from, as a security record of who did what to the account. That is about account holders, never about the people who visit your links, and it is kept separately from anything this page calls analytics.

What is left is a token that is useful for counting and useless for anything else. It cannot be turned back into an address without the server's secret, and it cannot be matched against a token from any other service.

We salted the hash, and unique counts restart

Until this release the hash carried no salt. That was not good enough, and we would rather say so than leave it unsaid: there are only about four billion IPv4 addresses, so anybody holding the stored values could work back to the original address by trying all of them. An unsalted hash of a small set of possible inputs is an encoding, not an anonymisation.

The fix has a visible cost. A salted hash never matches the unsalted hash of the same address, so de-duplication starts over from the day this shipped: a visitor we had already counted is counted as new one more time. Expect unique-visitor figures and QR unique-scan counters to step up slightly around that date and then behave normally.

We did not re-hash the old values, and we could not have. The raw addresses were never kept — which is the whole point of the design.

The same step happens again if we ever rotate that secret, for example after a suspected leak or a scheduled credential change. It is rare, it is deliberate, and the effect is the same: de-duplication starts from that day, and a QR code’s lifetime unique-scan counter steps up once as previously-seen scanners are recorded as new. We would rather say that plainly than describe it as unrepeatable and be wrong later.

What we deliberately do not do

We see what happens on your tmgo.to links, QR codes and Link Pages. We do not see what happens anywhere else, and we do not try to. These are permanent limits on the product, not a backlog:

• No tracking pixels and no third-party tags on your links or your pages.
• No cross-site tracking. A visitor is never followed from your link to any other website.
• No cross-device identity. A phone and a laptop are two visitors, and we make no attempt to join them into one person.
• No data brokers, no reverse lookups, no identity enrichment. We never buy or query anything about the people who visit your links.
• No CRM connector watching your sales. Outcomes and values are the ones you type in, which is exactly why the model is called operator-confirmed.

Our own website is a separate thing from your pages, and it is not covered by the list above: tmgo.to’s marketing pages carry a Google advertising conversion tag and a Zoho support chat widget, because we advertise and we answer questions. Someone who opens your short link, scans your QR code or reads your Link Page never meets either of them — those pages load nothing from anyone but us, and a test in our build fails if that ever stops being true.

Location

Where location is shown it is country and region only — never a city, never coordinates, never a postal code — and it is resolved from a database on our own servers. Your visitors' addresses are never sent to a location service.

Location is switched off today. No location database is loaded, no location data is being recorded, and the analytics pages say “not enabled” rather than showing a table of zeroes — because “nobody came from anywhere” and “we never looked” are different facts, and only one of them is true.

How long we keep data

This section is about your analytics — the visit and scan events behind every number on this page. We enforce a retention window on the raw per-visit detail, and the window depends on your plan: Starter keeps 90 days, Pro 12 months, Business 24 months and Agency 36 months. A workspace with no live paid plan keeps 30 days. Workspaces that already existed when this policy took effect keep 12 months whatever their plan says, for the first year of it.

Totals are kept indefinitely. Before any raw event is deleted we summarise it into daily figures per client and per source, and those summaries are never pruned — so when your detail window closes you still see what happened, and the product says so on the page instead of showing you a zero. What expires is the per-visit layer underneath: referrers, locations and individual visitors for those older days. Deleting a link, a QR code, a client workspace or an entire account still deletes its events with it, immediately and whatever the window says.

Our own operational records are a different matter and are already swept automatically: error reports, the administrative audit trail, and the log of actions taken inside signed-in accounts are each deleted after a set period. Those are records of our system and of account holders’ own actions; none of them contains the people who visit your links.

Money and currencies

A value you record is stored as a whole number of minor units — cents, pence, centavos — together with the currency you chose. It is never held as a decimal fraction, so nothing drifts by a penny over a year of arithmetic.

Reports group by currency and never add two currencies together. There is no exchange rate anywhere in tmgo.to and no conversion happens at any point, so no total you see has been quietly turned into a different currency at a rate you did not pick.

If a number looks wrong

Tell us, and we will either fix the number or fix this page. Both have happened. hello@tmgo.to