What Is Visit-Sibling Inheritance in Attribution?

Visit-sibling inheritance hands a sourceless session the attribution of another session from the same visit. One person arriving once routinely produces two or three sessions — a payment redirect, a jump to a subdomain, a phone dropping off wifi — and only the first carries the campaign tags and the click id. When the session that converts is not the session that arrived, the sale reads as Direct. Inheritance matches the siblings on device and timing, then copies the source forward.

The word doing the work is sibling: not two visits on two days, but fragments of one continuous visit that the web cut in half. The distinction matters because the fix is different. Joining visits across days and devices is identity resolution, and it needs a person-level identifier — an email, a phone number, a durable visitor id. Joining fragments inside one visit needs none of that: they happened minutes apart on the same device, and that is enough.

Why does one visit turn into several sessions?

Because a session ends whenever the browser stops looking like the same context, and several ordinary things do that. Each break starts a fresh session with an empty referrer and no campaign parameters — indistinguishable from someone typing your domain in cold.

The common causes, in rough order of how often they bite:

• A payment or booking redirect. The visitor leaves for a gateway, a scheduler or a hosted checkout, then comes back. The return leg is a new arrival from a different domain.
• A domain or subdomain hop. Landing page on one host, checkout on another. Cookies scoped to the first host do not travel, and the parameters were only ever in the landing URL.
• A network switch. A phone walking out of wifi onto cellular gets a new IP address mid-session.
• An in-app browser handoff. Tapping an ad inside a social app, then opening the page in Safari or Chrome, is two browser contexts, not one.
• A timeout. Someone reads, gets distracted, comes back after the session window closes. Same tab, same person, new session.
• A referrer that never survives. Cross-origin navigations frequently arrive with the referrer trimmed to a bare origin or missing entirely, depending on the sending page’s policy — rarely enough to name a channel, let alone a campaign.

None of these are edge cases. Between them they cover most paid traffic that ends in a checkout.

What does a sourceless session actually look like in a report?

It looks like Direct, and Direct is not a channel. It is an empty field wearing a channel’s name.

A report cannot distinguish “this person typed our URL from memory” from “this person clicked a Meta ad ninety seconds ago and the parameters did not survive the redirect”. Both arrive with no utm_source, no click id and no usable referrer, so both get filed in the same bucket. That is the main reason ad conversions show up as Direct at rates no media buyer believes.

The damage is not evenly spread. Sourceless sessions cluster at the end of journeys, because the end of a journey is where the redirects are. The traffic that gets robbed is the traffic that converts, so the campaigns that get starved are the ones that were working. There is a quick tell: if your Direct bucket converts at several times the rate of the rest of your traffic, Direct is not a channel in your account — it is a landfill for broken sessions.

How does visit-sibling inheritance actually repair a session?

By looking for another session that must be the same visit, and copying its attribution across. The test is deliberately narrow: same device signature, same short time window, one of them holding real campaign evidence. When a candidate passes, the sourceless session inherits the click id, the UTMs and the landing page from its sibling.

In practice the matching runs as a small ladder, strongest evidence first.

Tier 1 — same device, same network, minutes apart

The primary test is same client, same IP address and same user agent, within about thirty minutes either side. That combination is a strong claim: the same browser build on the same connection inside half an hour is the same person continuing the same thing. A session passing this test inherits the full strong signal — click ids and campaign tags, not just a channel name. Thirty minutes is a deliberate ceiling: widen it and you merge genuinely separate visits, tighten it and you lose the reader who spent twenty minutes on a pricing page first.

Tier 1B — the cellular handoff

The IP match is the part that breaks first, because phones change networks constantly. So there is a second, narrower tier for exactly that case: same user agent and a matching platform click cookie within a tighter ten-minute window, with the IP address allowed to differ.

That is a phone leaving the house mid-checkout. Dropping the IP requirement alone would be reckless, so this tier takes a cookie match and half the window in exchange.

