Data-broker intelligence field model for unbroker-style runs: exposure found, people-search yield, parent clusters, CCPA/GDPR/DROP opt-outs, forced disclosure, friction, re-listing, re-scan truth, and tool coverage.
What Data Broker Removal Runs Should Teach Cunicula
A removal run should not only produce a report for one person. It should teach Cunicula how the broker market behaves: who exposes what, which routes work, what fields are demanded, what blocks automation, and what comes back after a re-scan.
The person's dossier is not the reusable asset. It is sensitive input for one authorized run. The reusable asset is broker intelligence with the person removed from it.
The fields
| Field | Question | Why it matters | Public boundary |
|---|---|---|---|
| Broker exposure found | Which brokers actually expose a person? | Separates high-value removal targets from sites that do not currently expose the subject. | aggregate-only |
| Exposure yield | Which sites are high-yield for addresses, phones, relatives, emails, or prior locations? | Ranks brokers by practical harm, not by brand awareness. | aggregate-only |
| Parent cluster | Which brokers are wrappers, affiliates, or child brands of a parent company? | A single parent action can clear multiple broker shells and reduce wasted work. | public-broker-fact |
| Parent opt-out coverage | Which parent opt-outs clear many child sites? | Finds the highest-leverage removal actions. | aggregate-or-source-backed |
| Removal path | Which opt-out path works: form, email, CCPA, GDPR, DROP, suppression, deletion, or manual task? | Turns vague advice into an ordered workflow. | public-broker-fact |
| Required disclosure fields | Which fields does each broker force the subject to disclose? | Measures the privacy cost of removal. | public-broker-fact |
| Re-listing behavior | Which brokers re-list people after removal? | Shows which removals need recurring monitoring. | aggregate-only |
| Friction mode | Which brokers use hard CAPTCHA, phone callback, ID request, fax, or hostile loops? | Defines the human fallback queue and keeps automation honest. | public-broker-fact |
| Removal latency | How long do removals take? | Sets expectations and flags brokers that delay or ignore requests. | aggregate-only |
| Re-scan truth | Which removed claims survive a later re-scan? | Separates real removal from cosmetic success messages. | aggregate-only |
| Harm category | Which broker categories are most dangerous for doxxing, stalking, spam, scams, or identity theft? | Prioritizes removals by user risk instead of alphabetical lists. | aggregate-or-source-backed |
| Jurisdiction leverage | Which states or jurisdictions give the strongest deletion path? | Routes the subject through the strongest available legal mechanism. | public-law-fact |
| Removal tool coverage | Which removal services or tools cover the important brokers? | Lets Cunicula compare unbroker, paid services, manual cleanup, and search-result removal honestly. | public-or-consented |
| Source confidence | How was this broker fact learned? | Keeps official sources, observed runs, screenshots, and guesses separate. | public-broker-fact |
How this becomes education
These fields turn data-broker cleanup into a teachable model:
- Exposure found tells people where the risk is real.
- Exposure yield explains which sites leak addresses, relatives, phones, emails, and old locations.
- Parent clusters show why one request can matter more than ten small opt-outs.
- Required disclosure fields show the privacy cost of removal.
- Friction mode shows where automation should stop and a person should review the task.
- Re-scan truth shows which "removed" claims actually hold.
- Jurisdiction leverage shows when DROP, CCPA, GDPR, or a general request is the better path.
API field set
The field taxonomy is available for tooling and buyer diligence at /api/v1/data-broker-intelligence/fields. That endpoint is not a broker-results feed. It is the measurement contract for future researched rows and consented run receipts.
Next data product
The next useful dataset is not a list of people. It is a broker effectiveness table:
- broker name and parent cluster,
- exposure categories,
- working removal route,
- required disclosure fields,
- automation or human fallback tier,
- time to removal,
- re-scan result,
- source confidence and review date.
Read the broader lane note at Data Broker Exposure Is the Privacy Work Queue, or the practical guide at How to Self-Host unbroker.
Frequently Asked Questions
What should Cunicula measure about data brokers?
Cunicula should measure exposure found, exposure yield, parent clusters, parent opt-out coverage, removal paths, required disclosure fields, re-listing, friction, latency, re-scan truth, harm categories, jurisdiction leverage, tool coverage, and source confidence.
Is the valuable data the person dossier?
No. The subject dossier is sensitive run input. The reusable value is non-identifying broker intelligence: what exposed data, what removal route worked, what blocked, what came back, and how strong the evidence is.