Routy

Page View Tracking

Capture every page load on your site — full URL included — so the GCLID, FBCLID, MSCLKID, and TTCLID parameters ad platforms need are always there when a conversion fires.

What this feature does

Most affiliate trackers only see clicks on tracking links. That's a meaningful blind spot because the data ad platforms need to close the loop on a conversion — the GCLID parameter from Google Ads, FBCLID from Meta, MSCLKID from Microsoft Ads, TTCLID from TikTok, and others — arrives as a URL parameter on your landing page, not on your tracking link. If your tracker only watches the tracking link, those parameters are gone by the time the conversion happens, and the conversion you push back to the ad platform either doesn't match or matches incompletely.

Routy's page view tracking closes that gap. A lightweight script captures every page load on your site, parses out the ad-platform click IDs automatically, and stores them against the visitor. When a conversion eventually fires — through a postback, a webhook, or any other path — the original click ID is still there and gets attached to the conversion automatically. The conversion you upload back to the ad platform now matches a specific click in the platform's own attribution model, which is what Smart Bidding and Performance Max actually need to optimise correctly.

What you'll get out of it

After the script is installed, the following becomes available in your reporting:

  • Every page load captured, with the full request URL, query string, referrer, and user agent. Not just tracking-link clicks: every page the visitor lands on.
  • Automatic click-ID capture for every major ad platform. GCLID (Google), FBCLID (Meta), MSCLKID (Microsoft), TTCLID (TikTok), and others are parsed automatically from the URL and stored against the visitor. You don't configure which parameters to capture; the script handles the known ones and stores the rest as raw data for forensic review later.
  • Full-funnel attribution from the original ad click through the page view all the way to the eventual conversion. The click ID stays attached the whole way through, so when you push the conversion back to the ad platform, it lands with a click ID the platform recognises as its own.
  • Works alongside everything else: the visitor doesn't have to click a Routy tracking link for the page view to be captured. The script captures every page they land on, regardless of source, which means organic visits, direct visits, and paid clicks are all tracked uniformly.
  • Lightweight installation: a single async script tag (or a tag-manager equivalent) loaded once per page. The script is small enough that there's no measurable impact on page-speed metrics, and it loads asynchronously so it never blocks rendering.

The forensic value of capturing the full URL rather than just the parsed parameters is meaningful when something goes wrong. If a campaign starts misattributing conversions, you can look at the raw page views, see exactly what URLs visitors landed on, and trace whether the issue is in the campaign setup, the redirect chain, or the tag configuration.

How it actually works

You install the Routy collector script on your site either by adding a single script tag to your template, or by configuring it through your tag manager (Google Tag Manager, Tealium, Segment, or any other). The script fires once per page load and sends the page-view event to Routy with the full URL, the referrer, and basic device information.

On Routy's side, the page view is associated with the visitor (via a long-lived cookie set on first visit, with a fresh visitor ID for users who don't yet have one). The known ad-platform click IDs are parsed out of the URL and stored against that visitor. When a conversion eventually fires for the same visitor, the conversion record automatically picks up the stored click IDs and any other attribution data.

Worth knowing:

  • The visitor cookie is a first-party cookie on your tracking domain (if you've configured a custom domain) or on Routy's domain otherwise. First-party cookies survive iOS Safari's tracking-prevention measures meaningfully better than third-party ones, which is one of the reasons custom domains pair well with this feature.
  • For users with strict tracking prevention (Safari with all the toggles on, Brave with the shields up, Firefox with strict mode), the visitor identification falls back to fingerprinting on the server side. The match rate is lower than it would be with cookies, but it's well above zero.
  • The script is GDPR-compatible when wired through a consent management platform — it can be conditionally loaded based on consent, and a no-consent fallback that captures aggregate-only data is available.

Why this is worth doing

For affiliate operations running on paid traffic, the difference between fully-attributed conversions and partially-attributed conversions shows up directly in the cost per acquisition curve. When Google Ads or Meta only see half your conversions because the click IDs aren't getting through, their algorithms optimise for the wrong half — they learn what works based on incomplete signal, they bid up the audiences that produce visible conversions and ignore the audiences that produce the invisible ones. Over a few weeks, that asymmetry shows up as bids drifting toward higher-CPA segments while the segments that actually convert get under-served.

Capturing the page views and the click IDs fixes the upstream cause rather than the downstream symptom. The ad platforms get conversions back with the right click IDs attached, their attribution windows see them, and Smart Bidding has the full conversion signal to work with. The result, almost always, is a measurable drop in cost per acquisition over the following month.

For affiliates not running paid traffic, the feature still pays off — the full URL capture is what makes attribution forensics possible when something looks off, and the visitor-level identity is what makes per-visitor reporting work.

Frequently asked questions

Do I need to install anything if I'm only using Routy's tracking links?

For pure click-tracking, no. But if you want the ad-platform click IDs to flow through to conversions, you need the collector script on the page the visitor lands on after clicking, because that's where the click ID lives.

Does this require my own backend?

No. The script is client-side JavaScript. It sends events to Routy's collector endpoint directly.

What about iOS Safari's tracking prevention?

The collector script uses first-party cookies on your custom domain (if configured) and falls back to server-side fingerprinting for cases where cookies are blocked. Match rates are meaningfully better with a custom domain than without.

Will this slow down my site?

The script is async, small (under 5KB gzipped), and only fires one HTTP request per page load. There's no measurable impact on Core Web Vitals.

What other click IDs does it capture beyond the big four?

The major paid-media platforms (GCLID, FBCLID, MSCLKID, TTCLID) are parsed by name. All other URL parameters are stored as raw data and available for inspection or custom attribution logic later.

Ready to try Page View Tracking?

Add the collector script to your site (or wire it through your tag manager). Once installed, the click-ID capture happens automatically — no further configuration needed for the major ad platforms.