How do I tell if my redirect is server-side or client-side?

In DevTools Network, server-side shows HTTP 301/302 with a Location header. Client-side shows a 200 HTML document that redirects with JavaScript or meta refresh.

Can I still use a tracking template under parallel tracking?

Yes, if the tracker uses fast server-side HTTPS redirects. Put UTMs in the Final URL suffix, not only in the template.

Will moving UTMs to the Final URL suffix break anything?

No. Under parallel tracking the suffix is the correct place for landing-page parameters. It usually fixes false Direct sessions caused by template-only UTMs.

Guides · Google Ads

Parallel Tracking and Redirects

Q: Does parallel tracking break Google conversion tags?

Not directly. Conversion tags fire on the landing page after load. What breaks is pre-landing redirect logic that assumed the browser would visit the tracker.

What breaks under parallel tracking (JS hops, HTTP, UTMs only in the template), what still works (fast server-side HTTPS), and how redirect vs suffix trackers fit.

Parallel tracking is mandatory across Search, Shopping, Display and Video. For a plain Final URL it is mostly invisible. For redirect-based click tracking it is the reason data goes missing while the landing page still “works” — no red banner in Google Ads, just empty fraud logs or Direct sessions in GA4.

The browser goes to your landing page. Tracking runs in the background. Anything that needed the user’s browser to visit the tracker first is out of the path.

Field ownership: tracking template vs Final URL suffix. Encoding for multi-hop redirects: {lpurl} encoding. Account pattern: Ideal tracking template setup.

What parallel tracking changes

Old sequential model:

Click → Google → tracker hop(s) → landing page

Each hop sat on the user’s critical path. Slow trackers meant slow landings.

Parallel model:

Click → browser opens Final URL (+ Final URL suffix)
      → Google hits your tracking template asynchronously

Page speed improves. Your tracker only sees Google’s background request — not a user navigating through its HTML. Client-side “load page → set cookie → JS redirect” stacks never run for that user.

What breaks

Client-side / JavaScript redirects

Bypassed. The browser never loads the tracker document, so none of this runs:

<meta http-equiv="refresh">
window.location / JS bounce pages
Anything that needs a first-party pageview on the tracker domain before the hop

HTTP (non-HTTPS) in the chain

Final URL, tracking template, and every redirect target need HTTPS. HTTP is a hard fail or a silent drop — migrate the tracking host before you debug macros.

Slow or long chains

Background tracking has a practical timeout. Three TLS handshakes and a sleepy origin and the ping is gone even if each hop is “valid” 302. Prefer one fast hop. If you need two, keep each response tight (aim well under ~100 ms server time; treat multi-hundred-ms spikes as risk).

UTMs only in the tracking template

The browser never walks the template URL, so query params you stuffed after {lpurl} never become the landing address. Those sessions land as Direct (or worse) in GA4. Put UTMs in the Final URL suffix — Google attaches them to the destination the browser actually opens.

What works

Server-side HTTPS redirects

Tracker answers Google’s background hit with 301/302 + Location. No HTML, no JS. That is the compatible redirect model.

HTTPS on every hop
Real redirect status codes (not a 200 + script)
Fast enough that the async request finishes
Correct {lpurl} / {lpurl+2} for the hop count

Examples on this site: ClickCease, ClickPatrol, and other redirect rows in certified click trackers (filter Redirect).

Final URL suffix for parameters

Suffix is part of the destination, not the redirect chain. It survives parallel tracking by design.

Final URL:         https://example.com/landing
Final URL suffix:  utm_source=google&utm_medium=cpc&utm_campaign={campaignid}&utm_term={keyword}
Tracking template: https://track.example.com/click?url={lpurl}&cid={campaignid}

Keep auto-tagging on so Google adds gclid (and wbraid/gbraid where needed). You do not need to invent a gclid= ValueTrack in the suffix for that.

Wrong pattern:

https://track.example.com/click?url={lpurl}&utm_source=google&utm_medium=cpc

UTMs ride the template only → often never on the page the browser loaded.

Suffix-only (no redirect)

Some tools never sit in front of the click. They read gclid / params on the landing page and act later (exclusions, bidding signals). Fully parallel-safe; you give up pre-landing blocking. Example: Fraud Blocker (and other Final URL suffix listings).

Compatible vs not

Setup	Parallel-safe?	Notes
One server-side HTTPS redirect	Yes	Default for fraud filters that own the template
Two–three fast server-side hops	Usually	Watch total latency; fix `{lpurl}` encoding
JS / meta-refresh bounce	No	Browser never runs it for the user
HTTP anywhere in the chain	No	Upgrade to HTTPS first
Suffix-only measurement	Yes	No pre-click block
UTMs only in the template	Breaks landing UTMs	Move to Final URL suffix

Certified trackers: redirect vs suffix

The certified Google click trackers directory splits tools by template kind. Use it to pick architecture, then confirm with the vendor that they support parallel tracking (server-side HTTPS, documented template).

Redirect (Tracking template) — ClickCease, ClickPatrol, ClickGuard, TrafficGuard, and others under Redirect. Can inspect / block before the page renders when the async chain completes.
Final URL suffix — Fraud Blocker, Fraud0, and suffix listings. Params land with the user; action is after the click.

Neither model is universally “better.” Pre-click blocking needs a parallel-safe redirect. Pure measurement can stay suffix-only. Mixing both is normal: redirect in the template, attribution keys in the suffix (e.g. ClickCease + WhatConverts).

How to verify a redirect

Paste the tracking URL (or use Google Ads Test) and open DevTools → Network.
Look for 301/302 with a Location header — server-side.
A 200 HTML page that then navigates with JS or meta refresh — not parallel-safe for the user path.
Click a real ad once. Confirm the address bar after all redirects still has your suffix params.
Check the vendor dashboard for the click, and GA4 Realtime for google / cpc.

Decision order

Need a redirect fraud / click tool? Template must be their HTTPS server-side URL wrapping {lpurl} (right encoding).
Need UTMs / CRM keys on the page? Final URL suffix — not the template query string.
No redirect product? Template can be {lpurl} or empty; suffix carries params.
Still missing data? Chain length, HTTP, JS bounce, or under/over-encoded {lpurl}.

Generate a split setup in the template builder.

FAQ

Is parallel tracking mandatory?

Yes for modern Search, Shopping, Display and Video. Build as if there is no opt-out.

My redirect tracker still shows clicks — how?

Likely server-side HTTPS. Parallel tracking still sends Google’s background request through that chain. Confirm with Network status codes, not vibes.

How do I tell server-side from client-side?

Server-side: 301/302 + Location. Client-side: 200 document that redirects in HTML/JS.

Can I keep a tracking template?

Yes, if the tracker is parallel-safe. If it is JS-only, move to a suffix-compatible tool or suffix-only measurement.

Will moving UTMs to the suffix break anything?

It is the correct place under parallel tracking. Expect fewer false Direct sessions when the old template-only UTMs never reached the page.

Does parallel tracking break Google conversion tags?

Not directly. gtag / GA4 / enhanced conversions fire on the landing page after load. What breaks is pre-landing redirect logic that assumed a browser visit.

How slow is too slow?

Google does not publish a hard public timeout. Treat sub-100 ms per hop as a target; inconsistent 300 ms+ responses are where practitioners see dropped pings.

← All guides · Trackers · Recipes