Platform · Sfere ID
Sfere ID is a sovereign CDP and real-time identity graph. It resolves fragmented, anonymous touchpoints into one governed golden fan profile, in-Kingdom, consented, and yours to own.
One week, one fan
Six ordinary moments from one week. No configuration, no rules to learn - just scroll, and watch a blank card become a person. The card on the right is the only thing to follow.
fig. 01 · monday
Someone reads two pages on the website and leaves. No login, no name - the only thing anyone saw is a cookie: c_9f2. Your analytics counts a "visitor". That's the whole relationship so far.
→ the card gets its first mark: one dashed chip, and an UNSIGNED stamp.
fig. 02 · wednesday
At the box office, someone buys a ticket - and gives an email: sara@…. Now the card has a holder: Sara. The ticket number t_8841 is stapled on with it.
→ the HOLDER field writes itself in. Stamp: IDENTIFIED.
fig. 03 · thursday
Evening: a stream login from a laptop - carrying the same cookie as Monday's stranger. So Monday was never a stranger. It was Sara, before we knew her. History rewrites itself onto her card.
→ the cookie chip pulses: Monday's visit back-fills into Sara's story.
fig. 04 · friday
The app opens on a phone, then logs in with the same email. A loyalty scan follows at the stadium gate. Phone, laptop, inbox, ticket, gate - five ways she shows up, one person behind all of them.
→ gold foil slides on. Stamp: GOLDEN PROFILE. Fan № 48211.
fig. 05 · saturday
A family tablet: kids' shows all afternoon, then Khalid logs in, then Lama. One device, two different people. A greedy graph would fuse them into one "fan" and call it complete. This one refuses.
→ the shared device tries to bridge two cards. The guardrail blocks it: HELD APART.
fig. 06 · the count
Your tools counted nine separate records this week. The graph holds three fans - and one honest "we don't know yet". Nobody invented, nobody merged by mistake, every join can show its evidence.
waiting for the first touch…
ids: 0 · status: blank
Same records, different rules
The story you just watched is the graph under Sfere ID's defaults. Flip each scenario to see the same week resolve a different way - because the rules are yours to define.
with email as evidence: one fan
same week, three "strangers"
Take one identifier away and one fan lands as three separate records. This is why identity can't hang on a single hard key.
guardrail on: two people, kept two
two real people, one wrong profile
Without the guardrail, the family tablet collapses a marriage into one "fan" - and every message downstream is wrong for one of them.
definition: one person
definition: household - merged on purpose
Decide what a fan means for your business - one person, a family sharing a season pass, a corporate box - and resolution follows your model.
How it works
From the first anonymous visit to one governed profile, Sfere ID keeps resolution accurate, explainable, and current at every stage.
The same fan shows up as a phone at the gate, a laptop on the stream, and an anonymous browser in between. Sfere ID joins those appearances into one profile, so recognition survives every device switch.
The moment a fan acts is the moment to respond. Profiles update in real time as signals arrive, with no waiting on a nightly batch to learn what already happened.
Decide what a fan means for your business: one person, a family sharing a season pass, or a corporate box holder. Resolution follows your definition instead of forcing one shape.
Anonymous behavior is tracked from the first touch and joined to the profile once a fan identifies, so the pre-signup history and everything after it read as one relationship.
Resolve on any combination of identifiers rather than one hard key, and apply your own data-quality rules so identity stays accurate as profiles merge.
Consent & residency
The hardest part of a fan graph isn't collecting data; it's owning it responsibly. Consent, residency, and deployment are built into Sfere ID from the profile up, so the same record that powers activation is also the one that keeps you compliant.
Connect your data
Sfere ID sits on an open connector framework and a warehouse you self-manage. Bring the touchpoints you already have, with no rip-and-replace and no vendor holding your fan data hostage.
An open connector framework ingests events from ticketing, streaming, app, web, on-site, and social, with no parallel database to maintain.
Map your existing user IDs with custom identifiers and attributes, so the profile fits the data you already keep.
Stream to a columnar analytical warehouse you self-manage in-Kingdom, so the platform stays composable with your stack.
A clean REST API and client SDKs cover anything custom, so every capability is programmable.
How resolution works
Resolution matches signals on any identifier, merges them into one golden record, and applies guardrails so distinct fans stay distinct.
Email, device, app ID, ticket or order number, loyalty ID, custom IDs: each is a first-class identifier with its own merge rules. Resolution connects events on any of them, so you are not forced to hang identity on a single field that is often missing.
New signals either match an existing profile, create one, or merge several into a golden record as the graph learns the relationships. Contested matches follow rules you set, rather than silently collapsing two real people into one.
Per-identifier limits stop a shared device or family login from over-merging distinct fans. When a limit would be crossed, the system holds the records apart instead of guessing. Correct identity beats complete-but-wrong identity.
Questions
Bring your messiest export to a walkthrough. We'll run it through Sfere ID live and show you the golden profiles, the merge evidence behind every one of them, and the records the guardrail refused to guess on.