Cross-Domain Identity Stitching for Split Checkout Funnels

The number that decides this work is the stitch rate: of the sessions that arrive on the second host, the share still tied to the first. On funnels that hand the visitor to Mercado Pago, to a Greenhouse board on boards.greenhouse.io, or to a wallet app and back, I usually measure it between 55 and 75 percent before anything changes. The missing quarter is not spread evenly. It is Safari, it is the Instagram in-app browser, and it is every path with a redirect through a provider that strips query parameters. Where I start: At the handoff, not at the container. I list every boundary in the funnel, whether it is a subdomain, a third host, a native app or a messaging thread, and for each one I ask two questions: what identifier survives it, and who controls the receiving template. That pair of questions ends about a third of proposed setups on the first call, and it is far cheaper to hear it then. What the work touches: The GA4 linker parameter stays valid for two minutes, so any flow with a login wall, an OTP screen or a payment provider queue in the middle loses it, and the answer is a server-set first-party cookie rather than a longer decoration scheme. Cookies written through document.cookie are capped at seven days in Safari, and a CNAME pointed at a vendor endpoint is capped the same way, so the server-side container runs on a subdomain with an A record to infrastructure you control. Click identifiers are captured once at entry, gclid, gbraid, wbraid, fbclid rendered into the fb.1.timestamp.fbclid form, msclkid and ttclid, then stored server-side against the session rather than re-read from the URL three pages later. The boundaries that actually decide the project: A click-to-chat link into WhatsApp carries nothing. I put a short reference token in the prefilled message body and read it off the first inbound message in the Business API webhook; for click-to-WhatsApp ads the payload carries ctwa_clid and that becomes the join key. A wallet flow returns from a mobile app in a fresh browser context, so identity binds at the first signed message rather than at connect, because silent reconnects manufacture duplicate users. An application form inside an ATS iframe cannot write a cookie in a third-party context; where the board permits a script I use postMessage, and where it does not I take the submitted event from the ATS webhook and join on the token I placed in the apply URL. Not included: Consent platform selection or procurement. Media buying. Dashboards beyond the two QA views used to verify the stitch. Warehouse modelling. And I do not fingerprint: no canvas, no IP-and-user-agent probabilistic joins, in any market, including the ones whose law would tolerate it. What I refuse: A stitch that only holds in Chrome. Work where the receiving host can neither run our code nor emit a webhook, in which case I will tell you the boundary is unmeasurable and we redesign the funnel rather than pretend. Backdating a fix into history that was never collected. Who this is not for: Single-domain products; there is nothing here for you. Teams who need the reported number to rise. The honest first result of this work is often a lower conversion count on the entry domain, because duplicate users collapse into one and double-counted sessions stop counting twice. What you hold at the end: An identity map with every boundary marked measurable or not, the server container configuration in your own repository, the click-identifier capture code, and a device test I run in front of you: Safari on iOS, the Instagram in-app browser, one Android WebView. Each shows the same user id on both hosts, or the boundary is written down as failed and why.