Self-attributing network

Definition

A self-attributing network is an advertising platform that performs attribution on its own servers and reports the installs it claims to have caused, rather than passing a click identifier for a third party to match.

Google, Meta, Apple Search Ads, TikTok, Snap and X all work this way. The distinction matters because a SAN does not send you a click you can match — it sends you an answer. Your measurement stack's job with a SAN is not to attribute the install but to ask the network whether it wants to claim one, and then to decide what to do when several say yes.

How a SAN handshake differs from a tracking link

With an ordinary network you own the click. The ad points at a link you control, that link carries a click ID, and the install is matched against your own record — deterministic attribution in the plain sense. With a SAN, the click never touches your infrastructure. The ad opens the store directly, and the matching happens inside the network's own logged-in graph.

That final row is the whole trade. You gain access to inventory that no tracking link can reach, and you give up the ability to check the working. This is why the SAN relationship is normally mediated by a certified measurement partner: certification is the network's mechanism for trusting the probe, and the industry's mechanism for the answers being applied consistently.

Which platforms are SANs, and what each requires

Apple Search Ads is the outlier worth knowing about: attribution runs through the on-device AdServices framework, which returns a token your own server exchanges with Apple. No third party is required, and the response is first-party data you can audit — closer to a tracking link than to a classic SAN handshake despite Apple performing the match.

import AdServices

// The token is generated on device and is valid briefly.
// Exchange it server-side; never trust a client-reported attribution result.
func fetchAttributionToken() -> String? {
    do {
        return try AAAttribution.attributionToken()
    } catch {
        // Simulator, missing entitlement, or the API being unavailable
        // on this OS version all land here. Fail open: report unattributed
        // rather than guessing a campaign.
        return nil
    }
}

When two networks claim the same install

They will. A user can see a Meta ad, search on Google, and install — and both graphs contain a plausible touch. Because each SAN answers only about itself, the tie is broken by a priority order applied outside them, normally by the measurement partner, using each network's declared attribution window and touch type.

The rows that cause arguments are 2 and 4. A SAN reporting a view-through install inside a generous window will out-claim a genuine organic install every time it is ranked above nothing, which is why the view-through share per network is worth monitoring as its own metric rather than folded into a campaign total.

Expect network dashboards to sum to more than your install count, permanently. Each SAN is answering "did I plausibly cause this?" in isolation, and several can honestly answer yes. The reconciliation is not a bug to fix — it is the arithmetic of asking several parties the same question.

What to keep under your own control

• Your own click record for every link you own, so at least one column in the report is auditable.
• A single install definition, applied identically to SAN-claimed and organic installs.
• The priority order, written down and version-controlled, because it is a budget policy.
• Per-network view-through share, tracked over time.
• A periodic holdout, since no SAN's self-report can measure its own incrementality.

None of this makes SANs untrustworthy. It makes them what they are: parties with an interest in the answer, reporting on themselves under rules they publish. The failure mode is not deception — it is a team treating six self-reports as if they were one ledger.