Required Datapoints
- Total Revenue from Converted Trial Users
- Total Number of Users Who Entered a Trial (in period)
- Optional: Trial length or segmentation (e.g., by persona or plan)
Revenue per Trial User measures the average revenue generated per user who enters a product trial—regardless of whether they convert or not. It helps quantify the trial program’s financial efficiency.
Revenue per Trial User is a critical metric for product-led growth efficiency, reflecting how free users convert into monetized value over a defined period—typically trial to paid or freemium to premium.
The nuance of this KPI varies by model:
A high revenue per trial user signals strong onboarding, pricing alignment, and user activation, while a low rate points to drop-off, friction, or value disconnect.
Segment by user persona, acquisition channel, trial experience (guided vs. unguided) or feature path to identify high-potential cohorts.
Revenue per Trial User informs:
These are the main factors that directly impact the metric. Understanding these lets you know what levers you can pull to improve the outcome
Actionable ideas to optimize this KPI, from fast, low-effort wins to strategic initiatives that drive measurable impact.
Activities commonly tied to improving or operationalizing this KPI.
| Activity | Description |
|---|---|
| Trial Optimization | Trial Optimization is a structured process aimed at increasing the number of users who move from signing up for a product trial to becoming paying customers. It improves performance by removing friction, testing changes, and scaling what works. Relevant KPIs include Revenue per Trial User and Time to First Key Action. |
| Onboarding Flows | Onboarding Flows are structured processes designed to introduce new customers or users to a product or service, helping them quickly realize value and gain proficiency. It coordinates execution across touchpoints so teams can move users or accounts toward the target outcome. Relevant KPIs include Revenue per Trial User and Time to First Key Action. |
| PLG Growth Strategy | PLG Growth Strategy focuses on A Product-Led Growth (PLG) strategy leverages the product as the primary engine for acquiring, activating, retaining, and expanding users. It gives teams a clear plan for where to focus, how to sequence work, and what to measure. Relevant KPIs include Revenue per Trial User and Time to Expansion Signal. |
| Pricing Design | Pricing Design involves the systematic formulation, evaluation, and optimization of pricing models to align with the organization’s go-to-market approach. It gives teams a clear plan for where to focus, how to sequence work, and what to measure. Relevant KPIs include Revenue per Trial User. |
| Feature Activation | Feature Activation is the process of guiding users through the discovery, activation, and effective use of specific product features. It coordinates execution across touchpoints so teams can move users or accounts toward the target outcome. Relevant KPIs include Immediate Time to Value and Revenue per Trial User. |
4,200 users entered trial in Q2
800 converted, generating $100,000 in revenue
Formula: $100,000 ÷ 4,200 = $23.81 per trial user
This KPI is associated with the following stages in the AAARRR (Pirate Metrics) funnel:
This KPI is classified as a lagging Indicator. It reflects the results of past actions or behaviors and is used to validate performance or assess the impact of previous strategies.
This role is directly accountable for the KPI and is expected to drive progress and decisions around it.
These roles contribute directly to performance and typically partner on execution, reporting, or optimization.
These roles should stay informed on changes in the KPI because it influences adjacent planning, coordination, or outcomes.
These leading indicators influence this KPI and act as early signals that forecast future changes in this KPI.
These lagging indicators confirm, quantify, or amplify this KPI and help explain the broader business impact on this KPI after the fact.
How this KPI is structured in Cube.js, including its key measures, dimensions, and calculation logic for consistent reporting.
cube('TrialUsers', { sql: `SELECT * FROM trial_users`, measures: { totalRevenueFromConvertedTrialUsers: { sql: `total_revenue`, type: 'sum', title: 'Total Revenue from Converted Trial Users', description: 'Total revenue generated from users who converted after a trial period.' }, totalNumberOfTrialUsers: { sql: `user_id`, type: 'countDistinct', title: 'Total Number of Users Who Entered a Trial', description: 'Count of unique users who entered a trial period.' }, revenuePerTrialUser: { sql: `${totalRevenueFromConvertedTrialUsers} / NULLIF(${totalNumberOfTrialUsers}, 0)`, type: 'number', title: 'Revenue per Trial User', description: 'Average revenue generated per user who entered a trial period.' } }, dimensions: { userId: { sql: `user_id`, type: 'string', primaryKey: true, title: 'User ID', description: 'Unique identifier for each user.' }, trialStartDate: { sql: `trial_start_date`, type: 'time', title: 'Trial Start Date', description: 'The date when the user started the trial period.' } }})Note: This is a reference implementation and should be used as a starting point. You’ll need to adapt it to match your own data model and schema