Link Tracking

Page View Calls split tracking into two kinds and went deep on the first, the page view. This section takes the second, the link tracking call, fired in code as s.tl(). You already know why it carries the name it does, a leftover from the era when a page's interactions were mostly links inside anchor tags.

If the naming were being decided today, a more honest label would be something like activity call, or user action call. That is closer to what it captures. A link tracking call is, in practice, everything that is not a page load. A scroll, a click on any interface element, a mouse hover, a video played or paused, a document downloaded, a popup closed, a form opened, a form submitted, and dozens more. None of these is really a link in the old sense, and few are exits to a third party site. They are the actions that define digital performance now.

Why these calls carry the real weight

Think about the questions a business actually asks. How many times was this form submitted? How many times was this important document downloaded? How many times was this video played? That is the insight that pays for the tool. Traffic metrics, the page views and visits, are the primary goal and they matter, but conversion does not happen at that level. Conversion happens here, where a visitor purchases, submits a lead, downloads something, or engages with content. That is conversion in the true sense, and link tracking calls are how you capture it.

How a link call gets made, on the web

As with page views, there are two worlds, the website and the mobile app. On a website, the pattern was set out in the Rules section: for every action that matters, you build a rule. Take a document download. You define a direct call, hand its identifier and the data layer details to the developer, and they populate and trigger it at the right moment. Your rule does the rest, setting the Analytics variables and sending the server call, where the Send Beacon action fires s.tl(). That end of the work, the rule mechanics and how the extension manages your variables, lives in the Rules section. Here the subject is the call itself.

If you are implementing by hand instead, you populate your variables and then call the function. Unlike s.t(), the link call needs a few arguments to describe itself.

// s.tl(linkObject, linkType, linkName, variableOverrides, doneAction)
//   linkObject : "this" for a real navigating link (resolves its URL,
//                and holds a brief moment so the beacon fires before
//                the browser leaves). Use "true" for a non-navigating
//                interaction such as a popup or a custom action.
//   linkType   : "o" other/custom, "d" download, "e" exit
//   linkName   : your label, up to 100 characters, shown in the report
//   the last two arguments are optional

// A custom action that does not navigate away (a popup opened):
s.linkTrackVars = "eVar10,prop10,events";  // required in custom code
s.linkTrackEvents = "event5";              // so these get sent
s.events = "event5";
s.eVar10 = "newsletter-modal";
s.prop10 = "product-page";
s.tl(true, "o", "Newsletter Modal Opened");

// A real download link, passing the clicked element:
s.tl(this, "d", "User Guide PDF");

The linkName is worth care. It is what makes the call findable later in a debugger and meaningful in reports, which is why naming custom links well is treated as a discipline in the Rules section. One technical note that catches people implementing manually: when you set variables in custom code on a link call, you must also list them in s.linkTrackVars and any events in s.linkTrackEvents, or they will not be sent. Page view calls do not need this. When you set variables through the extension's interface instead, it manages both lists for you. The full reasoning is in the Rules section; the point to carry here is that a link call is selective about what it sends by default.

The call that races the page it is leaving

That "holds a brief moment" in the code above deserves more than a comment, because it marks the one place a link call can be perfectly built and still never arrive.

When a click both fires a tracking call and sends the browser somewhere else, two things start at once: the beacon is dispatched, and the new document begins loading. If the navigation wins, the page is torn down and the beacon goes with it. Passing this is what makes AppMeasurement hold the navigation back for a moment, around half a second, so the call gets away first. That is a trade rather than a fix. Every visitor who clicks a tracked outbound link waits through it, and on a slow connection the call can still lose.

The three link types, and why they exist

The second argument, the link type, takes one of three values, and the reason there are exactly three goes back to the tool's history. In the early days the product paid special attention to two behaviors: file downloads, and exit links that carried a visitor off the site. Each got its own type and its own report. Everything else was lumped into a third, generic type.

In modern practice the download and exit types are less central than they once were. Downloads are often captured as an ordinary custom link paired with a success event, which fits them into the same conversion reporting as everything else. And both downloads and exits can be tracked automatically without you writing an s.tl() at all. Turning on trackDownloadLinks lets AppMeasurement fire a download call whenever a clicked link ends in one of the file extensions you list in linkDownloadFileTypes, such as pdf,zip,doc. Turning on trackExternalLinks does the same for exits, firing a call the moment a visitor clicks a link that leaves your domain. The special types are not obsolete; they simply sit alongside the more common pattern of custom links carrying success events.

How a link call differs from a page call

The two calls are siblings, but they are not interchangeable, and it helps to see them side by side.

What usually rides on a link call

There is no rule in the code that forces it, but there is a strong, unwritten pattern: link calls are where your important success events fire. The behaviors above, a form submitted, a document downloaded, a video played, are conversions, and conversions have always been captured with success events and eVars. That is why, as a general practitioner, you will see success events and eVars showing up on s.tl() calls far more than on page views.

One honest caveat, the same one raised in the variables module: the arrival of Workspace blurred the old strict lines between props, eVars, default variables, and events. You can build reports across most of them now. So treat "link calls carry success events and eVars" as the common convention it is, not as a hard boundary. It describes how implementations are usually laid out, not a limit the tool imposes.

The same behavior in a mobile app

As with the page view, the mobile world does not have an s.tl() function, because it does not run JavaScript. Everything that is not a screen load, which is captured with trackState, is captured instead with trackAction. Every interaction a user takes, short of moving to a new screen, is a trackAction call: a button tap, a filter applied, a video started. The syntax differs by platform, but the outcome is the same, data sent to Adobe's servers describing an action. The mechanics of the mobile SDK, including how these map to variables through processing rules, are covered in the Mobile SDK section.

Both calls in this module, the page view and the link call, share one thing underneath: each is a server call sent to Adobe. And server calls are not just the unit of data collection, they are the unit you are billed on. That is the subject of Server Calls and Billing.