Platform · Sfere ID
Sfere ID is a customer data platform and real-time identity graph that resolves fragmented, anonymous touchpoints into one golden customer profile, consented and yours to own
One week, one customer
Six ordinary moments from one week. No configuration and no rules to learn. 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
In store, someone buys a jacket and asks for the receipt by email: maya@…. Now the card has a holder: Maya. The order number o_8841 is stapled on with it
→ the HOLDER field writes itself in. Stamp: IDENTIFIED
fig. 03 · thursday
Evening: a sign-in to the online store from a laptop, carrying the same cookie as Monday's stranger. So Monday was never a stranger. It was Maya, before we knew her. History rewrites itself onto her card
→ the cookie chip pulses: Monday's visit back-fills into Maya's story
fig. 04 · friday
The app opens on a phone, then logs in with the same email. A loyalty scan follows at the store register. Phone, laptop, inbox, receipt, register: five ways she shows up, one person behind all of them
→ gold foil slides on. Stamp: GOLDEN PROFILE. Customer #48211
fig. 05 · saturday
A family tablet: kids' shows all afternoon, then Daniel logs in, then Ava. One device, two different people. A greedy graph would fuse them into one "customer" 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 customers, plus 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 customer
same week, three "strangers"
Take one identifier away and one customer 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 married couple into one "customer," and every message downstream is wrong for one of them
definition: one person
definition: household, merged on purpose
Decide what a customer means for your business (one person, a family sharing one account, a company with several buyers) and resolution follows your model
How it works
Sfere ID keeps resolution accurate, explainable, and current at every stage, starting with the first anonymous visit
The same customer shows up as a loyalty scan in store, a laptop in your online store, and an anonymous browser in between. Sfere ID joins those appearances into one profile, so recognition survives every device switch
The moment a customer 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 customer means for your business: one person, a family sharing one account, or a company with several buyers. Resolution follows your definition instead of forcing one shape
Anonymous behavior is tracked from the first touch and joined to the profile once a customer 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 customer 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 own. Bring the touchpoints you already have, with no rip-and-replace and no vendor holding your customer data hostage
An open connector framework ingests events from online stores, point of sale, app, web, streaming, ticketing, 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 own, 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 people stay distinct
Email, device, app ID, order or ticket 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 people. 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