PLATFORM
04 stages
PSEUDONYMOUS AUDIENCE INTELLIGENCE · PRE-LAUNCH DESIGN
Recognize a cohort across the open web — without recognizing the person.
BingBong plans to issue randomized opaque tokens to participating surfaces. Advertisers see a stable, pseudonymized audience. Publishers retain control. Identity and event data are kept separate by design. Privacy boundaries are explicit. Singling-out and reidentification remain live risks that require controls, not promises.
01 · OPERATING POSITION
What BingBong is — and is not.
IS
Pseudonymization, not anonymization. Randomized opaque tokens issued to participating surfaces; no direct identifiers leave the boundary.
IS
Separation by design. Identity-bound and event-bound data live in distinct domains. Buyer outputs are cohort-shaped.
TARGET
Auditable cohort construction. Cohort thresholds, query budgets, and access logs are design targets pending engineering work.
NOT YET
Certification, patents, deployed scale, named customers, audited performance. These are prohibited until evidence exists.
02 · PRODUCT MODEL
A four-stage signal path.
BingBong routes a token from a participating surface through a privacy boundary, and returns cohort-shaped output to a buyer who never sees a person.
01
PARTICIPATING SURFACE
Token requested
Publisher or app requests a token via a documented surface. A randomized opaque token is returned, scoped to surface and key rotation.
02
PRIVACY BOUNDARY
Events ingested
Events are ingested under the token only. Identity-bound material (raw IP, full UA, identifiers) is filtered or routed to a separate domain.
03
AGGREGATION
Cohort constructed
Tokens are bucketed under cohort definitions with minimum-count thresholds and query-budget controls. Singling-out is treated as a design failure.
04
BUYER OUTPUT
Contract delivered
Buyers receive cohort-shaped aggregates with provenance, retention, and revocation metadata. No raw events, no direct identifiers, no per-user lookups.
03 · TRUST RAIL
Properties we are willing to ship behind.
PROPERTY
Randomized opaque tokens
Tokens carry no structural relationship to identifiers; rotation is scheduled; revocation is supported on request.
PROPERTY
Identity / event separation
Identity-bound inputs and event-bound inputs live in different domains; cross-domain joins are a controlled operation.
PROPERTY
Cohort-shaped output
Buyers see aggregates, not rows. k-anonymity-style thresholds, query budgets, and suppression are design targets.
PROPERTY
Honest residual risk
Reidentification and singling-out remain live risks. They are surfaced in governance and methodology, not hidden.
04 · BUYER PATH
For advertisers, analysts, and measurement teams.
Stable pseudonymous reach across participating surfaces, with a documented output contract and a prohibited-uses list. Request access is gated until pre-launch controls are operational.
05 · PUBLISHER PATH
For publishers and data partners.
Integrate at the edge without surrendering first-party control. Documented consent obligations, minimum cohort thresholds, and quality controls.
06 · ARCHITECTURE
Where the boundary sits.
A short view of the planned topology. See docs/ARCHITECTURE.html for the full self-contained diagram.
07 · PRIVACY BOUNDARY
The boundary is a designed artifact, not a posture.
Privacy is treated as a separable domain with explicit ingress, egress, and joining rules. The boundary is the smallest unit the operator agrees to defend under audit.
INGRESS
Token-gated
Inputs enter via opaque tokens issued by a documented surface. Identity-bound fields are filtered or routed to a separate identity domain.
INTERIOR
Separated domains
Identity and event data do not co-reside. Cross-domain joins are a privileged operation, logged and budgeted.
EGRESS
Cohort-shaped
Outbound contracts emit aggregates with provenance, retention, and revocation metadata. Raw events and per-user rows do not exit.
08 · NEXT STEPS
Read the receipts.
DOCS
09 artifacts
CLAIMS
00 unproven
STATUS
pre launch