Data Governance, Contracts, and Classification Questions

Direct answer. Treat personalization value and privacy risk as two things to optimize jointly, not a single dial to set. Start from the minimum data footprint the feature actually needs (data minimization), lean on aggregation wherever a session- or cohort-level signal captures most of the personalization lift, and make participation explicit through opt-in or opt-out design rather than defaulting to invisible collection. Then bring product and legal the same evidence, not two separate stories tailored to what each wants to hear.

Data minimization. Before building anything, list the specific fields the personalization model actually needs and drop everything else from the pipeline that feeds it, even if it's "free" to collect because it already flows through other systems. A model predicting interest from recent category views doesn't need full purchase history, billing address, or a device fingerprint; each field it doesn't touch is a field that can't leak, doesn't need its own retention policy, and doesn't need separate consent language.

Aggregation. Where a signal can be computed at a cohort or session level instead of tied to a persistent individual profile ("users who viewed this category in the last hour" instead of "this person's full viewing history"), prefer the aggregated version. It trades some precision for materially lower privacy risk and a smaller footprint to secure and retain.

Opt-in versus opt-out. This isn't just a legal checkbox; it changes both the ethics and the achievable personalization ceiling. Opt-in (the user must actively agree before data is used) yields a smaller, more privacy-comfortable population but a strong consent record. Opt-out (data used by default until disabled) yields broader coverage and stronger initial model performance but carries more legal and reputational exposure. In many jurisdictions, certain data categories (health, precise location, biometric) require opt-in as a matter of law regardless of product preference, so the choice isn't purely a design decision, it has a legal floor.

Presenting the trade-off honestly to product and legal

• Bring one shared document, not two: state the personalization lift you can defend for each data tier, and let both audiences see the same numbers rather than a rosier version for product and a more conservative one for legal.
• Make the risk side concrete: name the specific regulatory exposure and the reputational pattern, not just "privacy risk" as an abstraction.
• Make the value side falsifiable: propose validating the lift claim with an actual limited experiment (a minimized version against a fuller version, on a subset of users, under whatever consent basis is available) rather than asserting it from intuition, so the decision rests on evidence both sides can inspect.

Worked example (illustrative, not a measured result). Suppose an offline evaluation compares a cohort-level model against an individual-purchase-history model on the same held-out set, and the individual-level model's click-through rate on the top recommendation slot rises from a baseline of 4.0% to 4.6%. That is a 0.6 percentage-point lift, or 4.6/4.0 = 1.15, a 15% relative lift. That relative-lift figure is what product can advocate for. Legal's response isn't "no," it's "at what data tier, under what consent basis, and is a 15% relative lift worth expanding every user's default data footprint from cohort-level to full purchase history." The honest presentation puts the 15% figure and the specific new risk categories side by side for both stakeholders to weigh, rather than the analyst quietly picking a side.

Trade-offs and pitfalls

• The common failure mode is showing product the best-case lift and legal the worst-case risk separately, which trains both sides to distrust the analysis; use the same numbers with both audiences.
• Data minimization isn't free either: a smaller feature set can mean a materially worse cold-start experience for new users, so "less data" has a real product cost, not just a privacy benefit.
• An opt-out default that's technically legal in one jurisdiction can still be reputationally costly if users feel surprised by what's personalizing their experience; legal and acceptable-to-users are not the same bar.

A data contract is an explicit, versioned agreement between the team that produces a dataset or event stream and the teams that consume it, specifying what the data looks like and how it is allowed to change, so consumers can build on it without watching the producer's code. It moves the schema from an implicit "whatever the table currently contains" to a documented interface, the same way an API contract does for a service boundary.

What a data contract specifies

• Schema: the field names, types, nullability, and structure of the dataset or event.
• Semantics: what each field actually means (for example, is amount pre-tax or post-tax, is user_id internal or external).
• Freshness or SLA (service-level agreement): how often new data lands and by when (for example, "table refreshed daily by 6am UTC" or "event latency at the 95th percentile under 5 minutes").
• Ownership: who to contact, who approves changes, who gets paged if it breaks.
• Compatibility rules: what kind of changes are allowed without notice (adding an optional field) versus what requires a migration (renaming or removing a field, changing a type).

Where this shows up for ML features specifically

When the "dataset" is a feature powering a model, the contract checklist picks up a few ML-specific fields on top of the general ones: the feature's computation logic (so training and serving compute it identically), a point-in-time correctness guarantee (no leakage of future data into a training example), a PII (personally identifiable information) or sensitivity flag, and an owner responsible for backfills when the definition changes. Feature stores often store these as machine-readable metadata alongside the feature itself.

Why teams benefit, even from an informal one

Without any contract, consumers reverse-engineer the current shape of a table or event and build against it implicitly; the producer has no idea who is downstream, so a "harmless" rename breaks three pipelines nobody warned. A contract, even a one-page document naming the fields, semantics, freshness, and an owner, converts that into an explicit interface: the producer knows who to notify before a change, consumers know what they can safely rely on, and disputes over "was this expected" get resolved by pointing at a written agreement instead of chat-history archaeology. Contracts also make governance easier, because who owns which sensitive field is written down rather than tribal knowledge.

