> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bily.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Privacy and governance

> Keep event data minimal, identities distinct, credentials private, and production changes reviewable.

Treat your Bily implementation as a living data contract. Product, engineering, privacy, and operations should agree on what you collect, why you need it, who can access it, and how changes reach production.

## Give every event clear ownership

For each event, name:

* a product owner for the business meaning;
* an engineering owner for the trigger and payload;
* a privacy owner for customer-data classification and consent requirements;
* a verification owner for staging and production checks.

Clear ownership keeps an event from outliving its meaning or source.

## Know what every field contains

Use a simple classification in your event catalog.

| Class                        | Examples                                             | Handling                                           |
| ---------------------------- | ---------------------------------------------------- | -------------------------------------------------- |
| Public product context       | route name, product ID, feature name                 | Send when needed                                   |
| Internal operational context | safe status code, release version                    | Review and limit                                   |
| Customer data                | user ID, email, phone, address                       | Purpose, permission, and retention review required |
| Secret or restricted content | passwords, tokens, payment details, private messages | Never send in browser events                       |

The person using the browser—and software running on the page—can see browser events. An event payload is never secret storage.

## Send the least customer data you need

Choose the smallest stable identifier that supports the analysis.

```typescript theme={null}
track("user_signed_in", {
  client: {
    userId: "user_123",
    userGroup: "growth",
  },
});
```

Add email, phone, address, date of birth, or gender only for a documented purpose and permitted consent state. Never copy an entire application user object into `client` or custom properties.

## Let your application enforce consent

The SDK accepts the events your application sends. Before calling `track()`, your application must decide whether the event and each customer field are permitted.

Test these states:

* consent not yet selected;
* optional tracking accepted;
* optional tracking denied;
* consent changed after page load;
* signed-out and signed-in states.

When consent changes, stop sending fields that are no longer permitted. Keep your event catalog and customer-facing privacy notice aligned.

## Keep identity separate from authorization

The Bily browser tracking ID is not an authenticated account ID and must never authorize a request. `client.userId` adds customer context to an event. It does not prove a live session.

Authorize protected actions with:

* your verified application session;
* a Bily API key kept in server-side secret storage; or
* Bily Connect or a fallback key in a compatible MCP client.

## Limit API and MCP access

* Use one server credential per workload and environment.
* Give credentials descriptive names and an expiration.
* Store API keys only in secret-aware server or client configuration.
* Review organization and store scope before production use.
* Keep MCP client approval visible for `execute`.
* Verify writes with a read and preserve request IDs.
* Revoke a credential immediately if exposure is possible.

MCP risk and approval metadata helps a client plan. It is advisory and does not prove that a human reviewed an action.

## Review every custom property

Custom properties are flexible. Review them carefully.

Reject any property that can contain:

* raw error objects or stack traces;
* request or response bodies;
* unredacted form input;
* arbitrary document or message content;
* authorization values;
* complete URLs with sensitive query parameters.

Map internal errors to a small, safe vocabulary before you track them.

## Review every production change

Require review when a change:

* adds an event or field;
* changes a field's type or meaning;
* adds customer data;
* moves an event to a different trigger;
* creates a new API or MCP write path;
* changes a credential's scope.

Update the event catalog, privacy classification, test evidence, and rollback plan in the same review.

## Confirm your safeguards

* Every event and API/MCP workload has a named owner.
* Customer fields have a purpose, permission, and retention decision.
* No secret can enter an event through object spreading.
* Browser IDs are never used for authorization.
* Credentials stay out of browser code, prompts, logs, and repositories.
* Production writes require explicit workflow approval and verification.
* New fields and operations pass staging review before release.

<CardGroup cols={2}>
  <Card title="Browser data safety" icon="shield" href="/privacy/data-safety" />

  <Card title="Production rollout" icon="rocket" href="/guides/production-rollout" />
</CardGroup>