Tier 2 — the weak referrer fallback

When no click id or UTM exists anywhere in the visit, the last resort is the referrer, and the result is explicitly labelled weak. A referrer can usually name a channel and almost never names a campaign. Treating that as equivalent to a click id is how reports quietly become fiction, so it is inherited, marked low-confidence, and shown that way.

How is this different from identity stitching?

Sibling inheritance repairs one visit. Identity stitching joins a person’s visits together, and the two run on completely different evidence.

They stack. Inheritance gives each visit one honest source; stitching then assembles those repaired visits into a journey. Run stitching alone and you join up sessions that are individually mislabelled. Run inheritance alone and you get clean visits that never add up to a person — the separate problem of how to track leads across devices.

When does sibling inheritance get it wrong?

It has real failure modes, and anyone selling you a version without them has not stress-tested it.

Shared networks can merge two people. An office, a campus, a café: same public IP, plausibly the same browser version, both browsing within the window. The user-agent requirement and the short window make this unlikely rather than impossible — which is why the window is minutes rather than hours.

It cannot invent a source. If the first fragment of the visit was itself sourceless — an ad blocker killed the script on arrival, or the link was untagged — there is nothing to inherit. Inheritance moves evidence; it does not manufacture it.

The handoff tier depends on a cookie. No platform click cookie, no cellular-handoff match. A visitor who blocks it gets the strict Tier 1 test or nothing.

Weak stays weak. A referrer-derived source should never be reported as though a click id proved it.

What can you do about this without any tool?

Several things, and each one means less repair work later.

1. Carry parameters across redirects. If your checkout or scheduler lives on another host, append the campaign parameters to the outbound URL and read them on the way back.
2. Store attribution on arrival, not at conversion. Write the click id and UTMs into first-party storage the moment the visitor lands. The landing URL is the only place they ever exist.
3. Set your visitor cookie from the server. A cookie written by JavaScript faces much shorter browser caps than one set in an HTTP response from your own domain — the foundation of first-party attribution, and it costs nothing.
4. Exclude your payment gateway from referral traffic in your analytics, so the return leg stops counting as a new acquisition.

Where this runs out is the repair itself. Redirect chains you do not control, in-app handoffs and network switches still split visits — and excluding a referral domain stops the gateway getting credit without giving it back to the ad.

How does PartialLeads apply visit-sibling inheritance?

It runs the three tiers above automatically, on every session, before anything is reported. A converting session with no source is tested against its siblings from the same visit, and on a Tier 1 match it inherits the strong signal — click ids and campaign tags — rather than being filed as Direct.

A concrete shape, with illustrative numbers: a shopper clicks a Google ad, lands with a gclid, browses, then checks out in a session showing nothing at all. Inheritance finds the earlier session on the same device and IP eleven minutes back, and the purchase is labelled Google Ads instead of Direct. One sale is a rounding error; across a redirect-heavy checkout it is a systematic bias.

Two surfaces prove it rather than assert it. The Journey column on the Leads list draws each touch as a badge, so a repaired visit shows the channel glyph on the converting touch instead of the grey dot that means “we do not know” — and that grey dot is still used honestly where nothing resolved. The Attribution report then carries a Recovered Attribution block itemising the revenue a raw-UTM or last-click view would have lost, so the repair is a number you can argue with rather than a silent adjustment.

Repaired attribution is also what gets sent back out. When a conversion is dispatched server-side through the Conversions API, it carries the click id the visit actually arrived with, not the empty source the converting session happened to hold. An event with the click id attached is an event the platform can match to a click.

Honest constraints, plainly: inheritance works within a visit, so cross-day and cross-device joins are the identity graph’s job. The referrer tier stays labelled weak. And where the first fragment carried no evidence either, the session stays Direct — reading that disagreement rather than trusting one number is the whole skill of learning to read an attribution report.

Sources

https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/fbp-and-fbc https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters https://developers.facebook.com/docs/marketing-api/conversions-api