sharedata / examples
Topologies, by example

Three ways to wire it.

The same primitive — match, enrich, verify — composes into three shapes. Here's each one as a real marketing scenario: who holds what, what crosses the wire, and the question that gets answered without anyone's list ever moving.

1 : 1Two brands, audience overlap 1 : manyEnrichment as a service many : 1A retail-media co-op
TOPOLOGY · 1 : 1
Two parties match

Audience overlap between two brands.

A DTC coffee brand and a national magazine want to run a co-branded campaign — but only to people who are already customers of both. Neither will hand over its list.

The setup. Roast Co has 1.2M CRM emails. The Atlas (a publisher) has 4M subscriber emails. They want the size of the overlap, and the ability to target it — without Roast Co learning The Atlas's subscriber list, or vice versa, and without either uploading to a third party.

Roast Co 1.2M CRM emails The Atlas 4M subscribers blinded tokens → ← witnesses 311k the only answer that crosses
  1. 1Roast Co blinds its list. Each CRM email is normalized and turned into a token T = HMAC(k, email) on Roast Co's own infrastructure.
  2. 2The Atlas evaluates blind. It derives the same function over its subscriber emails and checks for matching tokens — seeing only opaque values, never a Roast Co address.
  3. 3Witnesses come back. The Atlas returns an unforgeable proof for each match. Roast Co counts them: 311,402 shared customers.
  4. 4Activate the overlap. Both sides now hold the matched segment as tokens and can target the co-branded campaign to it — without ever exchanging the underlying lists.
Example
# Roast Co asks
overlap(my_crm, atlas_subscribers)
# answer
311,402 matched · segment ready
    Stays home
  • Roast Co's CRM emails
  • The Atlas's subscriber list
    • Crosses the wire
  • Blinded tokens, both directions
  • Match witnesses + the overlap count
Why 1:1. Symmetric, two known parties, one relationship. This is the classic co-marketing / partner overlap deal — same shape as two firms checking a shared suppression list, or a brand verifying a partner's match rate before signing.
TOPOLOGY · 1 : many
One provider serves many consumers

Enrichment as a service.

One data provider publishes a queryable signal; thousands of marketers enrich their own audiences against it — each seeing only answers about records they already hold.

The setup. SignalIQ maintains an IP → buying-intent dataset (e.g. in-market: auto-insurance). Hundreds of agencies and in-house marketing teams want to score the traffic and email lists they already have. SignalIQ wants to monetize per-query without shipping its whole dataset to anyone, and the marketers don't want to reveal which visitors or customers they're scoring.

SignalIQ IP → intent provider endpoint Agency A Brand B marketing Agency C DTC shop D each query carries one metering token · answer scoped to the asker's own records
  1. 1Provider stands up an endpoint. SignalIQ runs the node holding its IP → intent data under its own key, sets a price ($0.002/query) and rate limits.
  2. 2A marketer blinds its query. Brand B blinds the IPs in its traffic log locally and sends only blinded values — SignalIQ never sees which IPs were asked about.
  3. 3Provider evaluates & returns enrichment. For matches, it returns the intent signal bound to those records only. Non-matches and the rest of SignalIQ's dataset never leave.
  4. 4Repeat at scale. Every consumer runs the same flow independently. No marketer sees another's queries; SignalIQ sees no raw identifiers from anyone.
Example
# Brand B asks (IP from its own traffic)
enrich(203.0.113.7 → intent?)
# answer, for a record it already holds
in-market: auto-insurance · hot
    Stays home
  • SignalIQ's full IP → intent dataset
  • Each marketer's traffic / email list
    • Crosses the wire
  • Blinded queries → provider
  • Enrichment for matched records only
  • One metering token per query
Why 1:many. This is the data-as-a-service shape — a fraud blocklist queried by thousands of merchants, an email/IP enrichment API, a suppression list everyone checks against. Because IPs are an enumerable keyspace, this endpoint runs in OPRF mode with rate-limiting so no consumer can sweep the dataset. It's also where the metering pipe earns its keep: per-query billing, settled through minted tokens, with the operator never in the data path.
TOPOLOGY · many : 1
Many contributors feed one aggregator

A retail-media audience co-op.

Independent retailers pool a high-value-shopper signal into one shared audience — without any retailer exposing its customer list to the others or to the aggregator.

The setup. Four mid-size retailers each know their repeat, high-LTV buyers. None is big enough to interest a national ad platform alone, and none will share its customer file with a competitor. They want a combined “premium shopper” audience an advertiser can target — built so the co-op aggregator never holds anyone's raw list, and no retailer learns another's customers.

Retailer 1 Retailer 2 Retailer 3 Retailer 4 contribute blinded signals Shopper co-op combined audience aggregator endpoint advertiser queries this →
  1. 1Each retailer contributes blind. Every retailer blinds its high-LTV customer identifiers locally and contributes only tokens to the co-op — raw lists stay on-prem.
  2. 2The co-op builds a combined set. The aggregator unions the contributed tokens into one “premium shopper” membership set. It holds tokens, never a name or an email.
  3. 3An advertiser queries the co-op. A brand checks its own prospect list against the co-op audience — membership answers come back for its records only.
  4. 4Everyone's covered. No retailer sees another's customers, the aggregator never holds raw PII, and contribution/usage is metered for revenue share.
Example
# advertiser asks
member(my_prospects, premium_shoppers)?
# answer, per prospect it already holds
2,184 of 50,000 are premium shoppers
    Stays home
  • Every retailer's customer list
  • The advertiser's prospect list
    • Crosses the wire
  • Blinded contributions → co-op
  • Membership answers, scoped to the asker
  • Metered for contribution & usage
Why many:1. This is the co-op / network shape — many parties pool a signal that's only valuable in aggregate, queried through one endpoint. Same primitive as a fraud co-op (many merchants contribute bad actors) or federated research (many hospitals feed one cohort query). The aggregator is a coordinator and trust badge, never a data honeypot.
Same primitive, three shapes

Side by side.

TopologyMarketing exampleWho holds dataWhat the asker learnsWhere the money is
1 : 1 Two brands measure & activate audience overlap Both parties, symmetric Size of overlap + the matched segment License / per-deal
1 : many One provider sells enrichment to many marketers Provider holds the signal; consumers hold queries Signal for records it already has Per-query metering
many : 1 Retailers pool a premium-shopper audience co-op Many contributors; aggregator holds only tokens Membership in the combined set Contribution + usage revenue share
The generalization. These aren't three products — they're one primitive (parties contribute, parties query) wired three ways. Compose them and you get the full co-op / network. See the full protocol for exactly what gets computed at each step.
Early access

Pick a shape. Run a pilot.

Start with one vertical and one topology — overlap, enrichment, or a co-op — and prove the no-pool guarantee on your own data.

Request early access Read the protocol