Overlap and consent in Fanspine. Activation with the tools a club already has.

Fanspine decides what may leave and proves why. It does not need to own the pipe. A warehouse-native activation tool reads the released audiences straight from the database and carries them to the destinations the club or its sponsor already uses. Synthetic data, labelled as such.

Released audiences the activation tool can see right now

Reading the sync schema…

How it is wired

1The Studio releases an audience. Consent checked by purpose, rights checked for third parties, small groups withheld, every run logged.
2The released set appears in a read-only schema. The activation tool's login can see those views and nothing else. Not the fan table, not the consent ledger, not the identity keys.
3The tool syncs the hashed identifiers on a schedule. Its own sync log records the delivery. The Studio logs the release; the tool logs the carry.
4A withdrawn consent shrinks the next sync. The view changes, the next run carries the smaller set. There is no copy to chase.

What this proves

A property that already owns a warehouse adds the multi-party consent and rights layer with no change to its activation setup.
The integration cost on the tool's side is zero. There is nothing to build there.
A club or league can release a consented, rights-checked sponsor audience with proof, without pooling records between clubs.

Export by purpose →The federated clean room →Evaluation checks →

Shown with a synthetic club. The activation tool in the demonstration is one warehouse-native product; the same schema works for any tool that reads Postgres.