How this actually gets adopted across teams

A contract that lives only in a wiki page decays quickly. What makes it stick is treating it as an artifact next to the code: check it into the same repository as the producing pipeline, version it, and, once the culture is ready, turn its compatibility rules into an automated CI (continuous integration) check on the producer's build so a breaking change fails the build instead of failing in a downstream dashboard three weeks later. Cross-team adoption grows from a few high-traffic, high-incident datasets first, not a company-wide mandate on day one.

Worked example

A orders.order_placed event contract might read:

event: orders.order_placed
owner: checkout-team (#checkout-eng)
schema:
  order_id: string (required)
  user_id: string (required)
  amount_cents: integer (required)   # semantics: total charged, in cents, post-discount, pre-tax
  currency: string (required, ISO 4217 code)
  placed_at: timestamp (required, UTC)
freshness: emitted within 2 seconds of order placement (95th percentile)
compatibility: backward-compatible only; new fields must be optional; no field renames or type changes without a version bump

A downstream fraud-scoring pipeline reads amount_cents and currency from this contract. If checkout later wants to add a discount_cents field, the compatibility rule says that is fine as an optional addition, but changing amount_cents to represent a pre-tax amount would violate the stated semantics and requires a notified migration, not a silent change.

Trade-offs and pitfalls

Writing and maintaining a contract has real overhead, and for a low-traffic, single-consumer dataset a full formal contract can be more process than the risk warrants; an informal one (a short document with an owner and the five elements above) captures most of the value at a fraction of the cost. The common pitfall is writing the document once and never enforcing it: a contract nobody checks against reality is worse than none, because consumers trust it and get burned when the real data has drifted from what is written. The fix is pairing the contract with even a lightweight CI check, not just a policy page.

At an organization level this becomes a lightweight approval pipeline attached to the normal dataset or event creation path: a producer registers a new dataset or event through a template that captures the schema and the contract fields (owner, freshness, compatibility mode), a small number of automatic checks gate any subsequent change, a named reviewer signs off on registration, and an explicit, rehearsed rollback path exists for the change that gets through anyway.

Registering and reviewing a new dataset or event

New datasets or events go through a registration template, either a PR (pull request) against a schema or contract repository, or a form wired into the catalog, that requires: a subject name following a naming convention (for example <domain>.<entity>.<verb> for events, so payments.charge.created rather than chargeCreatedPayments), the schema itself, the contract fields (semantics, freshness, owner, compatibility mode), and a link to the owning team. Review is done by a designated data-platform or governance reviewer, ideally a rotating role rather than a standing committee so it does not become a bottleneck, checking mainly for naming-convention compliance, whether the compatibility mode fits the use case, and whether a "new" dataset should instead extend an existing one.

Automatic CI (continuous integration) checks on a proposed schema change

Once registered, every subsequent change to that subject runs through CI automatically, not a person re-reviewing by hand each time:

• A compatibility check against the registry, in the subject's configured mode.
• A naming and lint check confirming the subject still matches convention.
• A contract-metadata check confirming required fields, like owner and freshness, are still present and not silently dropped.
  Failing any of these blocks the merge; passing all of them does not require additional human sign-off, which is what keeps day-to-day evolution fast.

Who signs off

Two tiers apply. Routine, compatible changes are self-served: the CI checks above are the sign-off. A change CI flags as breaking, or a request to relax the compatibility mode itself, requires explicit approval from the consuming teams' representatives, or from a data-governance owner if consumers cannot be enumerated cleanly, before it can merge. This is where the organization-level process differs from a single-team contract, because "the producer decides" does not scale once a dataset has consumers the producer does not know personally.

Onboarding governance for ML features specifically

Feature-store-backed features follow the same registration and CI path, plus one extra gate: a feature cannot go live for online serving until its point-in-time-correctness and training-serving-parity checks pass, since a contract violation here causes silent model degradation rather than a loud pipeline failure. The producing ML team owns the feature contract the same way a data-engineering team owns a table contract.

Rollback path when an incompatible change slips through

Two failure shapes to plan for: a change that violated the contract but CI missed it, whether from a gap in the check or someone bypassing CI, and a change that was compatible on paper (the type stayed the same) but broke a downstream consumer semantically. For both, the rollback path is: revert the producer's change to the last known-good schema version recorded in the registry, which is a pointer flip and redeploy rather than a from-scratch fix, notify affected consumers immediately with what broke and when it is fixed, and run a postmortem that specifically asks whether a new CI check would have caught it, feeding back into the checklist above so the same gap does not recur.

flowchart TD
  A[Producer: register new dataset/event] --> B{Naming + contract fields present?}
  B -->|No| C[Reviewer requests changes]
  B -->|Yes| D[Registered in catalog/registry]
  D --> E[Producer proposes schema change]
  E --> F{CI: compatibility + naming + metadata checks}
  F -->|Fail| G[Build blocked]
  F -->|Pass, compatible| H[Auto-merged]
  F -->|Flagged breaking| I[Consumer/governance sign-off required]
  I -->|Approved| H
  I -->|Denied| G
  H --> J[Deployed]
  J -->|Incident: incompatible change slipped through| K[Revert to last registered good version]
  K --> L[Notify affected consumers]
  L --> M[Postmortem: add missing CI check]

Worked example

A new event inventory.stock.updated is proposed by the warehouse team, with schema fields sku, location_id, quantity, and updated_at, owner, near-real-time freshness, and BACKWARD compatibility mode, following the naming convention. The reviewer approves within a day since it does not duplicate an existing event. Months later, a PR renaming quantity to quantity_on_hand fails the CI compatibility check, since there is no alias, and is auto-blocked. A separate PR that adds an optional quantity_reserved field passes all three checks and merges without human review. Later still, a change that widens quantity's type from a 32-bit to a 64-bit integer passes the compatibility checker, since type widening is backward compatible under the registry's rules, but breaks a downstream reporting job that had hardcoded a 32-bit column type in its warehouse loader. That is the "compatible on paper, broke a consumer" case: the fix is to revert the producer's type, notify the reporting team, and add a new CI check that flags any type-widening change for a lightweight consumer heads-up, even when the registry itself allows it.

Trade-offs and pitfalls

A committee-review model that requires sign-off on every schema change does not scale past a handful of teams, since weeks-long review queues push people to route around it; the tiered model above trades some rigor for throughput by only pulling humans in for flagged breaking changes. The main pitfall is a registration template that is easy to skip: if creating a new dataset without registering it is not meaningfully harder than registering it properly, teams will skip it under deadline pressure, and the whole process only covers datasets that opted in.

Direct answer. In a two-sided marketplace, the two sides usually need different retention granularity because they carry different kinds of ongoing risk and different decision horizons. The side with recurring dispute, fraud, or pricing and trust exposure, often the supply side (hosts or sellers), typically needs longer event-level history because its behavior over time affects platform trust and pricing. The side whose primary value is statistical, often the demand side (guests or buyers), can usually move to aggregates sooner without losing what the business actually uses.

Historical granularity by side

• Supply side: event-level history is often load-bearing for longer because it feeds trust and safety decisions, dispute history, cancellation patterns, fraud signals, that can resurface months or years after the fact, and because pricing or ranking models often depend on a seller's full track record, not just recent aggregates.
• Demand side: individual booking or browsing history is mostly useful in the short term, for the current session's recommendations, recent support tickets, near-term fraud checks. Past that window, what the business actually queries is aggregate demand patterns (conversion by cohort, seasonality, funnel drop-off), not a specific buyer's exact click from years earlier.

Where raw history is genuinely load-bearing versus where aggregates suffice

• Genuinely load-bearing: active disputes and their evidentiary trail, fraud investigations, a seller's or host's historical performance record used in ranking or trust scoring, and any regulatory recordkeeping obligation tied to a transaction.
• Aggregates suffice: demand forecasting, seasonality analysis, marketing funnel analytics, and most executive reporting, none of which need to resolve to an individual buyer's specific historical action once the near-term window has passed.

Deciding the actual windows. Tie each retention window to the specific use case that justifies it rather than a blanket policy: dispute-resolution windows follow the platform's own dispute policy, regulatory transaction-record retention follows the applicable rule for the jurisdiction, and everything else defaults to the shorter "how long does this drive an actual decision" window, moving to aggregates once that decision window has passed.

Worked example (illustrative, reasoning shown rather than asserting specific day counts as measured facts). Suppose a marketplace's dispute policy allows a claim to be raised within 90 days of a completed transaction, and the applicable financial recordkeeping rule requires transaction records stay retrievable for a longer, multi-year period. That gives two independent floors on raw-transaction retention: a 90-day dispute window, short, that justifies hot storage, and a multi-year regulatory floor, long, that only requires retrievability, not fast querying, so the data can move to cold storage once the 90-day window closes. Browsing or click events on the demand side that don't feed a dispute or a regulatory record have no such floor and can roll up to aggregate funnel metrics after a much shorter window, since no downstream system needs the exact click years later.

Trade-offs and pitfalls

• The common wrong turn is applying one retention policy across both sides because it's operationally simpler, which either over-retains low-risk demand-side click data or under-retains supply-side history that trust and safety actually needs later.
• Aggregating too early on the supply side can quietly break a fraud or trust model that depended on granular patterns, like timing between actions, that don't survive being rolled up to daily counts; check what those models actually consume before deciding a side is safe to aggregate.
• Treating a regulatory retention floor as requiring hot-storage duration for its full length is a common cost mistake; "must be retrievable" and "must be in the fast queryable warehouse" are different requirements, and cold storage usually satisfies the former at a fraction of the cost.