Why downloads and outbound links need their own measuring points
On many B2B websites the actual content is not on the page but next to it: in the data sheet, in the price list as an Excel file, in the catalog, in the installation guide. The page itself carries a summary and a link. The same goes for links to dealers, marketplaces and partner portals. The page fulfills its purpose at the very moment the visitor leaves it.
A tracking script only runs in HTML pages. Once the PDF opens in the browser's viewer or lands in the downloads folder, no script runs there any more, let alone on the dealer's site. Without a dedicated measuring point, the statistics only keep the last page view, with a short time on page and marked as an exit page. Lowering the bounce rate may then optimize away the very page that works best. Why the bounce rate on its own says little about attention is covered in Measure attention: scroll depth instead of bounce rate.
Files are also read without your page being involved. Google can index the content of most text-based files and certain encoded document formats, and lists PDF, Excel, PowerPoint and Word among them (Google Search Central). Anyone who opens a data sheet straight from the search results fetches the file without seeing your page. Click-based download figures therefore describe how visitors to your pages find their way to files, not how often a file is requested in total.
A measuring point at the click answers questions that page views leave open:
- Which data sheets, price lists and catalogs are actually downloaded, and from which page?
- Which dealers, marketplaces and partners receive visitors from your website, and which receive none?
- Do product pages lead to a download more often, or to contact by email and phone?
- Which linked files does nobody click, and which links point to a host nobody had in mind?
What counts as a download and what counts as an outbound link
The classification is part of cookieless web analytics by XICTRAQ® and runs without extra code. The tracker listens for clicks across the whole document. For every click it walks up from the clicked element to the nearest link and reads its destination. A simple comparison then decides: if the destination is on a different host than the current page, an outbound event is created with the full destination address. If it is on the same host and the path ends in a known file extension, a file_download event is created with the file path. Everything else is an ordinary click within the website.
You do not need to tag your links for this. Links inside SVG graphics are recorded too, such as a linked product drawing or a clickable map of dealer locations. Their destination is not available as plain text in the browser, so the tracker reads it separately.
These file extensions count as downloads, regardless of upper or lower case and even when the address is followed by a query such as ?v=:
pdf, doc and docx, xls and xlsx, ppt and pptx, csv and txt
zip, rar, 7z, tar and gz, such as bundles with drawings or drivers
mp3, mp4, wav and ogg, as long as they are linked as files
exe, dmg, apk and ipa, such as installers
The list does not include images, files for computer-aided design (CAD) such as .step or .dwg, e-books, calendar files or electronic business cards, among others. A click on such a file on your own domain counts neither as a download nor as an outbound link. The overview shows the most important cases:
| Link destination | Classification | What is stored |
|---|---|---|
| /downloads/data-sheet.pdf on your own domain | File download | Path of the file, without the query |
| File on company.example, page on www.company.example | File download, because www. and the bare host count as the same host | Path of the file |
| File on cdn.company.example or a storage service | Outbound link, not a download | Full destination address |
| Shop or portal on shop.company.example | Outbound link | Full destination address |
| Dealer, marketplace, partner portal | Outbound link | Full destination address |
| mailto: and tel: | Outbound link, analyzed as a contact conversion | Address or phone number of the link |
| /download.php?id=… without a file extension | No event | Nothing, an ordinary click |
| javascript:, data:, blob:, about: | No event | Nothing |
The host comparison: www, subdomain and CDN
Whether a destination belongs to your website is decided by the host alone, the part of the address between scheme and path. Relative links such as /downloads/price-list.xlsx are resolved by the browser against the current address before the comparison, so they end up on your own host. A leading www. is removed on both sides: a link from www.company.example to company.example stays on the website, and a file under the address without www. counts as a download.
This does not apply to any other subdomain. shop.company.example and cdn.company.example are foreign hosts for the comparison. For shops and portals on their own subdomain that is usually intended. For files it can be surprising: if the data sheet sits on a CDN, a network of delivery servers, or with a storage service, the click counts as an outbound link. It then appears in the Outbound links card, not under File downloads.
First, take stock: which host do your data sheets, catalogs and price lists live on? If they sit on a CDN, you will find the clicks among the outbound links, recognizable by the host. If you want all documents in one list, link them via a path on the main domain that the web server redirects to the storage location. The click then counts as a download.
A link to a file that no longer exists is still counted as a click. Whether linked files and dealer pages still respond is shown by a link check, not by click analytics. How to find dead links continuously is described in Monitor broken links and 404 errors automatically.
Why the event survives the page change
A click on a link is the worst moment to send data: the browser starts navigating immediately, and an ordinary asynchronous request from the old page may be aborted. Earlier tracking methods therefore delayed the page change artificially, for example with blocking requests, and made the next page slower (MDN).
navigator.sendBeacon() exists for exactly this case. The method sends a small amount of data to a server as an HTTP POST and is explicitly intended for analytics data (MDN). The browser queues the data and transmits it without holding up the unloading of the page or the next navigation. The queued data is limited to 64 KiB (MDN), and the method has been available across browsers since April 2018 (MDN).
The second option is fetch() with the keepalive option. The browser then does not abort the request if the page that started it is unloaded before the request completes (MDN). There is an upper limit here as well: if the payload of all pending keepalive requests of a page plus the new request exceeds 64 kibibytes, the new request ends in a network error (WHATWG Fetch Standard).
The XICTRAQ® tracker uses both routes in turn: sendBeacon first, and fetch with keepalive if the browser does not accept the beacon. The data goes to the server as plain text, so the browser needs no preflight request, and neither the download nor the move to the dealer is delayed. How the same principle applies at the end of a session is covered in unload is going away: capture analytics data completely.
In simplified form, the principle looks like this. The snippet is a teaching example with a shortened extension list, not the tracker's source code. The listener is attached to the document in the capture phase, so it sees the click even when a script on the page stops the event from propagating:
// The principle, simplified: not the tracker's source code
const FILE_PATTERN = /\.(pdf|docx?|xlsx?|zip)$/i;
const bareHost = (host) => host.replace(/^www\./, '');
document.addEventListener('click', (event) => {
const link = event.target.closest('a[href]');
if (!link) return;
const target = new URL(link.href, location.href);
// Script, data and in-memory addresses lead nowhere
if (/^(javascript|data|blob|about):$/.test(target.protocol)) return;
let payload = null;
if (bareHost(target.host) !== bareHost(location.host)) {
payload = { name: 'outbound', url: target.href };
} else if (FILE_PATTERN.test(target.pathname)) {
payload = { name: 'file_download', file: target.pathname };
}
// sendBeacon queues the data, the navigation does not wait
if (payload) navigator.sendBeacon('/collect', JSON.stringify(payload));
}, true);Clicks that trigger no measurement
Click-based figures do not capture every route to a file. Some routes to a file or an external destination trigger no ordinary click event on the page, and others cannot be recognized as a download from the link address:
- Middle click and new tab: mouse buttons other than the primary one have their own event,
auxclick(MDN). It has only been supported across current browsers since December 2024 (MDN). Whether a middle click also arrives as an ordinary click depends on the browser. - Context menu: anyone who chooses “Save link as” via right-click downloads the file without clicking the link.
- Direct request: a data sheet opened from the search results, an email or a bookmark opens without your page.
- Download via a script without a file extension: addresses such as
/download.php?id=…deliver the file, but their path does not end in a known extension. Whether the browser displays or saves the response is controlled by the server through the Content-Disposition header, which can also supply the filename for saving locally (RFC 6266). The tracker only sees the address of the link. - Files created in the browser: an export from a configurator often has an address starting with
blob:. It points to an object in the browser's memory (MDN) and leads nowhere, so the tracker does not count it. - The download attribute on its own: it indicates that a link is intended for downloading a resource (WHATWG HTML Standard). It only takes effect for same-origin addresses and for
blob:anddata:addresses (MDN), and it does not change the classification by host and file extension.
A tap on the link and the Enter key on a focused link, on the other hand, trigger an ordinary click event (MDN). Visitors using a keyboard or a touchscreen are therefore counted. And every click counts separately: anyone who opens the same data sheet several times creates several downloads in one session. The File downloads card therefore shows either the number of downloads or the number of visitors who downloaded a file.
Downloads without a link and files outside the list
For cases the automatic capture does not cover, the tracker offers two routes. They belong only where no link is captured automatically. The handbook page on the JS tracker API shows xictraq.event('download', …) as an example of a custom event. This call is meant for downloads that happen without an ordinary link. If it is also attached to a link to a PDF on your own domain, every request is recorded twice over: as a file download and as a custom event.
The first route is a call in your own code, for example when a configurator creates a file in the browser. The URL.createObjectURL() method returns a blob: address pointing to the created object (MDN):
// Create a file in the browser and offer it for saving
const blob = new Blob([csvText], { type: 'text/csv' });
const link = document.createElement('a');
link.href = URL.createObjectURL(blob);
link.download = 'configuration.csv';
link.click();
// The tracker does not count blob: addresses, so report it by hand
if (window.xictraq) {
xictraq.event('download', { file: 'configuration.csv' });
}The check for window.xictraq is needed because the tracker loads with defer and calls made before it has loaded are dropped. Such an event appears among the custom events, not in the File downloads card, which only lists automatically detected clicks.
The second route needs no script of your own. An element with the data-xictraq-event attribute reports a custom event under that name when clicked, and further attributes with the data-xictraq- prefix are sent along as properties. This suits files whose extension is not on the list, such as CAD data on your own domain:
<a href="/cad/ball-valve.step"
data-xictraq-event="cad_download"
data-xictraq-model="ball-valve">
CAD data (STEP)
</a>On a link to a PDF on your own domain, this attribute would make the same click appear additionally under the custom event name. That can be intentional if a single document is to count as a goal, but it then belongs in the description of your tracking setup.
Turning downloads and dealer clicks into goals
A download is not a conversion in itself, but it is often the most important intermediate step before an inquiry. In XICTRAQ® goals can be set up in two ways: as a page goal that applies to a specific path such as a thank-you page, or as an event goal that applies to a specific event name. An event goal named file_download counts every session in which at least one file was downloaded.
A goal counts sessions, not clicks. The conversion rate is the share of sessions that reached the goal among all sessions in the period. A visitor who downloads several files in one visit counts as one session. How many documents were taken away is still shown by the File downloads card.
For one specific document, file_download as a goal is not enough, because the event goal only compares the event name, not the file. The attribute from the previous section helps here: the data sheet of the most important product line gets its own event, for example datasheet_premium, and that event is set up as a goal. The same applies to outbound links. outbound as a goal is triggered by any move away from the site, while a custom event name on the link to the dealer portal is triggered only by exactly that one transition.
Clicks on mailto: and tel: links are additionally classified by XICTRAQ® as contact conversions at query time, split into phone, email, WhatsApp and SMS. Ordinary outbound clicks do not count as a lead there. How orders and revenue make it into the same analysis without third-party scripts is shown in Set up conversion tracking without third-party scripts.
An event goal on file_download shows how many sessions find their way to a file at all. A custom event on the most important document shows whether exactly that document is in demand. Together they separate general interest in documents from interest in a specific product.
Analyzing: which file, which dealer, which page
The analytics overview provides two cards for this, File downloads and Outbound links. Both can be set to a time range and a number of rows; the downloads card sorts by downloads, by visitors or by file name. The cards are available from the Starter plan, and the plans are listed on the pricing page. Each event is also stored with the path of the page on which the click happened.
Which pages a visitor saw before the download is a question of paths, not of individual clicks. How to analyze transitions between pages is described in User paths: where visitors drop off between pages. For the cards themselves, a reading aid helps:
| Observation | Possible cause | Next step |
|---|---|---|
| Many downloads, few visitors | repeated requests by the same people, such as dealers or your own staff | sort by visitors instead of downloads |
| Data sheet linked but not downloaded | link hard to find, wrong file, or file on a foreign host | check the host, place the link more visibly |
| High exit rate on the product page | visitors go to the data sheet or the dealer | compare exits with downloads and outbound clicks |
| Many clicks to a marketplace | visitors prefer to buy there rather than from the dealer or your own shop | review the link and the offer on the page |
| Contact clicks rise, inquiries do not | a click shows intent, not completion | cross-check incoming calls and emails |
Outbound links carry the full destination address including the query. If you link to dealers with campaign parameters, you will see a separate row for each parameter combination; how to keep parameters consistent is described in UTM parameters: tagging campaigns for clean attribution. Downloads do not split this way: a new version of the same data sheet with ?v= appended lands in the same row as the old one.
Privacy: measuring without storing anything in the browser
For click tracking, the tracker needs neither a cookie nor an identifier in the browser. Reach measurement in XICTRAQ® sets no cookies and stores nothing in the browser's storage; sessions are distinguished by a pseudonymous daily identifier. This is exactly where Section 25 of the German TDDDG comes in: storing information in the user's terminal equipment and accessing information already stored there are in principle only permitted with consent (TDDDG).
Whether a measurement setup as a whole can do without consent is not decided by the absence of a cookie alone, but by its design in the individual case. What the difference between anonymous and pseudonymous data means here is explained in Anonymous or pseudonymous? Web analytics under the EDPB guidelines. The basics are covered in Cookieless tracking: how analytics works without consent banners.
For downloads and outbound links there is one more practical rule: whatever is in the link address ends up in the statistics. For files that is only the path, for outbound links the entire address. A link to a dealer portal with a customer number, a name or a session identifier in the query writes these values into your reports. Such details do not belong in links that visitors click. A search of the source code for parameters such as id=, user= or email= in external links finds them before you start.
Rolling it out step by step
- Embed the snippet: the standard snippet is enough; it records downloads and outbound links without extra code.
- Take stock of your links: which files are linked, with which extension, on which host? Note files on a CDN or a subdomain separately.
- Close the gaps: for extensions outside the list and for files without a link, plan a custom event, but not in addition on a link that already counts automatically.
- Set up goals:
file_downloadas a general intermediate goal, custom events for individual documents or dealer portals, plus a page goal for the thank-you page of the inquiry form. - Run a cross-check: click a download and a dealer link yourself in an ordinary browser and find them again in the reports. The tracker deliberately does not report automated test browsers, so a test with such a tool stays empty.
- Write down the rules: note which figure counts what, so that downloads, custom events and contact conversions are not added together.
If you want to look at the reports first, the live demo shows the analytics overview with sample data. Custom events and the attribute are documented in detail in the handbook page on the JS tracker API.
Using documents and referrals as a sales signal
On many websites, downloads and outbound links are the points where a visit turns into a business process: a data sheet ends up in a tender, a price list in a cost calculation, a dealer link in an order. Measuring these clicks shows which documents are needed, which pages lead to them and which partners receive visitors. With cookieless analytics by XICTRAQ® this happens without a cookie and without storage in the browser, hosted in the EU. The pricing page shows which plan fits, and the live demo shows what the cards look like in the dashboard.
This article is based on: MDN Web Docs, pages “Navigator: sendBeacon() method”, “RequestInit”, “Element: click event”, “Element: auxclick event”, “HTML anchor element” and “URL: createObjectURL() static method”; WHATWG, Fetch Standard, section HTTP-network-or-cache fetch; WHATWG, HTML Standard, section Links; RFC 6266 on the Content-Disposition header; Google Search Central, “File types indexable by Google”; German Telecommunications Digital Services Data Protection Act (TDDDG), Section 25. The statements about the XICTRAQ® tracker describe its version at the date of publication. This article does not constitute legal advice.