What the script counts on its own

Once the script is on the page it records two things beyond page views, with no attributes to add and no code to write:

Both appear in your dashboard alongside your own goals.

Outbound clicks

Any <a> pointing at a different host than the page it is on.

The domain is what gets grouped, so the report reads "312 clicks to github.com" rather than listing every URL separately. The full link is kept alongside it, so you can still see which link inside that domain was clicked.

Internal links are not counted — a link to /pricing is a page view, and counting it twice would inflate both numbers. mailto:, tel: and javascript: links are skipped too.

File downloads

A link is treated as a download when its path ends in one of these:

pdf · csv · xlsx · xls · docx · doc · pptx · ppt · zip · rar · 7z · gz · dmg · exe · pkg · mp3 · mp4

The file is what gets grouped, so the report names what was taken — /files/price-list.pdf, /downloads/starter-kit.zip — rather than counting PDFs against ZIPs. Knowing three hundred PDFs were downloaded does not tell you which ones.

Two details worth knowing:

• Downloads on your own domain count. A link to /files/price-list.pdf is a download, not a page view — the check runs before the internal-link filter.

• The extension comes from the path, not the whole URL. A link like /pack.zip?v=2 is still a download, and a URL like /blog/v1.2/post is not.

What is not counted

The script records a click on a link, so a download that never involved one is invisible to it:

• Typing the file's address into the browser

• Following a link from an email, a chat message or a PDF

• Pasting a copied link

• curl, wget, or anything else fetching the file directly

Nothing is wrong when that happens — the script simply was not on the page, because there was no page. Every analytics tool that runs in the browser shares this limit: the file request never opens a page for a script to run on.

What this counts is downloads that start on your site. If you want a download to appear here, link to it from a page rather than sharing the file address itself. A link on a page also tells you something the bare file address cannot: which page sent the visitor, and where they came from before that.

A page with hundreds of files is fine. The script attaches one listener to the page, not one per link, so a library of five hundred PDFs costs no more than a single one. Only the files someone actually clicks are recorded — which also shows you which of those five hundred nobody has ever opened.

A missing file is still counted

The click is what gets recorded, not the response. If the file has moved and the link now returns 404, the download still appears in your dashboard.

That is deliberate, and useful: a row with plenty of clicks and a file that no longer exists is exactly how you find a broken download link.

If your file type is not listed

Tag the link yourself:

<a href="/whitepaper.epub" data-ts-goal="whitepaper_download">Download</a>

The list is deliberately short. Every extension in it costs bytes in a script that runs on every page of your site, and the ones left out — .key, .midi, .wma — are rare enough that carrying them for everyone is a bad trade. Tagging covers the exception.

They count towards your plan

Both event types count as events on your plan, the same as a page view or a goal. A site with many outbound links will use its allowance faster than the page-view count alone suggests.

If that matters more to you than the data, every one of these can be avoided by not linking out — but there is no switch to record them and not be billed for them, because the cost of storing them is the same either way.

Where they show up

Outbound clicks and downloads appear in Goals, beside the goals you defined yourself. Filtering the dashboard by one narrows everything else to the visitors who did it — so you can ask which channel sends the people who actually download your pricing.

See also: Custom events for goals you define, and What counts as an event for how your allowance is used.