ProlyticsWhat Prolytics OS Can Do With Your Data
See what PostHog, Stripe, and Sentry unlock across Health, Engine, Health Findings, Health Signals, and Watch.
Start with the question, not every connector
You do not need to connect everything before Prolytics becomes useful. Start with the system that owns the evidence for your first decision. Add another source when the question crosses from product behaviour into reliability or billing.
0 supported capabilities for this selection. Each capability still requires its stated evidence.
| Capability | Outcome | Required evidence |
|---|
| Start here | Connect | First useful questions |
|---|---|---|
| Users are not progressing | PostHog | Where are people stopping, and are they reaching value? |
| Revenue moved | Stripe | Which subscription, payment, or retention movement changed the result? |
| Customers are seeing technical pressure | Sentry | Which issues or transactions created the pressure, and when did it begin? |
| The explanation crosses systems | Add the relevant second source | Did the supported movements occur together, and is there enough identity coverage to link them? |
One source can establish a useful fact. More sources can strengthen an investigation. They do not turn timing into causation or make unrelated records belong to the same customer.
PostHog: understand product behaviour
Connect PostHog when the question begins with activation, engagement, retention, conversion, or a product journey. OS uses your event and property definitions to prepare the product evidence that Health and Engine can support.
| What you can do | Where it appears | What it needs |
|---|---|---|
| See whether users reach the value moment you care about | Usage Health | A confirmed value-moment event and enough cohort history |
| Compare activation quality across cohorts | Usage Health | A confirmed activation event and eight weekly cohorts |
| Measure product stickiness with DAU/MAU | Usage Health | Verified active-user activity across at least 30 days |
| Follow weekly retention movement | Usage Health | Enough completed cohort weeks for a trustworthy comparison |
| Find where users stop in onboarding, activation, or checkout | Engine | Usable event definitions and a clear journey or outcome |
| Track meaningful product movement after it is detected | Health Findings, Health Signals, and Watch | A supported metric, trusted source data, and a baseline where the workflow requires one |
PostHog event names are not treated as universal business definitions. Confirm the events that represent activation and value in your product. If a definition is missing or changes, the affected metric stays in setup or becomes unavailable instead of presenting a misleading decline.
User-level and account-level conclusions also depend on identity coverage. General product movement can still be useful without it.
Connect PostHog and review the required access ->
Stripe: explain billing and revenue movement
Connect Stripe when the question begins with MRR, subscriptions, retention, churn, expansion, contraction, refunds, or failed payments. OS keeps currency, billing interval, and reporting-window boundaries attached to the calculation.
| What you can do | Where it appears | What it needs |
|---|---|---|
| Break down recurring revenue movement | Billing Health and Engine | Subscription, price, invoice, customer, and payment records |
| Review new revenue, expansion, contraction, and churn | Billing Health and Engine | A complete current and comparison period |
| See failed-payment pressure and recovery | Billing Health | Failed-payment events, amounts, timestamps, and recovery state |
| Measure NRR and compare retention over time | Billing Health | Completed monthly subscription history, including contraction and churn |
| Inspect cohort retention and revenue concentration | Billing Health | Enough historical and customer-level MRR evidence for the requested view |
| Track meaningful billing movement after it is detected | Health Findings, Health Signals, and Watch | A supported metric and enough history to establish the required comparison or baseline |
Metrics such as current MRR can become useful quickly. NRR, cohort retention, and efficiency measures need completed historical periods. Until the comparison is earned, Health shows Building rather than inventing a value from incomplete records.
Stripe remains the source of truth for billing evidence. Prolytics reads the connected account but cannot alter subscriptions, issue refunds, or change customer records.
Connect Stripe and review the required access ->
Sentry: connect reliability pressure to customer impact
Connect Sentry when the question begins with an incident, release, error spike, affected users, or a slow transaction. OS uses issues, events, releases, environments, and performance evidence to show what changed and how widely the pressure reached.
| What you can do | Where it appears | What it needs |
|---|---|---|
| See which issues created the most pressure | Reliability Health | Accessible issue and event history for the selected project |
| Review affected users when Sentry has usable user context | Reliability Health | User context on the relevant events |
| Compare latency, transaction pressure, and reliability movement | Reliability Health and Engine | Performance data for the requested transaction and period |
| Check whether movement began around a release | Engine | Release and environment context alongside the incident window |
| Track meaningful reliability movement after it is detected | Health Findings, Health Signals, and Watch | A supported metric, trusted issue history, and a baseline where required |
Sentry can support a general reliability conclusion without user identity. Claims about the same users or accounts require usable identifiers on the events involved. If that coverage is missing, OS keeps the conclusion at the reliability or timing level.
Connect Sentry and review the required access ->
What another source adds
Add a source when it can resolve a question that the first source cannot answer alone.
| Sources | What OS can examine | The limit to check |
|---|---|---|
| PostHog + Sentry | Whether product friction moved with errors or performance pressure | Aligned timing does not prove the same users were affected |
| PostHog + Stripe | Whether activation, conversion, or retention movement appeared before a billing outcome | User-level and account-level claims need safe identity linkage |
| Stripe + Sentry | Whether subscription or payment pressure appeared around an incident | The incident may align with the outcome without causing it |
| PostHog + Stripe + Sentry | End-to-end investigation across product behaviour, reliability, and billing | Each claim still depends on its own history, mapping, and identity requirements |
Use Correlate when you already have a relationship to test. Use Investigate when several explanations remain plausible. Engine ranks what the connected evidence supports and keeps conflicting or missing evidence visible.
Choose the right Engine mode ->
How OS turns source data into a decision
Connecting a source does more than add another chart:
- Health calculates supported metrics for the selected reporting window and keeps Billing, Usage, and Reliability evidence in one review.
- Intelligent briefings summarise a bounded fact set. The model explains calculated evidence. It does not create the metric.
- Health Findings preserve meaningful detected issues that deserve review.
- Health Signals record supported metrics that moved materially against an established baseline. A duplicate Signal is suppressed when a Finding already covers the same movement.
- Engine fetches facts, tests specified relationships, or investigates several supported explanations.
- Watch keeps the original condition connected to later observations so you can judge whether it recovered.
This loop remains useful with one source. Additional sources increase the evidence available to a claim, not the certainty OS is allowed to manufacture.
Read the readiness state before acting
Every metric earns its result independently. A healthy connection does not mean every metric is ready on the same day.
| State | What it means | What to do |
|---|---|---|
Connect | The required source is missing | Connect the system that owns the evidence |
Building | History, mapping, or another prerequisite is incomplete | Wait for the stated requirement or complete the requested setup |
No data | The source is reachable, but the selected period has no usable records | Check the reporting window and source activity |
Unavailable | The source or calculation cannot be trusted right now | Review Connections, permissions, freshness, and the displayed limitation |
Ready | Enough verified evidence exists for the metric | Use the exact window, comparison, source, and limits shown with the result |
Missing evidence never becomes zero. Sparse history never becomes NaN. If OS cannot support the requested conclusion, it should tell you what is missing and stop there.
Choose your first useful setup
If checkout completion fell, connect PostHog first. Add Sentry when errors or latency may explain the friction. Add Stripe when the decision depends on payment completion or the resulting revenue.
If MRR moved, connect Stripe first and establish the revenue components. Add PostHog only when product behaviour could explain the movement. Add Sentry only when reliability pressure is a plausible part of the period.
If an incident may have affected customers, connect Sentry first and establish the issue and transaction window. Add PostHog or Stripe when you need to test a specific customer or business outcome.
Connect enough evidence to answer the question well. You do not need to copy every system into the investigation.
Where Prolytics stops
Prolytics uses read-only connections. It cannot change provider records, deploy code, alter a subscription, issue a refund, or resolve an incident inside another system.
It also does not assume that records from different sources belong to the same person or account. Identity-dependent claims require enough coverage to link them safely. Correlation remains correlation unless the evidence supports a stronger conclusion.
We do not train on your data. Your connected evidence is used to operate the service, answer your requests, preserve the history you paid for, and protect the platform.