Data Sourcing Methodology and Provenance
How GSDSI sources, validates, and delivers privacy-safe datasets across identity, location, CTV/ACR, clickstream, property, and consumer/B2B records.
Since 2018
Privacy-safe enterprise data
VOSB & SDVOSB
U.S. Veteran-Owned, Service-Disabled
SCC Transfers
EU/UK/CH per privacy policy
GDPR · CCPA · CPRA
Consent-first data sourcing
The buyer-safe model
GSDSI is built around procurement reality: buyers need documentation, exclusions, and audit-ready lineage, not just “coverage” claims. This page summarizes the methodology and what a buyer can request during evaluation.
Provenance artifacts
- Source category descriptions (public records, licensed partners, consented panels).
- Field-level descriptions and allowable joins.
- Refresh cadence and historical availability.
- Delivery manifests (files, schemas, checksums where applicable).
Compliance posture
- CCPA/CPRA, GDPR readiness, and state-by-state privacy controls.
- Opt-out and deletion request handling via privacy center.
- Sensitive-category exclusions (healthcare, worship, etc.) where applicable.
- FCRA boundary labeling on consumer-report-adjacent products.
Quality controls
- Deduplication and entity resolution checks.
- Coverage and bias evaluation during pilots (match-rate driven).
- Anomaly detection on refresh deltas.
- Schema stability: versioned fields and controlled changes.
Secure delivery
- TLS in transit and encryption at rest (where applicable).
- Delivery via SFTP, S3, Snowflake secure share, or API.
- Access scoping, retention expectations, and deletion SLAs in contract.
- Incident response and change control for enterprise buyers.
Data provenance manifesto (what we mean by “buyer-safe”)
“Provenance” isn’t a marketing word. It’s the chain of custody for a dataset: where it came from, how it was transformed, what was excluded, and what a buyer is allowed to do with it. If any of those are ambiguous, procurement risk goes up and the pilot becomes hard to defend internally.
1) Source transparency
Buyers can request source-category descriptions (not partner names) and consent posture by feed so legal and privacy teams can evaluate fit without guesswork.
2) Exclusions by design
Sensitive-category exclusions and permitted-use boundaries should be explicit and enforced in the pipeline, not left to downstream consumers to “do the right thing.”
3) Evaluation is measurement
The pilot should be a matched sample with a success metric (match rate, lift, coverage, precision/recall). Demos don’t predict outcomes.
What a provenance brief includes
When you request a provenance brief, we tailor it to the feed(s) you’re evaluating and the intended use case. Typical sections:
- Dataset summary: coverage, refresh cadence, delivery formats, and join keys.
- Source categories + consent posture (high-level; no partner disclosure).
- Exclusions, permitted-use boundaries, and governance expectations.
- Pilot plan: matched sample size, success metric, and timeline.
Where to go next
- Products catalog. See delivery formats and refresh cadence by feed.
- Identity graph. MAID→HEM use cases and buyer evaluation model.
- FTC enforcement buyer guide for what “privacy-safe” means post-consent-orders.
- Data glossary for MAID, POI, ACR, and pilot terminology.
- Contact to request a pilot and provenance documentation pack.
- Vendor comparisons to run a clean procurement bake-off with explicit evaluation criteria.