Revenue is an outcome, not a useful unit of diagnosis. Rejourney protects explicit business states such as:

• signup and first-value activation;
• checkout start, payment confirmation, and order creation;
• trial start, subscription, renewal, and cancellation recovery; and
• purchase validation and entitlement delivery in mobile apps.

For each state, the analysis starts with an eligible population and asks whether failure has increased beyond a comparable healthy population. It uses leading signals: journey changes, repeated interaction, request failures, runtime errors, crashes/ANRs, and state contradictions. These signals rank the risk before a lagging aggregate may make it obvious.

eligible session -> intended action -> request / product state
                 -> visible confirmation -> protected business outcome

The lead time depends on the transition. A checkout confirmation failure can be actionable immediately. A retention risk may only be confirmed after the chosen return or renewal window. There is no universal revenue score or fixed lead time.

The SDKs capture session, route/screen, interaction, and technical context. Add stable, domain-level events for the states that establish intent and a successful outcome. For example:

Rejourney.logEvent('checkout_started', {
  orderId: 'order_123',
  amount: 49,
  currency: 'USD',
});

Rejourney.logEvent('purchase_completed', {
  orderId: 'order_123',
  transactionId: 'txn_456',
  amount: 49,
  currency: 'USD',
});

Use internal user identifiers where identification is needed; do not send raw PII, payment credentials, secrets, or sensitive application payloads. The transaction/order identifiers and monetary fields above are optional event properties. They do not replace a financial ledger.

The basic population estimate is:

excess failed intent = eligible attempts × (current failure rate - healthy failure rate)
potential impact     = excess failed intent × historical completion value

The baseline must match the transition and context: release, platform, route or screen, device, region, campaign, experiment, and time window where relevant. Potential impact is an estimate, not booked or recovered revenue. Keep it separate from evidence confidence. High traffic alone does not justify a financial claim.

Candidate leaks are investigated with signal families that fail differently:

An event drop identifies a cohort. Replay describes an experience. Payment or entitlement state can confirm that the protected outcome failed. An unexplained exit remains an investigation until more evidence appears.

A candidate records the protected transition, affected users and sessions, baseline and excess failure, first and last seen time, release and segment concentration, technical signals, and representative healthy and failed sessions. Product and engineering can then test a specific hypothesis.

flowchart LR
  A[Web or mobile SDK] --> B[Session, journey, interaction, and runtime signals]
  C[Domain events] --> D[Protected business-state transitions]
  B --> E[Baseline and cohort comparison]
  D --> E
  E --> F[Ranked candidate leak]
  F --> G[Replay, request, error, and state evidence]
  G --> H[Human verification and fix]
  H --> I[Compare the original transition after release]

The checked-in benchmark measures web SDK capture overhead. It does not measure revenue-leak prediction accuracy. It compares the Rejourney browser SDK with PostHog on the same scripted flow in local Next.js, SvelteKit, and Nuxt fixtures. Both SDKs send to configured live project endpoints; browser measurements are collected through Playwright and Chrome DevTools Protocol.

The published run used Chromium at 1365×768, three iterations per framework/mode, and this shared flow: load, form edits, custom event, identity and metadata, request, route transition, synthetic error, missing resource, scroll, and an 85 ms controlled long task. It is a small sample and should be rerun before applying its results to another application.

TaskDuration is Chrome's main-thread busy-time proxy over the complete scripted visit, including the fixed flush wait. The figures are per-fixture medians from the published report. They are not a latency SLA.

Evidence and methodology:

The mobile comparison records package footprint against Sentry at the versions below. Transfer size comes from Bundlephobia. It measures packages, not a complete mobile application.

Sources: @rejourneyco/react-native on Bundlephobia and @sentry/react-native on Bundlephobia.

The recorded Rejourney capture measurement used an iPhone 15 Pro on iOS 26, Expo SDK 54, the React Native New Architecture, and a production app with Mapbox Metal and Firebase. The workload had 46 complex feed items, a Mapbox GL view, 124 API calls, 31 subcomponents, active gesture tracking, and privacy redaction.

Only UIKit + Metal capture runs on the main thread. These numbers describe the recorded workload. They are not a general mobile-performance or Sentry-runtime comparison.

npm install @rejourneyco/browser

import { Rejourney } from '@rejourneyco/browser';

await Rejourney.init('pk_live_your_public_key');
await Rejourney.start();

Call start() after consent when your site requires it. Add the application domain to Allowed Domains in Project Settings; web recording does not start until it is allowed. The browser SDK documentation covers framework-specific entry points, route naming, identity, and privacy-sensitive settings: web getting started.

npm install @rejourneyco/react-native

import { Rejourney } from '@rejourneyco/react-native';

Rejourney.init('pk_live_your_public_key');
Rejourney.start();

React Native requires native code and does not run in Expo Go. See React Native getting started for navigation tracking, session controls, event naming, and mobile privacy settings.

In Xcode, choose File → Add Package Dependencies and add:

https://github.com/rejourneyco/rejourney

Rejourney requires iOS 15.1 or later.

import SwiftUI
import Rejourney

@main
struct MyApp: App {
    @MainActor
    init() {
        Rejourney.configure(publicKey: "rj_your_public_key")
        Task { await Rejourney.start() }
    }

    var body: some Scene {
        WindowGroup { ContentView() }
    }
}

See iOS getting started for screen tracking, identity, event capture, and recording controls.

• A ranked signal does not establish causality. Inspect representative sessions and the authoritative business state before treating it as a revenue leak.
• Define an outcome, require enough volume, and choose a comparable baseline. An abandonment, error, or replay anomaly can have other explanations.
• Re-check the original cohort after releases, pricing changes, experiments, seasonal shifts, or instrumentation changes.
• Payments, subscriptions, entitlements, and booked revenue remain in the commercial system of record.
• Configure consent, capture controls, sampling, allowed domains, and masking. Do not send PII, credentials, payment data, or secrets in events or logs.

For a local development environment, start with local Kubernetes development. For single-node self-hosting, use the checked-in self-hosted guide. Architecture and deployment references are available in the architecture documentation.

Client-side components (SDKs and CLIs) are licensed under Apache 2.0. Server-side components (backend and dashboard) are licensed under SSPL 1.0. See LICENSE-APACHE and LICENSE-SSPL.