Rejourney
Revenue-leak prediction for web and mobile products.
Explore the website →
SUPPORTED PLATFORMS
Rejourney finds product failures that may be costing revenue. You define the
business transition to protect: activation, checkout, purchase validation,
entitlement, or renewal. Rejourney compares the current cohort with a healthy
baseline and groups the evidence around the change.
Session replay is the investigative surface
Session replay is central to the workflow. A conversion drop identifies a
transition worth checking; the recording shows the path to that transition,
what the user tried, whether the UI acknowledged it, and the errors or slow
requests in the same session. Reviewers can compare affected sessions with
successful sessions from the same release, device, route, or campaign.
The result is a candidate leak with a cohort, a baseline, supporting signals,
and sessions to inspect. It becomes a confirmed product or revenue problem only
after the relevant application and business state have been checked.
Investigation toolbox
The issue feed points to a cohort. These views are used to narrow down what
changed and where to look next.
Journeys and interaction
Journey maps show the routes through a flow. Heatmaps expose the interaction
pattern on the screen: repeated taps, missed targets, or controls that receive
little attention. Use both when the failure is visible in the interface but the
cause is not yet clear.
API, crash, and stability context
Endpoint views break down request volume, errors, latency, and status codes.
Crash and ANR detail adds the app version, device, and thread context around a
failure. This is where a problematic UI transition can be connected to a
backend or runtime condition.
Device and geographic cohorts
Device views make version, operating-system, and hardware concentrations
visible. Geographic views help separate a global regression from an issue tied
to a region or network path.
General analytics and revenue context
The replay and investigation views sit alongside the project-level context that
helps decide whether a change is isolated or broad. The overview combines
version adoption, engagement mix, stability, time in product, retention, and
cohorts. The events view shows the business events behind a flow and the users
who generated them. When a revenue source is connected, the revenue view keeps
transactions, refunds, subscribers, and the revenue trend in the same review.
Open an image for the full-resolution capture.
What Rejourney looks for
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.
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.
From an event to an investigation
Instrument the protected states
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:
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.
Compare each cohort with a baseline
The basic population estimate is:
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.
Read the evidence in context
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.
Review the candidate
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.
Web capture benchmark
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:
benchmark README
published report
redacted raw results
benchmark runner
Mobile SDK measurements
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.
@rejourneyco/react-native on Bundlephobia
@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.
Quick integration
Web
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.
React Native
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.
Swift
In Xcode, choose File → Add Package Dependencies and add:
Rejourney requires iOS 15.1 or later.
See iOS getting started for screen tracking,
identity, event capture, and recording controls.
Limits, privacy, and verification
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.
Development and deployment
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.
the architecture documentation
License
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.