Use Case 9: Data sharing & monetization

Share data with strong privacy protection.

Use this use case when data must be made available beyond the original production boundary. Approvals by privacy officers or boards may be needed.

What problem this use case solves

Teams need to make data available to other consumers. They need strong privacy protection with measurable quality.

Classic anonymization can leak secondary identifiers. It can also reduce utility through broad generalization.

When to choose this use case

Pick this when data leaves your team or organization.

If you’re unsure, start with Synthesize all, avoid Consistent mapping, and run the QA report before each release.

• You share data with partners, vendors, or customers.

• You need sign-off and a clear privacy posture.

• You need privacy and utility evidence per delivery.

• You need low linkability across releases and recipients.

• Avoid stable pseudonyms unless required by contract.

When to avoid this use case

Skip this when the data stays internal.

• You only need internal demo datasets. Use Use Case 3: Demo Data.

• You only need internal training datasets. Use Use Case 12: Training & Education.

• You need stable, refreshable access for internal analysts. Use Use Case 7: Analytics Sandboxes.

• You need reversible mapping back to original records for internal debugging. Prefer de-identification with controlled access and tight auditing.

Recommended Syntho configuration

This setup is optimized for external sharing with strong privacy posture. You minimize linkability. You validate privacy and utility before distribution.

1

Prerequisites

Checklist

• Recipient, purpose, retention period defined.

• Share contract defined (view or extract).

• Approval/evidence requirements defined (QA report, privacy board).

Avoid stable pseudonyms unless contractually required. They increase linkability across releases.

• Use the Prerequisites checklist.

2

Source & destination management

Create one workspace per external consumer or per policy. This prevents accidental reuse of a “less strict” config.

Baseline rules

• Keep the source stable. Prefer snapshots or back-ups.

• Avoid a live production source for iterative work.

• Keep the destination isolated. Never write into production.

• Keep schemas aligned between source, workspace and destination.

• Use views when you need only a subset of the original database.

Lifecycle rule of thumb

• Keep the source connection when you expect schema changes.

• Remove the source connection when you expect a new run only much later.

• Revalidate after schema changes. Use Validate and synchronize workspace.

Nuances for this use case

• Lock down who can change generators. Treat generator changes like a release.

• Prefer “pull once, publish many”. Generate into staging, then distribute from the output.

• Don’t share the same database boundary as production. It blurs governance and access control.

• Don’t reuse a workspace for two recipients. One recipient’s requirements can silently weaken another’s posture.

• Create a workspace

• Share a workspace

3

Configure generators

Workspace initialization mode

Choose a workspace mode. It applies baseline generator suggestions during workspace creation.

Recommended modes for this use case:

• Synthesize all when you want maximum unlinkability and strong statistical utility (best default for external sharing).

• Mock all when you must avoid learning from the source altogether (highest separation, often lower utility).

• De-identify only when the sharing contract explicitly requires production-like multi-table behavior and you can accept higher linkage risk.

AI-generated synthesis

This is typically the best option for external sharing. Use it for strong unlinkability with good statistical utility.

Example (partner dataset as one table): create partner_share_view with only approved columns, then AI synthesize it into a single share table. Apply rare-category protection before delivery.

Rule-based generation

Use this to enforce release policy rules such as bucketing, top-coding, or redaction of sensitive derived fields. Use Calculated columns to encode these policies.

Example (k-anonymity-friendly bucketing): replace age with calculated age_band and replace income with top-coded buckets. This reduces re-identification risk while keeping utility.

// New column: age_band
IFS(
  [age] < 18,  "0-17",
  [age] < 35,  "18-34",
  [age] < 55,  "35-54",
  TRUE,        "55+"
)

// New column: income_bucket (top-coded)
SWITCH(TRUE,
  [income] >= 200000, "200k+",
  [income] >= 100000, "100-199k",
  [income] >= 50000,  "50-99k",
  "0-49k"
)

Masking

Use this only when you must keep format-valid values for consumer systems. Be careful with stable pseudonyms across releases.

Example (format contract without linkability): mask customer_reference to a UUID format without consistent mapping so the same person cannot be linked across deliveries.

Hybrid

Use this when you need synthesis for unlinkability, plus explicit policy constraints. It mirrors the “rare scenario / policy guardrails” mindset from Example data generation scenarios.

Example (synthesize + guardrails):

1. AI synthesize a single “share contract” view (entity table).

