Good intelligence
starts with
clear data contracts.

Define what value looks like.

Choose the product action that represents a useful result: a report used to make a decision, a lesson completed, or a shared project finished. Identify the system that records it and the owner who can confirm its meaning.

Make identity explicit.

Keep the product user or team identity mapped to the correct Stripe customer ID. Display names help people recognize an account; they are not sufficient evidence for linking records.

Review duplicate, missing, and ambiguous mappings. Tenant identity must come from the authenticated integration boundary rather than an untrusted client claim.

Use the restricted connection.

The Stripe connector uses restricted, read-only access to approved billing context. Agree the required permissions and secure configuration path with the setup owner; keep credentials out of client code, public forms, and email.

Review forecast eligibility separately. The current supported path is scoped to one USD licensed, per-unit recurring price on an eligible subscription. Metered, tiered, and multiple-subscription arrangements need a scope review.

A zero and a missing record are different.

A complete day with no activity is evidence. An unreported day may mean the data is missing. Your integration should preserve that distinction, along with when an event happened and when the system received it.

Browser tracking can add context, but is best effort. It does not, by itself, establish that the behavioral ledger is complete.

Agree the meaning. Validate the mapping.

Atlas keeps source and mapping evidence connected to its origin. Proposed tracking and mapping changes require explicit approval; production trackers also require validation.

Review the proposed feature meaning with the product owner. Missing prerequisites should remain visible as readiness issues rather than becoming unsupported risk scores.

Read the first assessment with its context.

Check the customer name and Stripe ID, source timestamp, coverage, forecast horizon, and evidence behind the flag. Newly connected customers may need more history before an individual pattern is supported.

Recoverable revenue needs evidence beyond churn probability. Keep unavailable estimates visible until that support exists.