Does s.tl() link tracking distort my Adobe Analytics bounce rate, and how do I sequence it safely?

Why this happens

Bounce rate in Adobe Analytics is derived from visits that recorded exactly one page view - a metric built on s.t() calls (page views), not s.tl() calls (link tracking). A correctly implemented exit, download, or custom link should never itself register as a second page view, so it should never turn a genuine one-page visit into a "non-bounce" or vice versa. When teams report link tracking moving their bounce rate, it's almost always one of these three things, not link tracking as a concept:

• The call actually used s.t() where s.tl() was intended - counting outbound clicks as additional page views, which mechanically lowers bounce rate by giving single-page visits a second "page."
• A processing rule or VISTA rule reclassifying the link hit's pageName/event structure in a way that makes it resemble a page view downstream.
• A coincidental correlation - link tracking was added alongside an unrelated site or campaign change that's the actual cause of the bounce-rate shift.

The genuinely tricky part of s.tl() is timing, not counting: it's typically bound to a click on an element that also causes navigation (an outbound link, a file download, a form that redirects). If the browser navigates away before the tracking beacon has actually left, the hit is silently lost - the opposite failure of a duplicate.

Fix it

1. Confirm which call is actually in use. Search the codebase and any Launch rules for both function names - it's easy for a copy-pasted snippet to carry the wrong one:

grep -rn "s\.t(" src/  # page view - should NOT run on a link click
grep -rn "s\.tl(" src/ # link tracking - correct for exit/download/custom links

2. Call s.tl() with the correct link type and a callback that only navigates once the beacon is sent, using AppMeasurement's own delay mechanism rather than a raw setTimeout guess:

document.querySelector('#outbound-link').addEventListener('click', function (e) {
  e.preventDefault();
  var href = this.href;
  s.tl(this, 'e', 'Outbound Link', {
    linkTrackVars: 'events,eVar10',
    linkTrackEvents: 'event5'
  });
  // AppMeasurement's own callback pattern - navigate after the beacon fires
  s.t(); // omit if this call should not also register a page view
  setTimeout(function () { window.location.href = href; }, 150);
});

The 150ms figure is a practical floor many implementations use to let a synchronous beacon complete before the page unloads - tune it against your own network conditions rather than treating it as an exact requirement, and prefer navigator.sendBeacon-based delivery where your AppMeasurement version and Launch extension support it, since it's designed specifically to survive page unload.

3. If the destination opens in a new tab (target="_blank"), there's no navigation race to manage - let the link behave natively and fire s.tl() without preventDefault() at all, since the current tab never unloads.

4. Route it through Launch's Core "Link Click" trigger where possible instead of hand-rolled event listeners - Launch's own link-tracking action already implements the send-then-navigate sequencing, which removes an entire class of hand-written timing bugs.

How to verify it worked

• Click the tracked link with the Network tab open and confirm the tracking beacon shows a completed request before the page navigates away - a request still "pending" when the new page loads means the race isn't fixed.
• In the AEP Debugger, confirm the hit is typed as a link/custom event, not a page view - check the request's link-tracking parameter, not just that "something" fired.
• In Analysis Workspace, pull single-page-view visits before and after the fix for a like-for-like time window and confirm bounce rate hasn't moved as a side effect of the correction - if it has, the original problem was miscounted page views, and this confirms it's resolved.

Illustrative, not a measured result: a resource page whose outbound PDF links were silently calling s.t() instead of s.tl() might see its reported bounce rate rise back to its true level once the call is corrected - because those visits are no longer artificially credited with a second page view.