2. Add calculated columns for bucketing and top-coding.

3. Use rare category protection and additional privacy controls before release.

One practical guardrail is removing day-level timestamps while keeping time utility:

// New column: event_month (coarsen timestamps for sharing)
CONCATENATE(YEAR([event_date]), "-", MONTH([event_date]))

Then exclude the original event_date from the shared dataset.

Minimal configuration steps

1. Build a share-contract view with approved columns only.

2. Prefer AI synthesize on that view.

3. Add calculated columns for bucketing/top-coding.

4. Run the QA report and capture evidence for release.

• Automatic PII discovery with PII scanner

• Manage personally identifiable information (PII)

Avoid Consistent mapping unless the sharing contract explicitly requires stable pseudonyms.

4

Handle keys and relationships (relational schemas)

If you share a single flattened table (common), you can skip this step.

Only keep multi-table relationships if the consumer truly needs joins. Every join key increases linkage risk.

If you must keep multiple tables, keep join keys consistent and document them. Otherwise, prefer a flattened entity table for sharing.

• Key generators

Single-table sharing is the common path

Many external consumers want one table that is easy to import and understand.

Typical approach:

1. Create a view that represents the shareable dataset (entity table).

2. Use that view as the input to Syntho.

3. Publish the generated output as a single table or file export.

See Use SQL views as input tables.

5

Validate and sync

Run the QA report when available. Treat the QA output as part of your release evidence.

Revalidate on every delivery. A small schema change can reintroduce sensitive fields.

Privacy metrics and approvals (what to document)

Treat sharing like a controlled release. Privacy reviewers typically expect:

• The intended recipient, purpose, and retention period.

• A list of removed/transformed identifiers and any stable pseudonyms used.

• Utility and privacy evidence (QA report where applicable, plus privacy controls used).

• A clear threshold statement (example): “k-anonymity ≥ 10 on {age_band, region, product} after rare category protection”.

If your organization has a privacy board, capture sign-off before distributing the dataset.

Package and distribute (practical)

Make the dataset easier (and safer) to consume:

• Include a short data dictionary (column meaning, units, allowed values).

• Include metadata: refresh date, version, and known limitations.

• Use explicit licensing/usage terms when data leaves your organization.

6

Tune generation settings

Apply Additional privacy controls before shipping. These controls matter more here than runtime.

Tune performance only after privacy posture is accepted. Speed is not the primary constraint for sharing.

Common pitfalls & misconfigurations

Use-case specific pitfalls

• Using consistent mapping for identifiers in external shares.

• Shipping outputs without capturing QA/validation evidence.

• Accidentally leaking indirect identifiers through rare categories.

  • Review rare category protection. See AI synthesize.

General pitfalls

These pitfalls show up in most projects:

• Running full-scale jobs before a small validation run.

• Skipping workspace validation/sync after schema changes. Use Validate and synchronize workspace.

• Breaking relational integrity (missing PK/FK setup, missing foreign keys, missing virtual foreign keys). Start with Manage foreign keys and virtual foreign keys.

• Leaving sensitive columns on Duplicate, or trusting the PII scan without reviewing false positives/negatives.

• Overusing Consistent mapping (it slows down data generation and increases linkability).

Governance, compliance, and automation

Governance, access control, and audit evidence

Keep the workspace configuration as a controlled artifact. Treat it like “test data release”.

Recommended roles

• Workspace Owner: data steward or privacy lead. Approves generator choices and sharing.

• Workspace Editor: data engineer or platform engineer. Implements configuration changes.

• Workspace Reader: testers, analysts, or trainees. Can run jobs but should not change rules.

See Workspace & user management and Share a workspace.

Access control checklist

• Use read-only access to the source database for day-to-day users.

• Restrict who can view source data in the UI. Don’t default to broad access.

• Use a dedicated destination per environment (dev, test, accept, sandbox).

• Keep external recipients in a separate workspace with stricter settings.

Evidence for auditors (lightweight but useful)

Capture these items per delivery or refresh:

• Workspace name, owner, and intended audience.

• PII scan results and the final list of “PII columns + applied generator type”.

• Any enabled privacy controls (e.g., rare category protection, free-text de-identification scope).

• Validation output and/or QA report (when applicable).

• Approval notes (ticket link, privacy board sign-off, or risk acceptance).

Automation and deployment (reference)

You can automate workspace setup, scans, and generation runs via the Syntho REST API.