Page View Tracking

The Routy tracking pixel is a snippet of JavaScript you paste once per site, ideally just before </head>. It records page views, and it copies gclid, fbclid, obclid and any utm_* parameter off the landing page URL onto the affiliate links on that page, so the click Routy records carries the identifier the ad platform issued.

That copying is what gets a paid click's id into Routy. Google Ads auto-tagging puts gclid on your landing page URL, not on your tracking link. When Routy pushes a conversion back to Google Ads it looks for the click id in the landing page view first, the referrer page view second, and the click URL last, so on a site with no pixel installed there is usually no gclid to send and nothing gets pushed.

Each site has its own asset key. The snippet loads collector/<your-asset-key>.js and already carries your link matching rules, so there's nothing in it to edit and nothing to re-paste when a setting changes.

• Page views carrying the page address, the title, the referrer and the visitor's device, recorded against the traffic source the site belongs to.
• Campaign parameters copied onto matching affiliate links. Matching runs against the link's href, not the page's address, so a rule like example.com/lp matches nothing unless it shows up in a link.
• The visitor's path through the site. Every page view carries the id of the landing page and the id of the page navigated from, so from a click you can walk back to the first page of the visit and the parameters it arrived with, without matching on IP.
• Page views on in-app navigation, for single-page sites where the browser never loads a second document.
• Visitor device details with each page view: screen size and usable area, viewport, colour depth, operating system, processor core count, approximate memory, graphics vendor and model, preferred languages, timezone, and connection class, speed and latency.
• A device ID worked out from the parts of that which belong to the machine rather than the browser, so the same visitor is recognisable in Chrome one day and Safari the next, and after clearing cookies.
• Device type, brand, model, browser and operating system on every click and page view, with the finer detail as dd- entries in the record's headers: dd-brand, dd-model, dd-browser-version, dd-engine, dd-os-version, dd-os-platform.
• Google Analytics 4 client and session ids, and GA's copy of gclid, attached to the page view once you set a measurement ID. Meta's _fbp and _fbc get picked up wherever fbq is already on the page, with no setting to turn on.
• Crawler and spider page views dropped on arrival instead of stored, along with anything reporting itself as a headless browser.

Reports cover the last three months of page views. Older ones come from exports and the archive.

Installing it

Open the Install Pixel panel for your site, copy the snippet, paste it into your template. Then run the Pixel Setup Test: Routy hands you a test link, you open it and browse your own site the way a visitor would, and eight checks report back live as the pixel reaches them. They cover configuration, cookies, visitor ID, page view tracking, link interception, analytics integration, visitor info and the script loading. A test link lasts 30 minutes, and the traffic it produces is flagged as test rather than counted as live tracking, so running the test against your live site is fine.

What's on and what isn't

A new site starts with "track every page" off. With it off, a page holding no matching affiliate link records nothing at all, and that is the usual answer to "the pixel is installed and I see no page views". Turn it on to measure whole visits rather than only the pages that can produce a click.

"Tag links on click" is on. The tagged address is parked on an rt-href attribute and copied into href at the moment someone clicks, which keeps the links in your page clean. Turn it off only if something on the page reads href before the click.

"Remember visitors with cookies" is off on a new site. Without it, a visit is kept per tab, so a link opened in a new tab begins a fresh one; with it on, the new tab continues the visit it came from.

"Collect visitor device details" is on. Turning it off stops collection from that point and doesn't delete what's already recorded, so ask support if you need existing rows removed.

"Wait for Google Analytics" holds the page view for up to two seconds so the GA ids can be attached to it.

Changing a setting

Changes are served on the next request, and your snippet doesn't change, so you never re-paste it into your site. If you're verifying a change you just made, hard-reload the page, because your own browser may still be holding the previous copy of the script for up to an hour.

Closing a traffic source now stops its pixel collecting. It used to carry on sending page views from a source you had closed, and they carried on counting.

Delivery

Page views travel in the body of the request. They used to travel in the page-view web address, which sat close enough to the length limit some networks enforce that a long page title or a link carrying campaign tags could push one over it, and past that limit a page view is lost without a trace. Browsers too old for the new method fall back to the old one on their own.

Privacy

A visitor whose browser sends Do Not Track still has the page view and the navigation chain recorded; the canvas and WebGL fingerprints are skipped, so there's usually no device ID for them. IP addresses are shortened before storage. The device ID is a one-way fingerprint: it can't be reversed into the details it came from, it isn't a name or an email, and it doesn't follow anyone to another website.

If you operate where device details need consent, the UK and EU among them, "collect visitor device details" is the setting your consent tooling should govern, and off is the right value for a site where you can't get that consent.

When it refuses

Four states return an error instead of recording the page view: your page-view allowance is used up, the asset key is wrong or disabled or the page's domain isn't registered to that site, the traffic source isn't enabled, or the account is on hold.

The identifier an ad platform needs back is issued on the landing page, not on your tracking link. Google Ads auto-tagging appends gclid to the address the visitor arrives at; your Routy link was already clicked by then. A tracker that watches only the link has nothing to put in an offline conversion upload, so the conversion stays in your own reports and never reaches the Google Ads account that paid for the click.

Reading the landing page view is how Routy avoids that, and it's why "no pushes are happening at all" nearly always resolves to no gclid found in the page views. Auto-tagging on, pixel installed, and the chain holds.

The page views also give you the path, which is worth having whether or not you buy traffic. A click carries the id of the page it happened on, that page carries the id of the landing page, and the landing page holds the original address. So a conversion traces back through the visit to where the visitor came from.

Two limits worth knowing before you plan around this. Conversion push is live for Google Ads; the fbclid, msclkid and obclid click ids are extracted and mapped to Meta, Microsoft Ads and Outbrain, but those uploads aren't built yet. And device details describe an audience rather than prove an identity. They're self-reported by the browser and can be faked, so treat a repeated device ID as a strong hint.