Data minimization for MCP product analytics

Start with the smallest useful product-event record

For MCP product analytics, begin with a named action and only the dimensions needed to answer a defined product question. OfflineCreator Studio's current privacy policy describes first-party events such as page views, generation starts or failures, and checkout starts. It says those events may be associated with an account or an anonymous browser identifier and may include campaign parameters and a referral code. That published inventory supports measuring a funnel; it does not make prompts, uploads, generated media, or arbitrary tool arguments analytics fields.

For this review, require a written purpose for every proposed field before collection. Approve event names and bounded workflow or model enums only for documented questions. Require a separate necessity decision before allowing a generation identifier to join records. Treat every free-text value as unapproved unless a reviewer demonstrates why a controlled value cannot answer the question. Use an explicit event and property allowlist as the review standard, and reject an open-ended analytics object.

Keep

Bounded event names and necessary enumsTie every accepted field to a documented metric, owner, and retention decision.

Question

Account, anonymous, and generation identifiersUse an identifier only when the analysis cannot be completed with a less linkable value.

Exclude by default

Prompts, media, secrets, signed URLs, and free textDo not depend on downstream cleanup to remove data that the event never needed.

Separate first-party events from consented Google Analytics

OfflineCreator's public notices describe two analytics paths with different boundaries. First-party product events go to Studio's own servers and are associated with an account or anonymous identifier. Google Analytics 4 loads only after explicit opt-in consent and receives measurements such as pages viewed, sign-ups, generations, and purchases. The Cookie Notice says declining or ignoring the banner prevents Google Analytics from loading, and the privacy policy says advertising features remain disabled.

Do not merge those paths in a review. A field accepted by a first-party route is not automatically suitable for Google. OfflineCreator says it does not send prompts, uploads, generated media, email addresses, or other free-text content to Google. Google separately warns customers not to send personally identifiable information and calls out URLs, page titles, form input, campaign dimensions, and event dimensions as places where it can leak. Consent controls whether the third-party path runs; payload minimization still determines what a consented event may contain.

First-party path

Studio product eventsReview the Studio event schema, identifier use, access, and retention.

Third-party path

Google Analytics 4 after opt-inApply the consent gate and a separate, narrower outbound property map.

Do not assume

Consent makes sensitive fields appropriateA consented measurement still needs a minimized payload.

Keep MCP generation content outside the analytics envelope

The privacy policy applies to the web app, public API, MCP server, and CLI. It classifies prompts, source images, selected settings, and generated outputs as generation content, while its analytics section describes product events and identifiers separately. Use that separation as the review boundary: MCP tool arguments and results belong to the generation dataflow, not to an analytics event merely because a tool invocation produced the event.

At each MCP caller, construct a fresh analytics payload from approved values instead of spreading a request object, tool arguments, provider response, or error object into properties. Record a stable failure category rather than the exception message when the message can contain provider text or request material. Record that an output was downloaded rather than the signed download URL. Record the selected workflow as a controlled value rather than copying a prompt or filename. These choices preserve useful conversion and reliability signals without creating a second store for generation content.

Tool input

Do not copy into analyticsMap only the approved event name, enum, and identifier fields.

Provider failure

Use a bounded categoryKeep raw provider messages in the appropriate operational path, not the product-event payload.

Media delivery

Track the action, not the URLA download event does not need a signed media address.

Review every caller and the event route as one dataflow

Do not end the review at a route-level event-name enum. Inventory every browser, server, webhook, MCP, and CLI caller that can emit or enrich an event. For each caller, record the event name, possible properties, identifier source, consent dependency, and destination. Then compare that inventory with the event route's accepted schema and the database columns it writes. Produce a field-level matrix that shows where each value originates and whether an unreviewed property can cross the route.

Test the boundary with payloads designed to fail safely: an unknown event name, an overlong identifier, an unexpected property key, nested free text, a prompt-like string, a signed-URL-shaped string, and a provider error containing credentials. Confirm rejection or removal before persistence and before any Google mapping. Also verify the anonymous path and signed-in path independently. OfflineCreator's notices say first-party events can use either an account or anonymous browser identifier, so reviewers should not assume that signing out eliminates event linkage.

Caller inventory

Name every event producerInclude client components, server callbacks, webhooks, MCP adapters, and CLI paths.

Route contract

Allowlist names, types, lengths, and keysReject unknown structure before adding identity or writing an event.

Destination map

Separate first-party storage from GoogleProve which fields can reach each destination under each consent state.

Treat flexible properties and URLs as high-risk failure modes

Review a flexible properties bag as a high-risk expansion point even when its initial fields appear harmless. Do not approve type validation alone when arbitrary keys or nested values can pass. Require per-event property schemas, rejection of unknown keys, length caps, and controlled values. Before mapping a first-party event to Google Analytics, require a smaller destination-specific projection instead of forwarding the complete first-party record.

URLs deserve explicit tests because they can hide data in paths, queries, and fragments. Google says its basic tag collects page URLs and titles and warns that campaign and event dimensions can carry personally identifiable information. Normalize analytics paths to stable route templates where possible, strip unneeded query parameters and fragments, and never place signed media links in event fields. Redaction can reduce accidents, but an allowlist gives the reviewer a finite contract to verify.

Bad pattern

properties: arbitrary objectA broad container lets future callers expand collection without changing the route contract.

Better pattern

Per-event property schemaUnknown keys fail closed and destination mappings select only necessary fields.

URL rule

Use stable route templatesRemove query values, fragments, tokens, and signed delivery parameters.

Continue the privacy review at the adjacent boundaries

Analytics minimization does not replace audit-log review, provider-retention review, or secret redaction. Use the security directory to keep those controls separate, then verify that an analytics event cannot become an accidental copy of a prompt, media address, provider response, or credential.

Evidence boundary and open verification work

The current public Privacy Policy and Cookie Notice establish the disclosed analytics categories, identifier choices, first-party and Google destinations, consent condition, and excluded content for Google. They do not publish a field-by-field event-route schema, a complete caller inventory, first-party analytics-event retention period, database access matrix, deletion behavior, or a deployed test trace. Those implementation facts remain release-bound verification work rather than public promises in this draft.

No recent community anecdote is used to infer adoption, prevalence, privacy performance, or customer outcomes. Before editorial review, capture externally reviewable implementation evidence or a controlled test record for the event route and representative MCP callers. Keep the page in draft if that evidence cannot be produced, and do not turn a recommended minimization design into a claim about the deployed service.