Does LeadJourney offer cross-browser tracking?
How LeadJourney keeps a journey connected when the click and the conversion happen in different browsers – for example a tap in the Instagram in-app browser, then a purchase in Safari or Chrome.
Yes – including the case that trips up most trackers: an ad clicked inside an app's in-app browser, then a purchase finished later in the visitor's normal browser. Because LeadJourney's anchor lives on the server rather than in a single browser, the journey stays in one piece even when the browser changes.
In short
LeadJourney attributes through a click ID that is stored server-side, not a cookie tied to one browser. A conversion reported later – from a different browser, an in-app webview, your CRM or a payment provider – is matched back to the click that started it.
Why cross-browser tracking is normally hard
Tracking usually lives in a browser cookie, and a cookie is sealed inside the browser that set it. Open the same site in a different browser and that cookie simply isn't there – so a cookie-only tracker sees a fresh, anonymous visitor and the original ad click is lost.
The most common place this happens isn't even two separate apps – it's a single visitor on a single phone:
- They tap your ad inside the Instagram, Facebook or TikTok in-app browser (a webview).
- Later they reopen the link, or finish checkout, in their default browser (Safari or Chrome).
Those two browsers don't share cookies. A cookie-based tool treats the in-app click and the Safari purchase as two unrelated people, and the ad gets no credit for the sale it produced.
How LeadJourney bridges browsers
LeadJourney's anchor isn't a per-browser cookie – it's a click ID captured at the moment of the click and kept on the server. Two things carry it across a browser switch.
1. The click ID travels in the URL, not in a cookie
When someone clicks your ad, a click ID is created and rides along in the URL through your funnel. Because it lives in the link rather than in browser storage, it survives being opened in a different browser:
https://yoursite.com/?click_id=8f3c… ← still present when opened in any browserThe LeadJourney script reads click_id (and any lj_* campaign parameters) straight from
the URL and continues the same journey, no matter which browser loaded the page.
2. Conversions are matched server-to-server
The moment the visitor submits a form, the click ID is attached to a real lead in your system. When the sale finally happens, it's reported back to LeadJourney server-side:
- your CRM marks the lead as won, or
- a postback / webhook from your checkout or payment provider fires.
That report carries the click ID, so LeadJourney matches it to the original click without needing the same cookie or browser. (Each conversion also carries a transaction ID, so a re-fired postback is de-duplicated rather than counted twice.)
Where the browser switch disappears
Because the match happens through the click ID on the server, the question "was it the same browser?" stops mattering. An in-app click and a Safari conversion become one journey as long as the click ID carried through to the conversion event.
A typical cross-browser journey
- Instagram in-app browser: a visitor taps your ad. LeadJourney captures the click ID and the campaign, ad set and ad.
- The click ID rides the URL into your funnel and onto the lead when they enter their details.
- They reopen the link – or come back to finish checkout – in Safari, their default browser. The click ID is still in the link, so the journey continues rather than restarting.
- The sale is reported (via your CRM or a postback) with the click ID. LeadJourney attributes the revenue to the original in-app click.
What it can and can't do
It bridges browsers when there's a click ID to follow – which covers the journey that actually drives revenue: click → lead → sale, even when the in-app click and the final purchase happen in different browsers.
It does not guess that two anonymous visitors are the same person. If someone browses anonymously in one browser, never identifies themselves, and later buys from a fresh, parameter-free visit in another browser, there's no shared click ID to connect them – and LeadJourney won't invent one. To get the most coverage:
- Keep the click ID flowing. Carry it through redirects and into your funnel and CRM so it's present when the conversion is reported. See cross-domain tracking for how it travels between domains.
- Report conversions server-side (CRM or postback) rather than relying only on a browser pixel that can't see the other browser.
Related articles
Does LeadJourney offer cross-device tracking?
How LeadJourney keeps a click on one device connected to a conversion that happens later on another – on the phone, then the laptop, or closed offline in your CRM.
Is LeadJourney adblock-proof?
Why LeadJourney is far more resilient to ad blockers than a typical third-party tag – it runs first-party from your own domain – and the honest limits of any tracking setup.