UserCurrent App: for product and engineering
Ship behind flags. Know whether it worked.
Flags, experiments and product analytics run on one profile. A rollout, the adoption of a feature and retention are all read from the same events, and the config lives in your repo.
Flag new_share_dialog, experiment share_dialog_test
+2.6 pts
Share dialog completed, treatment vs control
21.0% of exposed users completed a share against 18.4% on control. The 95% interval is +0.9 to +4.3 pts, and it stays valid however often you check it.
95% interval +0.9 to +4.3 pts. Control 18.4%, treatment 21.0%.
95% interval −1.3 to +2.9 pts. Control 41.2%, treatment 42.0%.
- Limit
95% interval −0.6 to +0.8 pts. Control 2.3%, treatment 2.4%.Limit +1.0 pts.Within limit
- Exposed
- 6,412 control, 6,388 treatment
- Split check
- Matches 50/50
Feature flags
Flags that can target behavior, not only attributes
Roll a feature out by percentage, by account or by what users just did, and turn it off the moment a number moves the wrong way.
Three kinds of flag
Boolean flags, multivariate flags, and JSON flags that carry remote config.
Rollouts that stay put
Percentage rollouts are sticky by user or by account, so a person keeps the same value on every visit.
Targeting on behavior
Target by trait, by context, or by a realtime segment, so a flag can follow what a user just did and not only who they are.
Environments
Each project has at least development and production, with its own rules in each.
Scheduled ramps with guardrails
Ramp from 10% to 50% on a date. Each rollout is measured as a two-arm experiment, and a guardrail metric that regresses can stop it.
A kill switch on every flag
Turn a flag off for everyone and serve its fallback. Exposure events are recorded automatically, so any flag can become an experiment.
ComingCloudflare Flagship as the flag store. Today UserCurrent's own engine evaluates flags; either way they are authored in config and the console.
Product experiments
A readout you can trust early, and guardrails that act
The readout above is one rollout. The same engine runs tests on flags and on experiences, with the statistics written down so two implementations give the same answer.
A/B/n on flags and experiences
One primary metric, secondary metrics and guardrail metrics, all computed from events.
Metrics from your events
Conversion within a window, count per user, sum or mean of a property such as revenue, retention and feature adoption.
Results you can read at any time
Always-valid intervals mean checking early does not inflate false positives. CUPED uses each user's earlier behavior to tighten the interval.
Guardrails that act
A guardrail metric that regresses can roll the test back by itself. Starting a test and shipping a winner stay with people.
A sample ratio check
A visible warning when the observed split does not match the allocation, before anyone trusts the result.
Layers, a holdout and a size estimate
Concurrent tests on one surface do not overlap, a project-wide holdout measures long-run lift, and setup estimates how many users you need.
Product analytics
Funnels, retention and feature adoption on the events you already send
The analytics are UserCurrent's own, built on the same events that drive flags and experiments. There is no second pipeline.
Trial accounts that shared a document
31.4%
Last 7 days. +9.4 pts vs prior 7 days (22.0%).
Funnels and paths
Ordered or strict-order funnels with exclusion steps and breakdowns. Paths forward or backward from an event, page or screen.
Retention and stickiness
Cohort tables and curves from the events you choose, with breakdowns, and daily active over monthly active users.
Feature adoption
A catalog of features defined by the events that mean "used it", grouped into modules, with adoption, frequency, retention and trend. Tied to a flag, it shows adoption for those with the flag on against those without.
Dashboards your agent can build
Tiles for saved insights, defined in the console or in config, with starter templates, share links and scheduled email or chat summaries.
ComingSQL editor tiles on hosted projects. They are built, and hosted execution stays off until the security review passes.
Accounts and in-app experiences
Decide for the account, and show the right message inside the product
For B2B products, the account matters as much as the user.
Bucket by account
Everyone in an account gets the same flag value or experiment arm. Account-level splits and holdouts keep a team from seeing two versions.
Target on account traits
A user can belong to several accounts, events carry the active one, and a rule can read account traits such as plan.
In-app messages
Banner, modal, tooltip, inline card and a one-question survey, with React components and custom elements you can restyle. Survey answers are recorded as events.
Slots in your own UI
Declare a slot in your web app and UserCurrent decides its props, for example to personalize an app's own checklist.
Account-level rules can run a few seconds behind a user's own events. Multi-step product tours and built-in checklists are not part of the first release.
Config in your repo
A flag, its experiment and its feature, reviewed in one pull request
Your coding agent writes the config, the CLI checks it, and a person reviews the diff. Publishing is a dry run until you apply it, and an agent cannot publish to Production on its own.
import {
defineConfig, defineEvent, defineFlag, defineExperiment, defineFeature,
} from '@usercurrent/cli';
export default defineConfig({
events: [
defineEvent({ name: 'share_dialog_opened', description: 'Opened sharing.' }),
defineEvent({ name: 'share_completed', description: 'Shared a document.' }),
defineEvent({ name: 'error_shown', description: 'Showed an error.' }),
],
flags: [
defineFlag({
key: 'new_share_dialog',
name: 'New share dialog',
rollout: 10,
}),
],
experiments: [
defineExperiment({
id: 'share_dialog_test',
name: 'New share dialog',
on: 'new_share_dialog',
allocation: 50,
arms: [
{ id: 'control', variant: 'off', weight: 50 },
{ id: 'treatment', variant: 'on', weight: 50 },
],
metrics: {
primary: 'share_completed',
guardrails: ['error_shown'],
},
}),
],
features: [
defineFeature({
key: 'share_dialog',
name: 'Share dialog',
module: 'Collaboration',
owner: 'platform-team',
events: [{ event: 'share_dialog_opened' }],
flagKey: 'new_share_dialog',
}),
],
});SDKs
Which platforms are covered today
One SDK per platform serves both products. The browser and the server are built. Mobile and desktop are not.
Web and server
The web SDK for browsers and the server SDK for Node 24 and Cloudflare Workers. They always answer: when a decision cannot be made, your code default is returned.
Built
OpenFeature providers
Server and web providers over the SDKs, so flag code written for OpenFeature keeps working.
Built
Mobile and desktop apps
SDKs for iOS, Android, React Native and Electron, and native rendering of the built-in messages.
Coming
Put the next release behind a flag
Your coding agent proposes the events and the feature catalog from your code, and you review the pull request.
Why this button?
It is this page's own suggestion for now. As you read, this site keeps a small profile of who each page is for and what it is about, in your browser, and picks this button from it. Nothing is sent.