Skip to main content
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.
ClassExamplesHandling
Public product contextroute name, product ID, feature nameSend when needed
Internal operational contextsafe status code, release versionReview and limit
Customer datauser ID, email, phone, addressPurpose, permission, and retention review required
Secret or restricted contentpasswords, tokens, payment details, private messagesNever 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. 
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. 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.

Browser data safety

Production rollout