{
"generated_at": "2026-09-23T00:39:35Z",
"source": "RevenueCat Monetization Model (Supabase)",
"exporter_version": "1.1.0",
"capabilities": [
{
"id": "acquisition_segmented_monetization_analytics",
"name": "Acquisition-segmented monetization analytics",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"iOS",
"Android"
],
"monetization_primitives": [
"Subscription",
"One-time",
"Ads",
"In-App Currency"
],
"what_it_does": "Allows monetization metrics and charts to be filtered and segmented by acquisition source, including App Store Ads, enabling accurate measurement of channel-level revenue performance.",
"why_it_matters": "Teams optimize locally while harming overall business performance. Revenue data is fragmented across subscriptions, purchases, and ads, making it difficult to understand true user value. Teams make acquisition and monetization decisions based on incomplete or misleading data. Ad spend data lives in ad platforms (Meta, Google, ASA) while revenue data lives in app stores or subscription systems. Without joining these, teams cannot calculate true payback periods, ROAS, or cost-per-trial by channel. Growth teams over-invest in channels that look good on install volume but have poor payback, or under-invest in high-LTV channels because they can't prove ROI. Budgets are allocated based on incomplete signals. All users are shown the same monetization experience regardless of their goals, intent, or context. This reduces relevance and conversion, forces generic paywalls and offers, and limits the ability to tailor monetization to different user needs, leading to lower performance across the funnel. Different users are shown the same prices, offers, and monetization surfaces despite having different willingness to pay. High-value users are under-monetized while low-value users are over-priced, hurting both revenue and user experience. Total user value is measured across subscriptions, purchases, and other revenue streams Acquisition and product decisions are based on unified revenue truth rather than partial signals Monetization experiences are tailored by segment to improve conversion and LTV Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience",
"constraints_limits": "Shows monetization revenue segmented by acquisition source (e.g., which App Store Ads keyword drove which subscribers), but does NOT ingest or display ad spend data. Payback and ROAS calculations require the customer to join their own spend data externally (e.g., via data export to a warehouse). Depends on availability and correct mapping of acquisition metadata; segmentation accuracy is limited by identifier matching and the completeness of attribution data provided by the platform/customer.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/integrations/attribution/apple-search-ads#:~:text=With%20our%20Apple%20Search%20Ads,integration%20you%20can",
"decisions_enabled": [
"Should revenue data be unified across platforms and products?",
"Should monetization logic adapt based on user intent or context?"
],
"canonical_problems": [
"We don’t understand true user value across revenue streams",
"We can't connect acquisition spend to downstream revenue to measure channel-level payback",
"All users are monetized the same way"
],
"outcomes": [
"Total user value is measured across subscriptions, purchases, and other revenue streams",
"Acquisition and product decisions are based on unified revenue truth rather than partial signals",
"Monetization experiences are tailored by segment to improve conversion and LTV",
"Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience"
],
"proof_points": [
{
"name": "Ladder: Granular ad spend attribution",
"type": "Customer",
"statement": "Ladder achieves granular attribution of ad spend to paid conversions, cost per trial, and payback periods using RevenueCat Webhooks + Segment integration to BigQuery. \"RevenueCat Webhook events enables us to attribute ad spend with granular precision to paid conversions, cost per trial, and payback periods. Matching UTM links with purchase data allows us to precisely identify which ads and affiliate partners drive the most paid conversions, yield the best retention rates, and generate full-price versus discounted purchases.\" — Greg Stewart, CEO"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/acquisition_segmented_monetization_analytics.json"
}
},
{
"id": "ad_revenue_ingestion_and_unified_reporting",
"name": "Ad monetization revenue ingestion",
"mechanism_type": "Integration",
"status": "Beta",
"platforms": [
"Cross-platform"
],
"monetization_primitives": [
"Ads"
],
"what_it_does": "Ingests revenue earned from in-app advertising (e.g., AdMob, ironSource, AppLovin) and combines it with subscription and purchase revenue so customers can understand total user value across all monetization streams. This is about ad REVENUE (money earned from showing ads to users), not ad SPEND (money spent on user acquisition campaigns).",
"why_it_matters": "We default to a one-size-fits-all monetization approach, which under-monetizes high-value users and caps revenue upside. Without this decision, we can’t consistently tailor paywalls, pricing, offers, retention efforts, or recovery flows to the users who contribute the most value, reducing ARPU, LTV, and margin potential. Users with high willingness to pay are not identified or offered tailored upsell opportunities. Teams leave significant revenue on the table by treating high-spending users the same as everyone else. Teams optimize locally while harming overall business performance. Revenue data is fragmented across subscriptions, purchases, and ads, making it difficult to understand true user value. Teams make acquisition and monetization decisions based on incomplete or misleading data. Ad spend data lives in ad platforms (Meta, Google, ASA) while revenue data lives in app stores or subscription systems. Without joining these, teams cannot calculate true payback periods, ROAS, or cost-per-trial by channel. Growth teams over-invest in channels that look good on install volume but have poor payback, or under-invest in high-LTV channels because they can't prove ROI. Budgets are allocated based on incomplete signals. High-value users are identified and shown appropriate upsell offers Repeat purchase and upsell programs increase revenue without harming retention Total user value is measured across subscriptions, purchases, and other revenue streams Acquisition and product decisions are based on unified revenue truth rather than partial signals",
"constraints_limits": "Depends on available ad network integrations and matching logic between ad revenue and user/cohort identifiers.",
"requires_configuration": true,
"docs_link": "",
"decisions_enabled": [
"Is this a user we should treat differently because of their value?",
"Should revenue data be unified across platforms and products?"
],
"canonical_problems": [
"High-value users are under-monetized",
"We don’t understand true user value across revenue streams",
"We can't connect acquisition spend to downstream revenue to measure channel-level payback"
],
"outcomes": [
"High-value users are identified and shown appropriate upsell offers",
"Repeat purchase and upsell programs increase revenue without harming retention",
"Total user value is measured across subscriptions, purchases, and other revenue streams",
"Acquisition and product decisions are based on unified revenue truth rather than partial signals"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/ad_revenue_ingestion_and_unified_reporting.json"
}
},
{
"id": "additional_app_store_and_platform_support",
"name": "Additional app store and platform support",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"Other",
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time"
],
"what_it_does": "Extends RevenueCat’s monetization infrastructure to support additional app stores and platforms beyond the core Apple and Google ecosystems.",
"why_it_matters": "The system is built narrowly around current revenue models and becomes expensive to extend later. We need to decide whether to build and maintain our own monetization infrastructure or rely on a platform to handle it for us. Teams delay monetization, accumulate technical debt, or later discover they are locked into fragile systems that slow product development and prevent pursuing new revenue opportunities. Teams react late to platform changes, causing revenue disruption and emergency work. Changes in platform APIs, policies, or billing rules introduce risk to existing monetization strategies. Revenue breaks unexpectedly, compliance issues arise, or teams scramble reactively to fix problems under time pressure. Monetization infrastructure is shipped without derailing the core product roadmap Engineering time stays focused on product differentiation instead of monetization plumbing Platform changes do not break revenue or compliance Store policy or billing API updates are handled proactively rather than as firefights",
"constraints_limits": "Support depends on platform APIs, billing capabilities, and policy constraints.",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/projects/connect-a-store",
"decisions_enabled": [
"Which monetization models do we want to support now and in the future?",
"Who is responsible for tracking and responding to platform API changes?"
],
"canonical_problems": [
"Do we build or buy monetization infrastructure?",
"Platform and policy changes create monetization risk"
],
"outcomes": [
"Monetization infrastructure is shipped without derailing the core product roadmap",
"Engineering time stays focused on product differentiation instead of monetization plumbing",
"Platform changes do not break revenue or compliance",
"Store policy or billing API updates are handled proactively rather than as firefights"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/additional_app_store_and_platform_support.json"
}
},
{
"id": "ai_paywall_generation",
"name": "AI-powered paywall generation and editing",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency"
],
"what_it_does": "Lets teams build and edit paywalls through a conversational AI interface, without design or engineering involvement. Supports creation from an App Store URL, a text description, or uploaded brand assets. Teams refine copy, layout, and visual design through natural language. Handles localization and flags conversion issues like low-contrast CTAs or missing restore links. Now the default entry point for paywall creation in the dashboard, and available to agents via the RevenueCat MCP.",
"why_it_matters": "Users hesitate because they don’t fully understand the offer. Users reach a monetization surface without fully understanding why the product is worth paying for. Conversion rates suffer, users churn early, and teams compensate by discounting instead of improving value communication. Users understand the value proposition before seeing an offer Monetization surfaces align with user intent and the value they care about",
"constraints_limits": "Template selection is optional. Generated paywalls remain editable in the Paywall Editor and must use supported components and the appropriate app integration. Publishing is separate from creating or editing a draft.",
"requires_configuration": true,
"docs_link": "",
"decisions_enabled": [
"What content and explanation should this monetization surface include?"
],
"canonical_problems": [
"Users don’t understand the value before being asked to pay"
],
"outcomes": [
"Users understand the value proposition before seeing an offer",
"Monetization surfaces align with user intent and the value they care about"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/ai_paywall_generation.json"
}
},
{
"id": "app_store_retention_messaging_api",
"name": "App Store retention messaging API support",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"iOS"
],
"monetization_primitives": [
"Subscription"
],
"what_it_does": "Integrates with Apple’s Retention Messaging API to present targeted retention offers inside the native App Store cancellation flow with low-latency responses.",
"why_it_matters": "Users churn without seeing alternatives. Users reduce spending or cancel before the business realizes the full value of the relationship. Revenue declines silently as users leave without any attempt at intervention or recovery. Cancellation intent triggers timely interventions that prevent avoidable churn At-risk users re-engage and remain subscribed long enough to realize value",
"constraints_limits": "Available only where supported by Apple and subject to API latency requirements.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/platform-resources/apple-platform-resources/apple-retention-messaging-api",
"decisions_enabled": [
"Should we present a retention offer when cancellation intent is detected?"
],
"canonical_problems": [
"Users cancel or disengage before delivering full value"
],
"outcomes": [
"Cancellation intent triggers timely interventions that prevent avoidable churn",
"At-risk users re-engage and remain subscribed long enough to realize value"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/app_store_retention_messaging_api.json"
}
},
{
"id": "attribution_and_asa_integrations",
"name": "Attribution and Apple Search Ads integrations",
"mechanism_type": "Integration",
"status": "GA",
"platforms": [],
"monetization_primitives": [],
"what_it_does": "Routes RevenueCat subscription lifecycle events (trials, purchases, renewals, cancellations, refunds) to third-party mobile attribution and Apple Search Ads optimization platforms. Enables these tools to attribute subscription revenue back to specific campaigns, ad groups, and keywords — closing the loop between ad spend and downstream LTV. Supported partners include AppsFlyer, Adjust, Airbridge, and Asapty. Replaces the need for customers to hand-wire attribution routing through generic webhooks. Each integration is enabled from the RevenueCat dashboard with partner-specific credentials. ASA-based integrations require Apple Search Ads attribution collection to be enabled in the RevenueCat project. Singular Event Endpoint V2 support is available to apps enabled in its supervised beta.",
"why_it_matters": "Teams optimize locally while harming overall business performance. Revenue data is fragmented across subscriptions, purchases, and ads, making it difficult to understand true user value. Teams make acquisition and monetization decisions based on incomplete or misleading data. Ad spend data lives in ad platforms (Meta, Google, ASA) while revenue data lives in app stores or subscription systems. Without joining these, teams cannot calculate true payback periods, ROAS, or cost-per-trial by channel. Growth teams over-invest in channels that look good on install volume but have poor payback, or under-invest in high-LTV channels because they can't prove ROI. Budgets are allocated based on incomplete signals. Total user value is measured across subscriptions, purchases, and other revenue streams Acquisition and product decisions are based on unified revenue truth rather than partial signals",
"constraints_limits": "Integrations require partner-specific credentials and identifiers. Singular V2 requires SDID obtained from the Singular SDK and passed to RevenueCat; collectDeviceIdentifiers() does not collect it. V1 remains available to eligible Singular accounts created before July 15, 2026. Apple AdServices returns attribution=false for ad groups using age or gender targeting, limiting workflows that require affirmative Apple Ads attribution.",
"requires_configuration": true,
"docs_link": "",
"decisions_enabled": [
"Should revenue data be unified across platforms and products?"
],
"canonical_problems": [
"We don’t understand true user value across revenue streams",
"We can't connect acquisition spend to downstream revenue to measure channel-level payback"
],
"outcomes": [
"Total user value is measured across subscriptions, purchases, and other revenue streams",
"Acquisition and product decisions are based on unified revenue truth rather than partial signals"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/attribution_and_asa_integrations.json"
}
},
{
"id": "automated_refund_request_handling",
"name": "Automated refund request handling",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"iOS",
"Android"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency"
],
"what_it_does": "Enables developers to configure and automate refund handling for the Apple App Store and Google Play Store. Supports audience-targeted refund policies that express grant, decline, or neutral preferences for specific customer segments, while each store retains final refund authority. Also provides contextual purchase and user information during refund review to help teams manage refund outcomes.",
"why_it_matters": "All monetization actions must be tied to visible in-app surfaces, limiting our ability to respond to high-signal events like cancellation, refund requests, or expiration in real time. This forces late or manual interventions and reduces the effectiveness of retention, recovery, and support-driven monetization actions. Users reduce spending or cancel before the business realizes the full value of the relationship. Revenue declines silently as users leave without any attempt at intervention or recovery. Cancellation intent triggers timely interventions that prevent avoidable churn At-risk users re-engage and remain subscribed long enough to realize value",
"constraints_limits": "Limited to refund flows exposed by platform providers.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/customers/refund-control/configure-refund-policies",
"decisions_enabled": [
"Should we take monetization actions without showing an in-app surface?"
],
"canonical_problems": [
"Users cancel or disengage before delivering full value"
],
"outcomes": [
"Cancellation intent triggers timely interventions that prevent avoidable churn",
"At-risk users re-engage and remain subscribed long enough to realize value"
],
"proof_points": [
{
"name": "MyMood AI Apple refunds reduction",
"type": "Customer",
"statement": "MyMood AI reduced Apple refunds by 50%"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/automated_refund_request_handling.json"
}
},
{
"id": "cancellation_and_refund_resolution_analytics",
"name": "Cancellation reason and refund resolution analytics",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"iOS",
"Android"
],
"monetization_primitives": [
"Subscription",
"One-time"
],
"what_it_does": "Aggregates and normalizes platform-provided cancellation reasons and refund outcomes to help teams understand why users churn and when refunds are granted or denied.",
"why_it_matters": "Teams optimize locally while harming overall business performance. Revenue data is fragmented across subscriptions, purchases, and ads, making it difficult to understand true user value. Teams make acquisition and monetization decisions based on incomplete or misleading data. Ad spend data lives in ad platforms (Meta, Google, ASA) while revenue data lives in app stores or subscription systems. Without joining these, teams cannot calculate true payback periods, ROAS, or cost-per-trial by channel. Growth teams over-invest in channels that look good on install volume but have poor payback, or under-invest in high-LTV channels because they can't prove ROI. Budgets are allocated based on incomplete signals. Churn analysis is speculative and inaccurate. Users reduce spending or cancel before the business realizes the full value of the relationship. Revenue declines silently as users leave without any attempt at intervention or recovery. Total user value is measured across subscriptions, purchases, and other revenue streams Acquisition and product decisions are based on unified revenue truth rather than partial signals Cancellation intent triggers timely interventions that prevent avoidable churn At-risk users re-engage and remain subscribed long enough to realize value",
"constraints_limits": "Limited to cancellation reason and refund outcome data exposed by each platform; reason codes and refund states may differ across stores and may be incomplete for some transactions.",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/dashboard-and-metrics/charts/app-store-refund-requests-chart",
"decisions_enabled": [
"Should revenue data be unified across platforms and products?",
"What information should we capture about why the user is leaving?"
],
"canonical_problems": [
"We don’t understand true user value across revenue streams",
"We can't connect acquisition spend to downstream revenue to measure channel-level payback",
"Users cancel or disengage before delivering full value"
],
"outcomes": [
"Total user value is measured across subscriptions, purchases, and other revenue streams",
"Acquisition and product decisions are based on unified revenue truth rather than partial signals",
"Cancellation intent triggers timely interventions that prevent avoidable churn",
"At-risk users re-engage and remain subscribed long enough to realize value"
],
"proof_points": [
{
"name": "MyMood AI Apple refunds reduction",
"type": "Customer",
"statement": "MyMood AI reduced Apple refunds by 50%"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/cancellation_and_refund_resolution_analytics.json"
}
},
{
"id": "centralized_monetization_configuration",
"name": "Centralized monetization configuration layer",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Web purchases"
],
"what_it_does": "Allows teams to configure products, entitlements, access rules, and monetization behavior centrally without shipping new app versions. Includes full lifecycle management of catalog entities (offerings, products, entitlements) — including archiving stale entries to keep the catalog clean without deleting historical data. The Product Catalog supports CSV editing and copying a product's App Store configuration into another plan. Teams can also configure RevenueCat through the CLI or their own AI coding agents using the RevenueCat AI Toolkit, including projects, apps, products, entitlements, Offerings and Packages.",
"why_it_matters": "Monetization behavior becomes inconsistent across platforms, teams, and codebases. Maintaining monetization systems over time diverts engineering effort away from building the core product. Monetization systems fall behind platform changes, bugs accumulate, and engineers spend increasing time maintaining revenue infrastructure instead of improving the product. Monetization systems stay reliable and current without ongoing internal maintenance burden Platform feature adoption happens quickly without major engineering projects",
"constraints_limits": "Limited to configuration options supported by RevenueCat. Product configuration cloning is scoped to the App Store. The RevenueCat CLI is available in public beta.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/getting-started/displaying-products#:~:text=If%20you%27ve%20configured%20Offerings%20in,flexibility%20to%20make%20remote%20updates",
"decisions_enabled": [
"Should monetization logic live in one centralized system?"
],
"canonical_problems": [
"We can’t afford to maintain monetization systems long-term"
],
"outcomes": [
"Monetization systems stay reliable and current without ongoing internal maintenance burden",
"Platform feature adoption happens quickly without major engineering projects"
],
"proof_points": [
{
"name": "HOLYWATER: 4x faster product launches",
"type": "Customer",
"statement": "HOLYWATER achieves 4x faster launch of new in-app offerings (from 8+ hours to ~2 hours per product) using RevenueCat product/entitlement setup. \"RevenueCat eliminates the manual work. We can set up new products, entitlements, and price tiers quickly—without spending days building backend logic.\" — Anatolii Kasianov, CTO and Co-founder"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/centralized_monetization_configuration.json"
}
},
{
"id": "charts_api",
"name": "Charts API",
"mechanism_type": "API",
"status": "GA",
"platforms": [
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Ads",
"Web purchases"
],
"what_it_does": "Provides programmatic API access to all RevenueCat subscription analytics data—revenue, churn, active subscribers, and dozens of other metrics—enabling developers to pull their data into any tool, platform, or custom application. Supports filtering, segmentation, and querying across multiple apps and time periods for building custom dashboards, automation, real-time alerts, AI agent integrations, data warehouse exports (Snowflake, BigQuery, Redshift), and BI tool integrations (Tableau, Looker, Power BI). Addresses frequent enterprise customer requests for programmatic analytics access.",
"why_it_matters": "Developers are locked into dashboard-only analytics, cannot build custom tooling, cannot automate based on metrics, and cannot integrate subscription data with AI agents or external systems. Developers cannot programmatically access their subscription analytics data. Analytics are only available through the RevenueCat dashboard UI, preventing custom tooling, automation, AI integration, and real-time data pipelines. Developers manually export data or scrape dashboards, cannot build custom tooling on top of RevenueCat data, cannot integrate with AI agents, cannot automate alerts or reports, and are limited to the dashboard's built-in visualizations and workflows. Developers can build custom analytics dashboards and tooling Subscription data can be integrated with AI agents and automation",
"constraints_limits": "API rate limits apply; data freshness depends on underlying analytics pipeline latency.",
"requires_configuration": false,
"docs_link": "",
"decisions_enabled": [
"How should developers programmatically access their analytics data?"
],
"canonical_problems": [
"Analytics data is locked in dashboard-only interfaces"
],
"outcomes": [
"Developers can build custom analytics dashboards and tooling",
"Subscription data can be integrated with AI agents and automation"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/charts_api.json"
}
},
{
"id": "cross_platform_billing_abstraction",
"name": "Cross-platform billing abstraction",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web"
],
"monetization_primitives": [
"Subscription",
"One-time"
],
"what_it_does": "Abstracts supported billing-platform and payment-provider product models, including multi-price Stripe Billing configurations, into RevenueCat products that customers can sell and track as distinct monetization options in Web purchase flows. RevenueCat Billing supports Avalara AvaTax alongside Stripe Tax for configured web purchases, renewals and refunds. Eligible subscribers can upgrade Stripe subscriptions through RevenueCat Web Checkout.",
"why_it_matters": "Revenue data and logic fragment across systems, making holistic decisions impossible. Revenue data is fragmented across subscriptions, purchases, and ads, making it difficult to understand true user value. Teams make acquisition and monetization decisions based on incomplete or misleading data. Total user value is measured across subscriptions, purchases, and other revenue streams Acquisition and product decisions are based on unified revenue truth rather than partial signals",
"constraints_limits": "Limited to billing systems RevenueCat supports.",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/welcome/overview",
"decisions_enabled": [
"Do we want to support multiple monetization models in a unified system?"
],
"canonical_problems": [
"We don’t understand true user value across revenue streams"
],
"outcomes": [
"Total user value is measured across subscriptions, purchases, and other revenue streams",
"Acquisition and product decisions are based on unified revenue truth rather than partial signals"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/cross_platform_billing_abstraction.json"
}
},
{
"id": "custom_store_and_distribution_integrations",
"name": "Custom store and distribution integrations",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"Other"
],
"monetization_primitives": [
"Subscription",
"One-time"
],
"what_it_does": "Implements custom integrations for non-standard stores or distribution deals, enabling monetization in environments that do not match existing store abstractions.",
"why_it_matters": "The team drifts into partial ownership, inheriting long-term costs without committing to a clear strategy. We need to decide whether to build and maintain our own monetization infrastructure or rely on a platform to handle it for us. Teams delay monetization, accumulate technical debt, or later discover they are locked into fragile systems that slow product development and prevent pursuing new revenue opportunities. Monetization systems become under-resourced, brittle, and increasingly risky over time. Maintaining monetization systems over time diverts engineering effort away from building the core product. Monetization systems fall behind platform changes, bugs accumulate, and engineers spend increasing time maintaining revenue infrastructure instead of improving the product. Monetization infrastructure is shipped without derailing the core product roadmap Engineering time stays focused on product differentiation instead of monetization plumbing Monetization systems stay reliable and current without ongoing internal maintenance burden Platform feature adoption happens quickly without major engineering projects",
"constraints_limits": "Typically built for specific partners or deals and may not generalize.",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/platform-resources/amazon-platform-resources",
"decisions_enabled": [
"Do we want to own monetization infrastructure long-term?",
"Are we willing to staff and maintain monetization infrastructure indefinitely?"
],
"canonical_problems": [
"Do we build or buy monetization infrastructure?",
"We can’t afford to maintain monetization systems long-term"
],
"outcomes": [
"Monetization infrastructure is shipped without derailing the core product roadmap",
"Engineering time stays focused on product differentiation instead of monetization plumbing",
"Monetization systems stay reliable and current without ongoing internal maintenance burden",
"Platform feature adoption happens quickly without major engineering projects"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/custom_store_and_distribution_integrations.json"
}
},
{
"id": "customer_center",
"name": "Customer Center (self-serve monetization UI)",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency"
],
"what_it_does": "Provides a user-facing interface for post-purchase account management, including viewing purchases, managing subscriptions, initiating cancellation, capturing cancellation feedback, and presenting retention offers before redirecting to native cancellation flows.",
"why_it_matters": "Users churn without seeing alternatives. Users reduce spending or cancel before the business realizes the full value of the relationship. Revenue declines silently as users leave without any attempt at intervention or recovery. Churn analysis is speculative and inaccurate. f we can’t intervene before monetization fully stops, churn is treated as a single irreversible event instead of a process. We miss high-signal intervention windows such as post-cancellation but pre-expiration, and are limited to late winback attempts when user intent and engagement are already low. This reduces retention effectiveness and increases reliance on discounts instead of targeted recovery actions. Cancellation intent triggers timely interventions that prevent avoidable churn At-risk users re-engage and remain subscribed long enough to realize value",
"constraints_limits": "Cannot directly cancel subscriptions; redirects users to native store cancellation flows.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/tools/customer-center",
"decisions_enabled": [
"Should we present a retention offer when cancellation intent is detected?",
"What information should we capture about why the user is leaving?",
"Should we intervene before monetization stops?"
],
"canonical_problems": [
"Users cancel or disengage before delivering full value"
],
"outcomes": [
"Cancellation intent triggers timely interventions that prevent avoidable churn",
"At-risk users re-engage and remain subscribed long enough to realize value"
],
"proof_points": [
{
"name": "MySwimPro: Fewer support tickets around cancellations",
"type": "Customer",
"statement": "MySwimPro saw a reduction in inbound support requests related to cancellations after implementing RevenueCat Customer Center for user self-service. \"We felt confident putting it in a more prominent place. And it worked, we have seen fewer support tickets around cancellations.\" — Adam Oxner, Co-founder and CTO"
},
{
"name": "MySwimPro: Maintained win-back rates with less effort",
"type": "Customer",
"statement": "MySwimPro maintained their strong win-back offer success rates after switching from a custom flow to RevenueCat Customer Center, with much less effort required. \"I was monitoring churn closely after switching. Customer Center maintained our strong win-back results but with much less effort required on our part.\" — Adam Oxner, Co-founder and CTO"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/customer_center.json"
}
},
{
"id": "data_export_and_warehouse_integrations",
"name": "Data export and warehouse integrations",
"mechanism_type": "Integration",
"status": "GA",
"platforms": [
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Ads",
"Web purchases"
],
"what_it_does": "Exports monetization data for external analytics and company-wide reporting. Scheduled Data Exports can deliver files to cloud storage or send download links by email, allowing teams to receive the same configured feeds, columns, format and schedule without maintaining cloud-storage credentials.",
"why_it_matters": "Teams optimize locally while harming overall business performance. Revenue data is fragmented across subscriptions, purchases, and ads, making it difficult to understand true user value. Teams make acquisition and monetization decisions based on incomplete or misleading data. Ad spend data lives in ad platforms (Meta, Google, ASA) while revenue data lives in app stores or subscription systems. Without joining these, teams cannot calculate true payback periods, ROAS, or cost-per-trial by channel. Growth teams over-invest in channels that look good on install volume but have poor payback, or under-invest in high-LTV channels because they can't prove ROI. Budgets are allocated based on incomplete signals. Total user value is measured across subscriptions, purchases, and other revenue streams Acquisition and product decisions are based on unified revenue truth rather than partial signals",
"constraints_limits": "Downstream data quality depends on warehouse modeling and join keys. Email delivery supports up to 25 recipients and an optional subject prefix. Each export sends download links rather than attachments; links expire after seven days.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/integrations/scheduled-data-exports",
"decisions_enabled": [
"Should revenue data be unified across platforms and products?"
],
"canonical_problems": [
"We don’t understand true user value across revenue streams",
"We can't connect acquisition spend to downstream revenue to measure channel-level payback"
],
"outcomes": [
"Total user value is measured across subscriptions, purchases, and other revenue streams",
"Acquisition and product decisions are based on unified revenue truth rather than partial signals"
],
"proof_points": [
{
"name": "VSCO: 3 integrations consolidated to 1",
"type": "Customer",
"statement": "VSCO reduced integration management from 3 separate data channels to 1 (VSCO to RevenueCat) using RevenueCat native integrations with their marketing stack. \"Using RevenueCat as our single source of reporting for mobile and web helped us eliminate a considerable amount of the backlog across almost every team.\" — Shaheen Essabhoy, Business Intelligence"
},
{
"name": "Foodvisor: 2-3x ARPU growth",
"type": "Customer",
"statement": "Foodvisor achieved 2-3x growth in ARPU since integrating RevenueCat with Amplitude, enabling fast iteration on conversion funnels and pricing models. \"Thanks to the events sent by RevenueCat to Amplitude, we have been able to iterate very fast on our conversion funnels and pricing models, leading to a 2x-3x growth of our ARPU since the first integration.\" — Charles Boes, Chief Product Officer"
},
{
"name": "HOLYWATER: 80% revenue driven by RC-powered marketing",
"type": "Customer",
"statement": "80% of HOLYWATER revenue is driven by paid marketing, powered by RevenueCat data through integrations with AppsFlyer, Amplitude, and webhooks. \"Marketing drives 80% of our revenue, so it is of utmost importance for us to operate with real-time, extensive data. Every day, our team uses RevenueCat data to make decisions.\" — Bogdan Nesvit, Co-Founder and CEO"
},
{
"name": "Ladder: User-level financial reporting",
"type": "Customer",
"statement": "Ladder uses RevenueCat Segment integration to BigQuery for all financial reporting and affiliate-related payouts, providing user-level spend, store fees, offer code usage, and currency data. \"We use the Segment integration to BigQuery extensively for all our financial reporting and affiliate-related payouts at month-end. It is crucial in providing us with precise information on new paying members, renewal metrics, and reactivated members—broken down by dollar amount, currency conversion and product type.\" — Greg Stewart, CEO"
},
{
"name": "Runna: 8% CAC reduction",
"type": "Customer",
"statement": "Runna achieved an 8% decrease in cost of acquisition by using RevenueCat + AppsFlyer integration to identify and eliminate spending in underperforming markets. \"Through the use of AppsFlyer and RevenueCat, we have been able to identify a set of markets that were driving our CAC up considerably. Eliminating spending in these regions decreased our CAC by 8%.\" — Walter Holohan, CTO"
},
{
"name": "Runna: 56% trial conversion improvement on ASA",
"type": "Customer",
"statement": "Runna achieved a 56% improvement in trial conversion rate on Apple Search Ads for US campaigns by using RevenueCat + AppsFlyer integration to optimize for top converting keywords. \"We also utilize RevenueCat events in AppsFlyer to ensure we are optimizing our Apple Search Ads performance based on top converting keywords rather than optimizing for upper funnel events. This has improved our trial conversion rate on ASA for US campaigns by 56%.\" — Walter Holohan, CTO"
},
{
"name": "Runna: 5.7% trial conversion improvement via product",
"type": "Customer",
"statement": "Runna achieved a 5.7% increase in trial conversion rates by using RevenueCat + Mixpanel integration to identify valuable user behaviors (calendar connections) and transform them into product improvements. \"We have been able to identify key traits of users with the highest trial conversion rate. We found that those who connect a calendar have a better retention rate... Identifying valuable user behaviors with the Mixpanel integration and transforming them into product improvements has led to a 5.7% increase in trial conversion rates for Runna.\" — Walter Holohan, CTO"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/data_export_and_warehouse_integrations.json"
}
},
{
"id": "entitlement_resolution_engine",
"name": "Entitlement resolution engine",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"Android",
"iOS",
"Web",
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Web purchases"
],
"what_it_does": "Determines which entitlements (features, content, access) a user should have at any given time based on purchases, promotions, and configuration.",
"why_it_matters": "Access is inconsistent or delayed, creating support issues. User access does not reliably reflect their current monetization state. Users lose access incorrectly, retain access when they shouldn’t, or contact support, eroding trust and increasing operational cost. Users retain access too long or lose it prematurely. Monetization behavior becomes inconsistent across platforms, teams, and codebases. Maintaining monetization systems over time diverts engineering effort away from building the core product. Monetization systems fall behind platform changes, bugs accumulate, and engineers spend increasing time maintaining revenue infrastructure instead of improving the product. Access changes are strictly tied to transactions, making it difficult to offer recovery paths such as reverse trials, goodwill access, or re-engagement experiences without refunds or code changes. This reduces flexibility in retention and winback strategies and increases friction for both users and teams. Users reduce spending or cancel before the business realizes the full value of the relationship. Revenue declines silently as users leave without any attempt at intervention or recovery. Users immediately receive the correct access after purchase Access revokes correctly and predictably when spending stops Monetization systems stay reliable and current without ongoing internal maintenance burden Platform feature adoption happens quickly without major engineering projects Cancellation intent triggers timely interventions that prevent avoidable churn",
"constraints_limits": "Entitlements must be modeled using RevenueCat’s entitlement system.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/getting-started/entitlements",
"decisions_enabled": [
"What access should this purchase immediately unlock?",
"When should access be revoked after spending stops?",
"Should monetization logic live in one centralized system?",
"Should we grant monetized access without requiring a purchase?"
],
"canonical_problems": [
"Access and entitlements become inconsistent when spending changes",
"We can’t afford to maintain monetization systems long-term",
"Users cancel or disengage before delivering full value"
],
"outcomes": [
"Users immediately receive the correct access after purchase",
"Access revokes correctly and predictably when spending stops",
"Monetization systems stay reliable and current without ongoing internal maintenance burden",
"Platform feature adoption happens quickly without major engineering projects",
"Cancellation intent triggers timely interventions that prevent avoidable churn",
"At-risk users re-engage and remain subscribed long enough to realize value"
],
"proof_points": [
{
"name": "Ladder cross-platform subscribers",
"type": "Customer",
"statement": "Ladder grew from 0 to 100,000 cross-platform subscribers with RevenueCat"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/entitlement_resolution_engine.json"
}
},
{
"id": "exit_and_alternative_offers",
"name": "Exit and alternative offers",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency"
],
"what_it_does": "Presents alternative offers or messaging when a user dismisses or attempts to exit a monetization surface.",
"why_it_matters": "Users hesitate because they don’t fully understand the offer. Users reach a monetization surface without fully understanding why the product is worth paying for. Conversion rates suffer, users churn early, and teams compensate by discounting instead of improving value communication. f we can’t intervene before monetization fully stops, churn is treated as a single irreversible event instead of a process. We miss high-signal intervention windows such as post-cancellation but pre-expiration, and are limited to late winback attempts when user intent and engagement are already low. This reduces retention effectiveness and increases reliance on discounts instead of targeted recovery actions. Users reduce spending or cancel before the business realizes the full value of the relationship. Revenue declines silently as users leave without any attempt at intervention or recovery. Users understand the value proposition before seeing an offer Monetization surfaces align with user intent and the value they care about Cancellation intent triggers timely interventions that prevent avoidable churn At-risk users re-engage and remain subscribed long enough to realize value",
"constraints_limits": "Triggered only at supported exit points.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/tools/customer-center",
"decisions_enabled": [
"What content and explanation should this monetization surface include?",
"Should we intervene before monetization stops?"
],
"canonical_problems": [
"Users don’t understand the value before being asked to pay",
"Users cancel or disengage before delivering full value"
],
"outcomes": [
"Users understand the value proposition before seeing an offer",
"Monetization surfaces align with user intent and the value they care about",
"Cancellation intent triggers timely interventions that prevent avoidable churn",
"At-risk users re-engage and remain subscribed long enough to realize value"
],
"proof_points": [
{
"name": "dub LTV increase",
"type": "Customer",
"statement": "dub increased LTV by 207% with RevenueCat"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/exit_and_alternative_offers.json"
}
},
{
"id": "experimentation_and_variants_framework",
"name": "Experimentation and variants framework",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web",
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Web purchases"
],
"what_it_does": "Enables running controlled experiments by creating variants of monetization experiences (e.g., paywalls, offers, pricing presentation, and web funnel branches), measuring outcomes, and predicting long-term revenue impact (12-month LTV) to identify the optimal variant. Includes experiment steps inside web funnels that randomly route visitors across multiple branches and report results alongside other experiments. Experiment results are computed in near-real-time, typically available within seconds of events occurring.",
"why_it_matters": "Monetization becomes a series of permanent guesses instead of a measurable optimization loop. Improvements slow down because changes require higher confidence upfront, teams ship fewer iterations, and you can’t reliably attribute revenue changes to specific choices. Over time, you either stagnate on a suboptimal setup or rely on blunt levers like price cuts because you lack a safe way to test and learn. It’s difficult to experiment with pricing, packaging, and monetization surfaces and understand what improves revenue. Teams rely on intuition, make slow changes, or avoid experimentation entirely, leading to suboptimal monetization. Teams can run experiments quickly and confidently measure impact Experimentation becomes continuous, compounding small gains over time",
"constraints_limits": "Experiment validity depends on correct traffic allocation, sufficient volume, and consistent instrumentation.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/tools/experiments-v1#:~:text=RevenueCat%20Experiments%20allow%20you%20to,more%20value%20for%20your%20business",
"decisions_enabled": [
"Should we experiment with alternatives instead of committing to a single monetization choice?"
],
"canonical_problems": [
"We don’t know which monetization experiments actually work"
],
"outcomes": [
"Teams can run experiments quickly and confidently measure impact",
"Experimentation becomes continuous, compounding small gains over time"
],
"proof_points": [
{
"name": "RocketSim LTV increase",
"type": "Customer",
"statement": "RocketSim increased LTV by 47% using RevenueCat Experiments"
},
{
"name": "Pixelcut conversion improvement",
"type": "Customer",
"statement": "Pixelcut improved conversion to payer by 16% with a single experiment"
},
{
"name": "Pixery Labs experiment speed improvement",
"type": "Customer",
"statement": "Pixery Labs runs experiments 4-6x faster with RevenueCat"
},
{
"name": "Experiment variants supported",
"type": "Ecosystem",
"statement": "RevenueCat supports up to 4 simultaneous experiment variants"
},
{
"name": "Floga six figures in one day",
"type": "Customer",
"statement": "Floga made six figures in one day pre-launch and commission-free using RevenueCat"
},
{
"name": "MOJO doubles ARPU",
"type": "Customer",
"statement": "MOJO doubled ARPU using RevenueCat for reliable and flexible reporting"
},
{
"name": "MOJO $1M MRR with experiments",
"type": "Customer",
"statement": "MOJO grew to $1M MRR with paywall and pricing experiments using RevenueCat"
},
{
"name": "V1 Sports doubled revenue",
"type": "Customer",
"statement": "V1 Sports doubled revenue with bold bets using RevenueCat"
},
{
"name": "Opal 121 A/B tests",
"type": "Customer",
"statement": "Opal ran 121 A/B tests using RevenueCat experiments to optimize their subscription business"
},
{
"name": "Zumba 52% CPA reduction",
"type": "Customer",
"statement": "Zumba achieved 52% reduction in CPA in just 3 weeks through creative testing and paywall optimization"
},
{
"name": "Pixelcut: Single A/B test paid for all RC costs",
"type": "Customer",
"statement": "A single A/B test using RevenueCat Experiments paid for all of Pixelcut RevenueCat costs. \"This A/B test alone paid for all of RevenueCat costs. Being able to find a variant that produces a 16% increase in subscribers definitely makes RevenueCat worth it.\" — Dominique Yahyavi, Co-Founder"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/experimentation_and_variants_framework.json"
}
},
{
"id": "high_value_user_identification_signals",
"name": "High-value user identification signals",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web",
"Cross-platform"
],
"monetization_primitives": [
"One-time",
"Subscription",
"In-App Currency",
"Ads",
"Web purchases"
],
"what_it_does": "Surfaces signals and aggregated user value indicators that allow customers to identify users who should be treated differently due to their revenue contribution.",
"why_it_matters": "We default to a one-size-fits-all monetization approach, which under-monetizes high-value users and caps revenue upside. Without this decision, we can’t consistently tailor paywalls, pricing, offers, retention efforts, or recovery flows to the users who contribute the most value, reducing ARPU, LTV, and margin potential. Users with high willingness to pay are not identified or offered tailored upsell opportunities. Teams leave significant revenue on the table by treating high-spending users the same as everyone else. High-value users are identified and shown appropriate upsell offers Repeat purchase and upsell programs increase revenue without harming retention",
"constraints_limits": "High-value definitions vary by business; customers must align on thresholds and how to use the signal.",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/customers/customer-attributes",
"decisions_enabled": [
"Is this a user we should treat differently because of their value?"
],
"canonical_problems": [
"High-value users are under-monetized"
],
"outcomes": [
"High-value users are identified and shown appropriate upsell offers",
"Repeat purchase and upsell programs increase revenue without harming retention"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/high_value_user_identification_signals.json"
}
},
{
"id": "messaging_and_crm_integrations",
"name": "Messaging and CRM integrations",
"mechanism_type": "Integration",
"status": "GA",
"platforms": [
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Web purchases"
],
"what_it_does": "Integrates monetization events and user context with messaging, CRM, and engagement tools such as Braze, OneSignal, Firebase, Intercom, and Zendesk.",
"why_it_matters": "Users who have already decided to leave will coast to expiration with no targeted intervention, meaning preventable churn is treated as inevitable. We lose the chance to tailor messaging or offers during the highest-signal window (post-cancel, pre-expiration), and winback efforts shift later when intent and engagement are lower, reducing effectiveness and increasing discount dependency. Users reduce spending or cancel before the business realizes the full value of the relationship. Revenue declines silently as users leave without any attempt at intervention or recovery. All monetization actions must be tied to visible in-app surfaces, limiting our ability to respond to high-signal events like cancellation, refund requests, or expiration in real time. This forces late or manual interventions and reduces the effectiveness of retention, recovery, and support-driven monetization actions. f we can’t intervene before monetization fully stops, churn is treated as a single irreversible event instead of a process. We miss high-signal intervention windows such as post-cancellation but pre-expiration, and are limited to late winback attempts when user intent and engagement are already low. This reduces retention effectiveness and increases reliance on discounts instead of targeted recovery actions. Cancellation intent triggers timely interventions that prevent avoidable churn At-risk users re-engage and remain subscribed long enough to realize value",
"constraints_limits": "Dependent on capabilities of integrated third-party tools.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/integrations/third-party-integrations",
"decisions_enabled": [
"Should we take action when a user cancels, even if they still have access?",
"Should we take monetization actions without showing an in-app surface?",
"Should we intervene before monetization stops?"
],
"canonical_problems": [
"Users cancel or disengage before delivering full value"
],
"outcomes": [
"Cancellation intent triggers timely interventions that prevent avoidable churn",
"At-risk users re-engage and remain subscribed long enough to realize value"
],
"proof_points": [
{
"name": "dub LTV increase",
"type": "Customer",
"statement": "dub increased LTV by 207% with RevenueCat"
},
{
"name": "VSCO membership churn reduction",
"type": "Customer",
"statement": "VSCO reduced membership churn by almost 5% using RevenueCat and Braze integration"
},
{
"name": "Runna: 93.6% CSAT score",
"type": "Customer",
"statement": "Runna achieved a 93.6% CSAT score over 4 weeks using RevenueCat + Intercom integration for subscription management and win-back campaigns. \"Our integration with Intercom helps our customer experience team effortlessly manage subscriptions. We also use it for win-back campaigns and a free trial transparency campaign... This all contributes to our strong CSAT score of 93.6% over the last 4 weeks.\" — Walter Holohan, CTO"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/messaging_and_crm_integrations.json"
}
},
{
"id": "mobile_and_ambient_performance_monitoring",
"name": "Mobile and ambient performance monitoring",
"mechanism_type": "Surface",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web",
"Other",
"Cross-platform"
],
"monetization_primitives": [
"Future / unknown",
"Web purchases",
"Ads",
"In-App Currency",
"One-time",
"Subscription"
],
"what_it_does": "Provides mobile app views, push notifications, and chat integrations that let teams monitor monetization performance without actively checking dashboards. The mobile apps also support AI-assisted questions, user-approved actions, and conversational paywall editing and publication.",
"why_it_matters": "Monetization performance is only visible when someone actively checks dashboards, making it easy to miss early warning signs such as anomalies, regressions, or deteriorating trends. Teams react later than they should, small issues compound into larger revenue-impacting problems, and leadership lacks continuous confidence in the health of the business. Teams lack timely visibility into monetization performance and emerging issues, causing them to react only after revenue-impacting problems have already escalated. Performance regressions, anomalies, and negative trends go unnoticed until they cause meaningful revenue loss. Teams respond late, firefight instead of preventing issues, and leadership lacks real-time confidence in the health of the business. Anomalies and regressions are detected quickly before major revenue impact Teams maintain continuous awareness of monetization health without manual monitoring",
"constraints_limits": "Available actions and authoring features vary by surface. AI actions require user approval and appropriate permissions.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/integrations/third-party-integrations/slack",
"decisions_enabled": [
"Should monetization performance be proactively surfaced rather than passively monitored?"
],
"canonical_problems": [
"Monetization performance issues are detected too late"
],
"outcomes": [
"Anomalies and regressions are detected quickly before major revenue impact",
"Teams maintain continuous awareness of monetization health without manual monitoring"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/mobile_and_ambient_performance_monitoring.json"
}
},
{
"id": "monetization_anomaly_detection_alerts",
"name": "Monetization anomaly detection alerts",
"mechanism_type": "Surface",
"status": "GA",
"platforms": [
"Cross-platform"
],
"monetization_primitives": [
"Future / unknown",
"Web purchases",
"Ads",
"In-App Currency",
"One-time",
"Subscription"
],
"what_it_does": "Automatically detects unusual deviations in monetization metrics and notifies teams via email or other channels when performance diverges from expected patterns.",
"why_it_matters": "Monetization performance is only visible when someone actively checks dashboards, making it easy to miss early warning signs such as anomalies, regressions, or deteriorating trends. Teams react later than they should, small issues compound into larger revenue-impacting problems, and leadership lacks continuous confidence in the health of the business. Teams lack timely visibility into monetization performance and emerging issues, causing them to react only after revenue-impacting problems have already escalated. Performance regressions, anomalies, and negative trends go unnoticed until they cause meaningful revenue loss. Teams respond late, firefight instead of preventing issues, and leadership lacks real-time confidence in the health of the business. Anomalies and regressions are detected quickly before major revenue impact Teams maintain continuous awareness of monetization health without manual monitoring",
"constraints_limits": "Alert quality depends on sufficient historical baselines and stable seasonality; false positives/negatives can occur when traffic is low or patterns shift abruptly.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/dashboard-and-metrics/anomaly-detection-notifications#:~:text=Anomaly%20Detection%20Notifications%20are%20currently,in%20beta",
"decisions_enabled": [
"Should monetization performance be proactively surfaced rather than passively monitored?"
],
"canonical_problems": [
"Monetization performance issues are detected too late"
],
"outcomes": [
"Anomalies and regressions are detected quickly before major revenue impact",
"Teams maintain continuous awareness of monetization health without manual monitoring"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/monetization_anomaly_detection_alerts.json"
}
},
{
"id": "monetization_benchmarking",
"name": "Monetization benchmarking",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [],
"monetization_primitives": [],
"what_it_does": "Provides percentile rankings for subscription metrics (conversion, churn, LTV, refunds) against similar apps by store and category, plus a recommendation identifying the single biggest improvement opportunity relative to peers. Gives teams the external reference frame needed to evaluate whether their monetization performance is strong, acceptable, or structurally underperforming — replacing internal-only targets with market-calibrated standards.",
"why_it_matters": "Teams evaluate monetization performance in isolation, with no external reference frame. A 3% conversion rate or 8% monthly churn looks the same whether it is best-in-class or bottom-quartile for the category. Without peer context, teams either set arbitrary internal targets, over-invest in metrics that are already strong, or miss structural underperformance entirely. Teams measure monetization performance without any external reference frame, making it impossible to know whether their results are strong, acceptable, or structurally underperforming relative to peers in the same category. Teams set targets based on internal history rather than market reality. They optimize metrics that are already competitive while missing structural gaps in metrics where they are bottom-quartile. Monetization strategy is evaluated in a vacuum, leading to misallocated effort and false confidence — or unnecessary alarm — about performance. Teams can evaluate monetization performance against peer benchmarks, replacing internal-only targets with market-calibrated standards",
"constraints_limits": "",
"requires_configuration": false,
"docs_link": "",
"decisions_enabled": [
"How should we determine if our performance metrics are good enough?"
],
"canonical_problems": [
"We don't know what \"good\" looks like for our monetization performance"
],
"outcomes": [
"Teams can evaluate monetization performance against peer benchmarks, replacing internal-only targets with market-calibrated standards"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/monetization_benchmarking.json"
}
},
{
"id": "monetization_config_audit_versioning_rollback",
"name": "Monetization Configuration Audit, Versioning, and Rollback",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"Cross-platform",
"Web"
],
"monetization_primitives": [
"Future / unknown",
"Web purchases",
"Ads",
"In-App Currency",
"Subscription",
"One-time"
],
"what_it_does": "Creates a durable history of monetization configuration changes (who/what/when), supports version snapshots, and enables rollback to a known-good configuration when a change causes conversion, revenue, or access regressions. In the Paywall Editor, version history now shows the author of each saved version, surfaces a Current Draft item when unsaved changes exist (with a Discard action), and presents a cleaner scrollable version list with footer actions (Preview in app, Save version).",
"why_it_matters": "All users are shown the same monetization experience regardless of their goals, intent, or context. This reduces relevance and conversion, forces generic paywalls and offers, and limits the ability to tailor monetization to different user needs, leading to lower performance across the funnel. Different users are shown the same prices, offers, and monetization surfaces despite having different willingness to pay. High-value users are under-monetized while low-value users are over-priced, hurting both revenue and user experience. Monetization performance is only visible when someone actively checks dashboards, making it easy to miss early warning signs such as anomalies, regressions, or deteriorating trends. Teams react later than they should, small issues compound into larger revenue-impacting problems, and leadership lacks continuous confidence in the health of the business. Teams lack timely visibility into monetization performance and emerging issues, causing them to react only after revenue-impacting problems have already escalated. Performance regressions, anomalies, and negative trends go unnoticed until they cause meaningful revenue loss. Teams respond late, firefight instead of preventing issues, and leadership lacks real-time confidence in the health of the business. Monetization becomes a series of permanent guesses instead of a measurable optimization loop. Improvements slow down because changes require higher confidence upfront, teams ship fewer iterations, and you can’t reliably attribute revenue changes to specific choices. Over time, you either stagnate on a suboptimal setup or rely on blunt levers like price cuts because you lack a safe way to test and learn. It’s difficult to experiment with pricing, packaging, and monetization surfaces and understand what improves revenue. Teams rely on intuition, make slow changes, or avoid experimentation entirely, leading to suboptimal monetization. Monetization decisions remain implicitly owned by engineering, even when they are driven by product, growth, or business needs. This increases iteration cost, slows experimentation, creates hidden queues and dependencies, and pushes teams toward fewer, higher-risk changes instead of continuous optimization. Over time, monetization strategy becomes constrained by deployment cycles rather than user insight. Maintaining monetization systems over time diverts engineering effort away from building the core product. Monetization systems fall behind platform changes, bugs accumulate, and engineers spend increasing time maintaining revenue infrastructure instead of improving the product. Monetization experiences are tailored by segment to improve conversion and LTV Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience Anomalies and regressions are detected quickly before major revenue impact Teams maintain continuous awareness of monetization health without manual monitoring Teams can run experiments quickly and confidently measure impact",
"constraints_limits": "Audit/versioning/rollback is about configuration state, not data correctness. If the underlying event stream is delayed or incorrect, rolling back config won’t fix that. It also won’t replace a true “approval workflow” (which is a separate concept and I’m not recommending adding yet).",
"requires_configuration": false,
"docs_link": "",
"decisions_enabled": [
"Should monetization logic adapt based on user intent or context?",
"Should monetization performance be proactively surfaced rather than passively monitored?",
"Should we experiment with alternatives instead of committing to a single monetization choice?",
"Who should own monetization decisions inside an organization?"
],
"canonical_problems": [
"All users are monetized the same way",
"Monetization performance issues are detected too late",
"We don’t know which monetization experiments actually work",
"We can’t afford to maintain monetization systems long-term"
],
"outcomes": [
"Monetization experiences are tailored by segment to improve conversion and LTV",
"Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience",
"Anomalies and regressions are detected quickly before major revenue impact",
"Teams maintain continuous awareness of monetization health without manual monitoring",
"Teams can run experiments quickly and confidently measure impact",
"Experimentation becomes continuous, compounding small gains over time",
"Monetization systems stay reliable and current without ongoing internal maintenance burden",
"Platform feature adoption happens quickly without major engineering projects"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/monetization_config_audit_versioning_rollback.json"
}
},
{
"id": "monetization_lifecycle_events_and_webhooks",
"name": "Monetization lifecycle events and webhooks",
"mechanism_type": "API",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web",
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Web purchases"
],
"what_it_does": "Emits real-time events for key monetization lifecycle moments such as trial cancellation, subscription expiration, refunds, and entitlement changes, enabling external systems to react immediately.",
"why_it_matters": "Users who have already decided to leave will coast to expiration with no targeted intervention, meaning preventable churn is treated as inevitable. We lose the chance to tailor messaging or offers during the highest-signal window (post-cancel, pre-expiration), and winback efforts shift later when intent and engagement are lower, reducing effectiveness and increasing discount dependency. Users reduce spending or cancel before the business realizes the full value of the relationship. Revenue declines silently as users leave without any attempt at intervention or recovery. All monetization actions must be tied to visible in-app surfaces, limiting our ability to respond to high-signal events like cancellation, refund requests, or expiration in real time. This forces late or manual interventions and reduces the effectiveness of retention, recovery, and support-driven monetization actions. f we can’t intervene before monetization fully stops, churn is treated as a single irreversible event instead of a process. We miss high-signal intervention windows such as post-cancellation but pre-expiration, and are limited to late winback attempts when user intent and engagement are already low. This reduces retention effectiveness and increases reliance on discounts instead of targeted recovery actions. Cancellation intent triggers timely interventions that prevent avoidable churn At-risk users re-engage and remain subscribed long enough to realize value",
"constraints_limits": "Events are limited to supported lifecycle states and delivery guarantees.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/integrations/webhooks",
"decisions_enabled": [
"Should we take action when a user cancels, even if they still have access?",
"Should we take monetization actions without showing an in-app surface?",
"Should we intervene before monetization stops?"
],
"canonical_problems": [
"Users cancel or disengage before delivering full value"
],
"outcomes": [
"Cancellation intent triggers timely interventions that prevent avoidable churn",
"At-risk users re-engage and remain subscribed long enough to realize value"
],
"proof_points": [
{
"name": "dub: 61% voluntary churn reduction",
"type": "Customer",
"statement": "dub reduced voluntary churn by 61% using RevenueCat event tracking to enable automated win-back campaigns including paywall exit offers, trial cancellation incentives, and annual plan switch offers. \"We get them in pre-subscription, during trial, and post-trial… all of these win-back campaigns have been crucial for retention.\" — Brett Chereskin, COO"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/monetization_lifecycle_events_and_webhooks.json"
}
},
{
"id": "multipage_paywalls",
"name": "Multipage Paywalls",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web",
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency"
],
"what_it_does": "Enables teams to build multi-screen paywall flows (workflows) where users move through a linear sequence of steps — such as an onboarding-style flow that introduces the app before the purchase screen. Built on a new workflows system that supports transitions between steps; branching, checkpoints, and other flow shapes will extend the same foundation. Multipage paywalls are served from a new config endpoint (static files) rather than /offerings, enabling faster load times especially for apps with many paywalls. SDK support is automatic on the latest SDK with no code changes required.",
"why_it_matters": "Users hesitate because they don’t fully understand the offer. Users reach a monetization surface without fully understanding why the product is worth paying for. Conversion rates suffer, users churn early, and teams compensate by discounting instead of improving value communication. Users are funneled into suboptimal monetization paths. Different users are shown the same prices, offers, and monetization surfaces despite having different willingness to pay. High-value users are under-monetized while low-value users are over-priced, hurting both revenue and user experience. Users understand the value proposition before seeing an offer Monetization surfaces align with user intent and the value they care about Monetization experiences are tailored by segment to improve conversion and LTV Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience",
"constraints_limits": "",
"requires_configuration": true,
"docs_link": "",
"decisions_enabled": [
"What content and explanation should this monetization surface include?",
"Which monetization surface should this user see first?"
],
"canonical_problems": [
"Users don’t understand the value before being asked to pay",
"All users are monetized the same way"
],
"outcomes": [
"Users understand the value proposition before seeing an offer",
"Monetization surfaces align with user intent and the value they care about",
"Monetization experiences are tailored by segment to improve conversion and LTV",
"Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/multipage_paywalls.json"
}
},
{
"id": "native_in_app_paywalls",
"name": "Native in-app paywalls",
"mechanism_type": "SDK",
"status": "GA",
"platforms": [
"Android",
"iOS"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency"
],
"what_it_does": "Displays in-app monetization surfaces that present pricing, plans, and value messaging to users inside the app. Supports branded fallback paywalls, multi-screen paywall flows, and customizable interactive content alongside native purchase controls, enabling teams to create branded, flexible purchase experiences. Teams can change packages, pricing, copy or styling according to the selected tab. Supported SDK callbacks expose Paywall component interactions for app-owned analytics.",
"why_it_matters": "Users hesitate because they don’t fully understand the offer. Users reach a monetization surface without fully understanding why the product is worth paying for. Conversion rates suffer, users churn early, and teams compensate by discounting instead of improving value communication. Users are funneled into suboptimal monetization paths. Different users are shown the same prices, offers, and monetization surfaces despite having different willingness to pay. High-value users are under-monetized while low-value users are over-priced, hurting both revenue and user experience. Users are asked to pay before perceiving value, hurting trust and conversion. Users understand the value proposition before seeing an offer Monetization surfaces align with user intent and the value they care about Monetization experiences are tailored by segment to improve conversion and LTV Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience",
"constraints_limits": "Subject to platform UI and policy constraints. Tab-based rules start from the configured default tab when the paywall opens. Interaction callback availability depends on the SDK.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/tools/paywalls",
"decisions_enabled": [
"What content and explanation should this monetization surface include?",
"Which monetization surface should this user see first?",
"Has this user experienced enough value to justify showing a monetization surface?"
],
"canonical_problems": [
"Users don’t understand the value before being asked to pay",
"All users are monetized the same way"
],
"outcomes": [
"Users understand the value proposition before seeing an offer",
"Monetization surfaces align with user intent and the value they care about",
"Monetization experiences are tailored by segment to improve conversion and LTV",
"Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience"
],
"proof_points": [
{
"name": "Pixelcut conversion improvement",
"type": "Customer",
"statement": "Pixelcut improved conversion to payer by 16% with a single experiment"
},
{
"name": "Photoroom trial rates in Japan",
"type": "Customer",
"statement": "Photoroom achieved 2-3x trial rates in Japan"
},
{
"name": "Photoroom upsell screen conversions",
"type": "Customer",
"statement": "Photoroom achieved 50% increase in upsell screen conversions"
},
{
"name": "HOLYWATER revenue growth",
"type": "Customer",
"statement": "HOLYWATER grew from $0 to $70M annual revenue with RevenueCat"
},
{
"name": "Fintech app paywall conversion improvement",
"type": "Other",
"statement": "Fintech app paywall redesign lifted conversion rate by over 20% (to 3.24%)"
},
{
"name": "Driver license prep app ARPU boost",
"type": "Other",
"statement": "Driver license prep app paywall redesign achieved 17.02% boost in ARPU"
},
{
"name": "Party game app conversion and revenue lift",
"type": "Other",
"statement": "Party game app paywall redesign achieved 31% increase in install-to-trial conversions and 64% uplift in revenue"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/native_in_app_paywalls.json"
}
},
{
"id": "oauth_client_management",
"name": "OAuth Client Management",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"Web"
],
"monetization_primitives": [],
"what_it_does": "Provides developers a self-service dashboard to view all third-party OAuth clients that hold active refresh tokens for their RevenueCat account, and to revoke any of those tokens on demand. Eliminates the need to contact support or engineering to remove unauthorized or stale third-party access.",
"why_it_matters": "Either monetization becomes locked behind engineers or changes introduce risk and errors. Maintaining monetization systems over time diverts engineering effort away from building the core product. Monetization systems fall behind platform changes, bugs accumulate, and engineers spend increasing time maintaining revenue infrastructure instead of improving the product. Engineering becomes a bottleneck for routine monetization and support work. Support teams lack the tools to investigate and resolve monetization and access issues independently. Support escalations increase, engineering time is wasted, and user trust erodes. Monetization systems stay reliable and current without ongoing internal maintenance burden Platform feature adoption happens quickly without major engineering projects Support resolves monetization state issues without engineering involvement Customers get faster, higher-trust resolutions to purchase and entitlement issues",
"constraints_limits": "Only covers OAuth clients using the RevenueCat OAuth flow. Does not cover API key management or personal access tokens.",
"requires_configuration": false,
"docs_link": "",
"decisions_enabled": [
"Who should be able to change monetization behavior safely?",
"Which teams should depend on engineering to resolve monetization issues?"
],
"canonical_problems": [
"We can’t afford to maintain monetization systems long-term",
"Support teams can’t resolve monetization issues without engineering"
],
"outcomes": [
"Monetization systems stay reliable and current without ongoing internal maintenance burden",
"Platform feature adoption happens quickly without major engineering projects",
"Support resolves monetization state issues without engineering involvement",
"Customers get faster, higher-trust resolutions to purchase and entitlement issues"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/oauth_client_management.json"
}
},
{
"id": "paywall_custom_variables",
"name": "Paywall custom variables",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency"
],
"what_it_does": "Allows developers to define custom variables in the Paywall Editor with default values that can be overridden through SDK calls at runtime, enabling dynamic paywall content based on user context, A/B tests, or regional requirements without code changes.",
"why_it_matters": "Users hesitate because they don’t fully understand the offer. Users reach a monetization surface without fully understanding why the product is worth paying for. Conversion rates suffer, users churn early, and teams compensate by discounting instead of improving value communication. Users understand the value proposition before seeing an offer Monetization surfaces align with user intent and the value they care about",
"constraints_limits": "Variables are global across all paywalls. Older SDK versions do not display default values.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/tools/paywalls/creating-paywalls/variables#custom-variables",
"decisions_enabled": [
"What content and explanation should this monetization surface include?"
],
"canonical_problems": [
"Users don’t understand the value before being asked to pay"
],
"outcomes": [
"Users understand the value proposition before seeing an offer",
"Monetization surfaces align with user intent and the value they care about"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/paywall_custom_variables.json"
}
},
{
"id": "paywall_templates_and_variants",
"name": "Paywall templates and layout variants",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency"
],
"what_it_does": "Allows teams to configure different paywall layouts, messaging structures, visual hierarchies, and locale-specific content without shipping new code. Includes locale management directly in the editor switcher (add/remove locales, set default locale) for both paywalls and funnels, enabling multi-market monetization surfaces without engineering involvement.",
"why_it_matters": "Users hesitate because they don’t fully understand the offer. Users reach a monetization surface without fully understanding why the product is worth paying for. Conversion rates suffer, users churn early, and teams compensate by discounting instead of improving value communication. Monetization becomes a series of permanent guesses instead of a measurable optimization loop. Improvements slow down because changes require higher confidence upfront, teams ship fewer iterations, and you can’t reliably attribute revenue changes to specific choices. Over time, you either stagnate on a suboptimal setup or rely on blunt levers like price cuts because you lack a safe way to test and learn. It’s difficult to experiment with pricing, packaging, and monetization surfaces and understand what improves revenue. Teams rely on intuition, make slow changes, or avoid experimentation entirely, leading to suboptimal monetization. Users understand the value proposition before seeing an offer Monetization surfaces align with user intent and the value they care about Teams can run experiments quickly and confidently measure impact Experimentation becomes continuous, compounding small gains over time",
"constraints_limits": "Templates must conform to supported components and layouts.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/tools/paywalls/creating-paywalls",
"decisions_enabled": [
"What content and explanation should this monetization surface include?",
"Should we experiment with alternatives instead of committing to a single monetization choice?"
],
"canonical_problems": [
"Users don’t understand the value before being asked to pay",
"We don’t know which monetization experiments actually work"
],
"outcomes": [
"Users understand the value proposition before seeing an offer",
"Monetization surfaces align with user intent and the value they care about",
"Teams can run experiments quickly and confidently measure impact",
"Experimentation becomes continuous, compounding small gains over time"
],
"proof_points": [
{
"name": "Photoroom upsell screen conversions",
"type": "Customer",
"statement": "Photoroom achieved 50% increase in upsell screen conversions"
},
{
"name": "Fintech app paywall conversion improvement",
"type": "Other",
"statement": "Fintech app paywall redesign lifted conversion rate by over 20% (to 3.24%)"
},
{
"name": "Driver license prep app ARPU boost",
"type": "Other",
"statement": "Driver license prep app paywall redesign achieved 17.02% boost in ARPU"
},
{
"name": "Party game app conversion and revenue lift",
"type": "Other",
"statement": "Party game app paywall redesign achieved 31% increase in install-to-trial conversions and 64% uplift in revenue"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/paywall_templates_and_variants.json"
}
},
{
"id": "platform_change_absorption",
"name": "Platform change absorption and updates",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web"
],
"monetization_primitives": [
"Future / unknown",
"Web purchases",
"In-App Currency",
"One-time",
"Subscription"
],
"what_it_does": "Continuously adapts RevenueCat’s systems to new billing APIs, policy changes, and store requirements without customer intervention.",
"why_it_matters": "The team drifts into partial ownership, inheriting long-term costs without committing to a clear strategy. We need to decide whether to build and maintain our own monetization infrastructure or rely on a platform to handle it for us. Teams delay monetization, accumulate technical debt, or later discover they are locked into fragile systems that slow product development and prevent pursuing new revenue opportunities. Teams react late to platform changes, causing revenue disruption and emergency work. Changes in platform APIs, policies, or billing rules introduce risk to existing monetization strategies. Revenue breaks unexpectedly, compliance issues arise, or teams scramble reactively to fix problems under time pressure. Monetization infrastructure is shipped without derailing the core product roadmap Engineering time stays focused on product differentiation instead of monetization plumbing Platform changes do not break revenue or compliance Store policy or billing API updates are handled proactively rather than as firefights",
"constraints_limits": "Limited to what platforms expose and permit.",
"requires_configuration": false,
"docs_link": "",
"decisions_enabled": [
"Do we want to own monetization infrastructure long-term?",
"Who is responsible for tracking and responding to platform API changes?"
],
"canonical_problems": [
"Do we build or buy monetization infrastructure?",
"Platform and policy changes create monetization risk"
],
"outcomes": [
"Monetization infrastructure is shipped without derailing the core product roadmap",
"Engineering time stays focused on product differentiation instead of monetization plumbing",
"Platform changes do not break revenue or compliance",
"Store policy or billing API updates are handled proactively rather than as firefights"
],
"proof_points": [
{
"name": "Pixery Labs engineering hours saved",
"type": "Customer",
"statement": "Pixery Labs saves 6,000+ engineering hours per year with RevenueCat"
},
{
"name": "OpenAI: Features delivered in hours/days not weeks",
"type": "Customer",
"statement": "RevenueCat turned around feature requests for OpenAI in hours or days, not weeks. \"When OpenAI needed a feature or adjustment, we turned it around fast—in some cases hours or days, not weeks.\" — Miguel Carranza, CTO and Co-founder, RevenueCat"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/platform_change_absorption.json"
}
},
{
"id": "play_store_promotional_offers",
"name": "Play Store promotional offers and product change handling",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"Android"
],
"monetization_primitives": [
"Subscription"
],
"what_it_does": "Allows developers to configure Google Play promotional offer identifiers for packages and manage product change behavior to prevent duplicate subscriptions when users switch between products.",
"why_it_matters": "Pricing optimizes for averages instead of maximizing revenue. Users show intent to pay but hesitate or abandon when presented with a monetization surface. High-intent users leave without converting, resulting in lost revenue that cannot be recovered later. Revenue ceiling is artificially capped. Users with high willingness to pay are not identified or offered tailored upsell opportunities. Teams leave significant revenue on the table by treating high-spending users the same as everyone else. Messaging remains generic and fails to resonate with user intent. Users reach a monetization surface without fully understanding why the product is worth paying for. Conversion rates suffer, users churn early, and teams compensate by discounting instead of improving value communication. High-intent users convert instead of abandoning paywalls Exit offers and alternatives recover would-have-been lost conversions without harming pricing integrity High-value users are identified and shown appropriate upsell offers Repeat purchase and upsell programs increase revenue without harming retention Users understand the value proposition before seeing an offer",
"constraints_limits": "Limited to Google Play promotional offer system capabilities. Product change behavior depends on Google Play billing rules.",
"requires_configuration": true,
"docs_link": "",
"decisions_enabled": [
"What pricing and packaging should this user see?",
"Should this user see premium-only offers or bundles?",
"What value should we emphasize to this user right now?"
],
"canonical_problems": [
"Users hesitate or abandon monetization surfaces",
"High-value users are under-monetized",
"Users don’t understand the value before being asked to pay"
],
"outcomes": [
"High-intent users convert instead of abandoning paywalls",
"Exit offers and alternatives recover would-have-been lost conversions without harming pricing integrity",
"High-value users are identified and shown appropriate upsell offers",
"Repeat purchase and upsell programs increase revenue without harming retention",
"Users understand the value proposition before seeing an offer",
"Monetization surfaces align with user intent and the value they care about"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/play_store_promotional_offers.json"
}
},
{
"id": "policy_compliance_and_platform_requirements_handling",
"name": "Policy compliance and platform requirement handling",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web",
"Other"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Web purchases",
"Future / unknown"
],
"what_it_does": "Ensures ongoing compliance with evolving store policies, billing requirements, and platform rules without requiring customer intervention.",
"why_it_matters": "The team drifts into partial ownership, inheriting long-term costs without committing to a clear strategy. We need to decide whether to build and maintain our own monetization infrastructure or rely on a platform to handle it for us. Teams delay monetization, accumulate technical debt, or later discover they are locked into fragile systems that slow product development and prevent pursuing new revenue opportunities. Teams react late to platform changes, causing revenue disruption and emergency work. Changes in platform APIs, policies, or billing rules introduce risk to existing monetization strategies. Revenue breaks unexpectedly, compliance issues arise, or teams scramble reactively to fix problems under time pressure. Monetization infrastructure is shipped without derailing the core product roadmap Engineering time stays focused on product differentiation instead of monetization plumbing Platform changes do not break revenue or compliance Store policy or billing API updates are handled proactively rather than as firefights",
"constraints_limits": "Limited to what platforms require and enforce.",
"requires_configuration": false,
"docs_link": "",
"decisions_enabled": [
"Do we want to own monetization infrastructure long-term?",
"Who is responsible for tracking and responding to platform API changes?"
],
"canonical_problems": [
"Do we build or buy monetization infrastructure?",
"Platform and policy changes create monetization risk"
],
"outcomes": [
"Monetization infrastructure is shipped without derailing the core product roadmap",
"Engineering time stays focused on product differentiation instead of monetization plumbing",
"Platform changes do not break revenue or compliance",
"Store policy or billing API updates are handled proactively rather than as firefights"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/policy_compliance_and_platform_requirements_handling.json"
}
},
{
"id": "pre_install_and_pre_sale_monetization",
"name": "Pre-install and pre-sale monetization",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"Web"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Web purchases"
],
"what_it_does": "Enables monetization before app installation, allowing high-intent users to purchase or unlock access off-platform prior to downloading the app.",
"why_it_matters": "All monetization is constrained to app store flows and fees, even for high-intent users reached through owned or off-platform channels. This limits pricing flexibility, reduces margin, and prevents monetizing demand that exists before installation. Different users are shown the same prices, offers, and monetization surfaces despite having different willingness to pay. High-value users are under-monetized while low-value users are over-priced, hurting both revenue and user experience. Monetization experiences are tailored by segment to improve conversion and LTV Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience",
"constraints_limits": "Requires off-platform acquisition, payments, and entitlement handoff into the app.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/web/web-billing/configuring-overview",
"decisions_enabled": [
"Should monetization occur outside app store distribution entirely?"
],
"canonical_problems": [
"All users are monetized the same way"
],
"outcomes": [
"Monetization experiences are tailored by segment to improve conversion and LTV",
"Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience"
],
"proof_points": [
{
"name": "CardPointers app store fees saved",
"type": "Customer",
"statement": "CardPointers saved ~27% in app store fees with Stripe integration"
},
{
"name": "Floga pre-launch revenue",
"type": "Customer",
"statement": "Floga generated six figures in revenue in one day pre-launch with commission-free web billing"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/pre_install_and_pre_sale_monetization.json"
}
},
{
"id": "promotional_non_purchase_entitlements",
"name": "Promotional and non-purchase entitlements",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web",
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"In-App Currency",
"Web purchases"
],
"what_it_does": "Allows granting time-bound or conditional access without a purchase, including promotional entitlements, reverse trials, and goodwill access.",
"why_it_matters": "Access is inconsistent or delayed, creating support issues. User access does not reliably reflect their current monetization state. Users lose access incorrectly, retain access when they shouldn’t, or contact support, eroding trust and increasing operational cost. Users who have already decided to leave will coast to expiration with no targeted intervention, meaning preventable churn is treated as inevitable. We lose the chance to tailor messaging or offers during the highest-signal window (post-cancel, pre-expiration), and winback efforts shift later when intent and engagement are lower, reducing effectiveness and increasing discount dependency. Users reduce spending or cancel before the business realizes the full value of the relationship. Revenue declines silently as users leave without any attempt at intervention or recovery. f we can’t intervene before monetization fully stops, churn is treated as a single irreversible event instead of a process. We miss high-signal intervention windows such as post-cancellation but pre-expiration, and are limited to late winback attempts when user intent and engagement are already low. This reduces retention effectiveness and increases reliance on discounts instead of targeted recovery actions. Access changes are strictly tied to transactions, making it difficult to offer recovery paths such as reverse trials, goodwill access, or re-engagement experiences without refunds or code changes. This reduces flexibility in retention and winback strategies and increases friction for both users and teams. Users immediately receive the correct access after purchase Access revokes correctly and predictably when spending stops Cancellation intent triggers timely interventions that prevent avoidable churn At-risk users re-engage and remain subscribed long enough to realize value",
"constraints_limits": "Access duration and conditions must be predefined in configuration.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/subscription-guidance/subscription-offers",
"decisions_enabled": [
"What access should this purchase immediately unlock?",
"Should we take action when a user cancels, even if they still have access?",
"Should we intervene before monetization stops?",
"Should we grant monetized access without requiring a purchase?"
],
"canonical_problems": [
"Access and entitlements become inconsistent when spending changes",
"Users cancel or disengage before delivering full value"
],
"outcomes": [
"Users immediately receive the correct access after purchase",
"Access revokes correctly and predictably when spending stops",
"Cancellation intent triggers timely interventions that prevent avoidable churn",
"At-risk users re-engage and remain subscribed long enough to realize value"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/promotional_non_purchase_entitlements.json"
}
},
{
"id": "promotional_entitlement_api",
"name": "Promotional entitlement API",
"mechanism_type": "API",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web"
],
"monetization_primitives": [
"Subscription"
],
"what_it_does": "Allows granting time-bound access to entitlements without requiring a purchase, enabling reverse trials, tier previews, and targeted promotional access.",
"why_it_matters": "All monetization actions must be tied to visible in-app surfaces, limiting our ability to respond to high-signal events like cancellation, refund requests, or expiration in real time. This forces late or manual interventions and reduces the effectiveness of retention, recovery, and support-driven monetization actions. Users reduce spending or cancel before the business realizes the full value of the relationship. Revenue declines silently as users leave without any attempt at intervention or recovery. Access changes are strictly tied to transactions, making it difficult to offer recovery paths such as reverse trials, goodwill access, or re-engagement experiences without refunds or code changes. This reduces flexibility in retention and winback strategies and increases friction for both users and teams. Cancellation intent triggers timely interventions that prevent avoidable churn At-risk users re-engage and remain subscribed long enough to realize value",
"constraints_limits": "Entitlements must be predefined and correctly scoped; misuse can grant unintended access; timing and targeting depend on the customer’s logic and identifiers.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/dashboard-and-metrics/customer-profile",
"decisions_enabled": [
"Should we take monetization actions without showing an in-app surface?",
"Should we grant monetized access without requiring a purchase?"
],
"canonical_problems": [
"Users cancel or disengage before delivering full value"
],
"outcomes": [
"Cancellation intent triggers timely interventions that prevent avoidable churn",
"At-risk users re-engage and remain subscribed long enough to realize value"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/promotional_entitlement_api.json"
}
},
{
"id": "promotional_subscription_extension_api",
"name": "Promotional subscription extension API",
"mechanism_type": "API",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web"
],
"monetization_primitives": [
"Subscription"
],
"what_it_does": "Allows programmatic extension of an existing subscription’s renewal date, enabling duration-based pricing incentives such as “buy one year, get one month free.”",
"why_it_matters": "Pricing incentives must be implemented through discounts, refunds, or additional products, increasing operational complexity and limiting how value can be communicated. Teams lose the ability to offer simple, intuitive incentives like “buy one year, get one month free” without introducing technical or billing workarounds. Platform pricing systems limit how incentives can be expressed, forcing teams to rely on discounts, refunds, or additional products to deliver value. Teams resort to workarounds like issuing refunds, creating duplicate SKUs, or changing access tiers, increasing complexity, user confusion, and operational overhead while limiting experimentation with pricing incentives. Time-based incentives can be offered without SKU sprawl, refunds, or operational workarounds Promotions improve conversion without permanently lowering price expectations",
"constraints_limits": "Limited to platforms that support subscription extensions and the rules those platforms enforce; requires correct entitlement/product mapping to ensure access aligns with extended time.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/guides/promotional-subscription-extensions",
"decisions_enabled": [
"Should we be able to modify subscription renewal timing after purchase?"
],
"canonical_problems": [
"Incentives cannot be expressed flexibly within platform pricing systems"
],
"outcomes": [
"Time-based incentives can be offered without SKU sprawl, refunds, or operational workarounds",
"Promotions improve conversion without permanently lowering price expectations"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/promotional_subscription_extension_api.json"
}
},
{
"id": "rc_billing_subscriber_lifecycle_emails",
"name": "RC Billing Subscriber Lifecycle Emails",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"Web"
],
"monetization_primitives": [
"Subscription",
"Web purchases"
],
"what_it_does": "Sends native, state-accurate lifecycle emails directly to subscribers when billing events occur on RevenueCat Billing — including a GRACE_PERIOD email (payment failed, access continues during retry window), a BILLING_RETRY email (still retrying, access still active), and a BILLING_FAILURE_EXPIRED email (retries exhausted, access revoked). Replaces the previous single BILLING_ISSUE email that was sent regardless of grace period state, eliminating subscriber confusion about whether access is still active during retry cycles.",
"why_it_matters": "f we can’t intervene before monetization fully stops, churn is treated as a single irreversible event instead of a process. We miss high-signal intervention windows such as post-cancellation but pre-expiration, and are limited to late winback attempts when user intent and engagement are already low. This reduces retention effectiveness and increases reliance on discounts instead of targeted recovery actions. Users reduce spending or cancel before the business realizes the full value of the relationship. Revenue declines silently as users leave without any attempt at intervention or recovery. Winback timing is suboptimal. After users stop spending, it’s unclear when to re-engage them and what offers are effective. Churned users are either ignored or spammed with generic discounts that perform poorly and hurt margins. Users retain access too long or lose it prematurely. User access does not reliably reflect their current monetization state. Users lose access incorrectly, retain access when they shouldn’t, or contact support, eroding trust and increasing operational cost. Cancellation intent triggers timely interventions that prevent avoidable churn At-risk users re-engage and remain subscribed long enough to realize value Churned users receive timed winback campaigns that drive reactivation Winback incentives are targeted and profitable rather than generic discounting Users immediately receive the correct access after purchase",
"constraints_limits": "RC Billing customers only; does not apply to App Store or Play Store subscriptions. Emails are sent to the subscriber email address on file with the payment provider. Email copy and layout are fixed templates and are not customizable. Branding is lightly customizable: page background color and primary button color are applied from the RevenueCat Billing Appearance editor, and text colors are auto-determined based on contrast. The app name (configured in RC Billing settings) is displayed as the sender, and a support reply-to email address can be configured. Email localization is not supported — emails are sent in English only.",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/web/billing",
"decisions_enabled": [
"Should we intervene before monetization stops?",
"Should expiration trigger immediate reactivation messaging?",
"When should access be revoked after spending stops?"
],
"canonical_problems": [
"Users cancel or disengage before delivering full value",
"We don’t know when or how to win users back after they stop spending",
"Access and entitlements become inconsistent when spending changes"
],
"outcomes": [
"Cancellation intent triggers timely interventions that prevent avoidable churn",
"At-risk users re-engage and remain subscribed long enough to realize value",
"Churned users receive timed winback campaigns that drive reactivation",
"Winback incentives are targeted and profitable rather than generic discounting",
"Users immediately receive the correct access after purchase",
"Access revokes correctly and predictably when spending stops"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/rc_billing_subscriber_lifecycle_emails.json"
}
},
{
"id": "revenue_and_cohort_analytics_dashboards",
"name": "Revenue and cohort analytics dashboards",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Web purchases"
],
"what_it_does": "Provides revenue and cohort reporting (including cohort-based performance over time) to support decisions on pricing, offers, and acquisition focus. Supports chart annotations that allow developers to mark specific dates or date ranges with contextual notes (e.g., price changes, ad campaigns, version releases), making it easier to correlate monetization metric changes with business events. Includes a Refunds chart (plots refund count and dollar amount by refund date) and a Trial Cancellation Rate chart (measures user-driven trial cancellations within configurable timeframes). Each chart now includes a Customers tab that lists the individual subscribers contributing to a given metric, enabling teams to drill into spikes, anomalies, or cohort segments and take targeted action.",
"why_it_matters": "Teams optimize locally while harming overall business performance. Revenue data is fragmented across subscriptions, purchases, and ads, making it difficult to understand true user value. Teams make acquisition and monetization decisions based on incomplete or misleading data. Ad spend data lives in ad platforms (Meta, Google, ASA) while revenue data lives in app stores or subscription systems. Without joining these, teams cannot calculate true payback periods, ROAS, or cost-per-trial by channel. Growth teams over-invest in channels that look good on install volume but have poor payback, or under-invest in high-LTV channels because they can't prove ROI. Budgets are allocated based on incomplete signals. Total user value is measured across subscriptions, purchases, and other revenue streams Acquisition and product decisions are based on unified revenue truth rather than partial signals",
"constraints_limits": "Accuracy depends on correct product configuration and consistent event ingestion across platforms.",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/dashboard-and-metrics/charts",
"decisions_enabled": [
"Should revenue data be unified across platforms and products?"
],
"canonical_problems": [
"We don’t understand true user value across revenue streams",
"We can't connect acquisition spend to downstream revenue to measure channel-level payback"
],
"outcomes": [
"Total user value is measured across subscriptions, purchases, and other revenue streams",
"Acquisition and product decisions are based on unified revenue truth rather than partial signals"
],
"proof_points": [
{
"name": "Dashboard data latency",
"type": "Reliability",
"statement": "Near real-time dashboard with less than 1 hour data latency"
},
{
"name": "Runna year-over-year growth",
"type": "Customer",
"statement": "Runna achieved 30x year-over-year growth with RevenueCat"
},
{
"name": "Pixery Labs capacity freed",
"type": "Customer",
"statement": "Pixery Labs freed 20% of capacity for data science and backend engineering"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/revenue_and_cohort_analytics_dashboards.json"
}
},
{
"id": "claude-code-plugin",
"name": "RevenueCat AI Toolkit",
"mechanism_type": "Integration",
"status": "GA",
"platforms": [
"Cross-platform"
],
"monetization_primitives": [],
"what_it_does": "Brings RevenueCat into AI coding environments through a plugin distributed for Claude Code, OpenAI Codex, Gemini CLI, and Visual Studio Code. The toolkit bundles two things: RevenueCat MCP server configuration (OAuth-authenticated access to the RevenueCat API) and pre-built skills — focused playbooks that guide agents through project setup, SDK integration, paywalls, custom purchase flows, entitlement gating, user identity, testing, troubleshooting, analytics, Customer Center setup, and migration. Developers can ask their agent to configure RevenueCat projects, integrate the Purchases SDK, build and present paywalls, query Charts data, and diagnose purchase issues without leaving their coding environment. Includes skills that guide agents through recurring-revenue forecasting and subscription-app valuation using project data, benchmarks and stated assumptions.",
"why_it_matters": "Engineering becomes a bottleneck for routine monetization and support work. Support teams lack the tools to investigate and resolve monetization and access issues independently. Support escalations increase, engineering time is wasted, and user trust erodes. Every monetization change requires engineering effort and app releases, slowing iteration dramatically. It’s difficult to experiment with pricing, packaging, and monetization surfaces and understand what improves revenue. Teams rely on intuition, make slow changes, or avoid experimentation entirely, leading to suboptimal monetization. Support resolves monetization state issues without engineering involvement Customers get faster, higher-trust resolutions to purchase and entitlement issues Teams can run experiments quickly and confidently measure impact Experimentation becomes continuous, compounding small gains over time",
"constraints_limits": "",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/tools/overview",
"decisions_enabled": [
"Which teams should depend on engineering to resolve monetization issues?",
"Should monetization behavior be configurable without shipping code?"
],
"canonical_problems": [
"Support teams can’t resolve monetization issues without engineering",
"We don’t know which monetization experiments actually work"
],
"outcomes": [
"Support resolves monetization state issues without engineering involvement",
"Customers get faster, higher-trust resolutions to purchase and entitlement issues",
"Teams can run experiments quickly and confidently measure impact",
"Experimentation becomes continuous, compounding small gains over time"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/claude-code-plugin.json"
}
},
{
"id": "revenuecat_capital_proceeds_advance",
"name": "RevenueCat Capital (daily proceeds advances)",
"mechanism_type": "Backend service",
"status": "Beta",
"platforms": [
"iOS"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Web purchases"
],
"what_it_does": "Advances expected app store proceeds to developers (daily payouts), so they can access earned revenue sooner and reinvest in growth; then reconciles and nets out advances/fees when the actual store payouts land.",
"why_it_matters": "Access to earned revenue is constrained by app store payout schedules, slowing reinvestment in user acquisition and growth, increasing cash-flow risk, and forcing teams to delay or scale back otherwise viable opportunities. App stores pay out on delayed schedules, so developers can’t access earned revenue fast enough to reinvest in growth or run the business smoothly. Teams under-invest in UA and product, miss time-sensitive growth windows, and may face cash-flow stress (especially in smaller businesses), even when the app is performing well. Earned revenue becomes available sooner to reinvest in growth Cash flow becomes predictable enough to pursue growth opportunities without operational stress",
"constraints_limits": "Depends on store proceeds data quality and payout timing; requires reconciliation once store payouts land; limited to supported stores/countries/banking rails and to customers who meet eligibility and risk requirements.",
"requires_configuration": true,
"docs_link": "",
"decisions_enabled": [
"Should we accelerate access to earned app revenue by trading future proceeds for cash today?"
],
"canonical_problems": [
"App store payout delays constrain growth and operations"
],
"outcomes": [
"Earned revenue becomes available sooner to reinvest in growth",
"Cash flow becomes predictable enough to pursue growth opportunities without operational stress"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/revenuecat_capital_proceeds_advance.json"
}
},
{
"id": "rico_ai_growth_advisor",
"name": "Rico AI Growth Advisor",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web",
"Amazon",
"Roku"
],
"monetization_primitives": [],
"what_it_does": "Provides a conversational AI agent embedded in the RevenueCat dashboard and in Slack that allows developers and growth teams to ask natural language questions about their monetization performance, metrics, subscription health, and RevenueCat capabilities. Answers are grounded in the user's own project data and RevenueCat documentation. In addition to answering questions, Rico can perform write actions on behalf of the user — such as managing products, entitlements, offerings, packages, and experiments — subject to human-in-the-loop approval. Rico pauses before executing write or destructive actions and requires explicit user approval; destructive operations are visually distinguished with a red Approve button. The dashboard refreshes live after Rico makes changes. Project admins control Rico's access level (Disabled, Read-only, or Read & write with permission) per project in AI Features settings. Uses project data to forecast recurring revenue and explore growth scenarios under stated assumptions.",
"why_it_matters": "Monetization performance is only visible when someone actively checks dashboards, making it easy to miss early warning signs such as anomalies, regressions, or deteriorating trends. Teams react later than they should, small issues compound into larger revenue-impacting problems, and leadership lacks continuous confidence in the health of the business. Teams lack timely visibility into monetization performance and emerging issues, causing them to react only after revenue-impacting problems have already escalated. Performance regressions, anomalies, and negative trends go unnoticed until they cause meaningful revenue loss. Teams respond late, firefight instead of preventing issues, and leadership lacks real-time confidence in the health of the business. Monetization becomes a series of permanent guesses instead of a measurable optimization loop. Improvements slow down because changes require higher confidence upfront, teams ship fewer iterations, and you can’t reliably attribute revenue changes to specific choices. Over time, you either stagnate on a suboptimal setup or rely on blunt levers like price cuts because you lack a safe way to test and learn. It’s difficult to experiment with pricing, packaging, and monetization surfaces and understand what improves revenue. Teams rely on intuition, make slow changes, or avoid experimentation entirely, leading to suboptimal monetization. Anomalies and regressions are detected quickly before major revenue impact Teams maintain continuous awareness of monetization health without manual monitoring Teams can run experiments quickly and confidently measure impact Experimentation becomes continuous, compounding small gains over time",
"constraints_limits": "Available to all RevenueCat projects; access level is controlled per-project by project admins in AI Features settings (Disabled / Read-only / Read & write with permission). Write access requires explicit human approval for each write or destructive action — Rico cannot make changes autonomously. Rate limit: 300 messages per day per user. Project Instructions (persistent context, similar to AGENTS.md) can be configured by project admins to give Rico standing context about the project. Write access and human-in-the-loop approvals apply to the dashboard only; Rico on Slack uses channel-scoped auth (not per-developer) and does not currently support write actions.",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/dashboard-and-metrics/rico",
"decisions_enabled": [
"Should monetization performance be proactively surfaced rather than passively monitored?",
"Should we experiment with alternatives instead of committing to a single monetization choice?"
],
"canonical_problems": [
"Monetization performance issues are detected too late",
"We don’t know which monetization experiments actually work"
],
"outcomes": [
"Anomalies and regressions are detected quickly before major revenue impact",
"Teams maintain continuous awareness of monetization health without manual monitoring",
"Teams can run experiments quickly and confidently measure impact",
"Experimentation becomes continuous, compounding small gains over time"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/rico_ai_growth_advisor.json"
}
},
{
"id": "rbac_monetization_control",
"name": "Roles & permissions for monetization control (RBAC)",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"Web",
"Cross-platform"
],
"monetization_primitives": [
"Future / unknown",
"Web purchases",
"Ads",
"In-App Currency",
"One-time",
"Subscription"
],
"what_it_does": "Defines who can view, change, and publish monetization configuration and actions, with role-based access that lets non-engineering owners safely operate monetization without opening up full admin privileges.",
"why_it_matters": "Monetization behavior becomes inconsistent across platforms, teams, and codebases. Maintaining monetization systems over time diverts engineering effort away from building the core product. Monetization systems fall behind platform changes, bugs accumulate, and engineers spend increasing time maintaining revenue infrastructure instead of improving the product. Monetization performance is only visible when someone actively checks dashboards, making it easy to miss early warning signs such as anomalies, regressions, or deteriorating trends. Teams react later than they should, small issues compound into larger revenue-impacting problems, and leadership lacks continuous confidence in the health of the business. Teams lack timely visibility into monetization performance and emerging issues, causing them to react only after revenue-impacting problems have already escalated. Performance regressions, anomalies, and negative trends go unnoticed until they cause meaningful revenue loss. Teams respond late, firefight instead of preventing issues, and leadership lacks real-time confidence in the health of the business. Monetization becomes a series of permanent guesses instead of a measurable optimization loop. Improvements slow down because changes require higher confidence upfront, teams ship fewer iterations, and you can’t reliably attribute revenue changes to specific choices. Over time, you either stagnate on a suboptimal setup or rely on blunt levers like price cuts because you lack a safe way to test and learn. It’s difficult to experiment with pricing, packaging, and monetization surfaces and understand what improves revenue. Teams rely on intuition, make slow changes, or avoid experimentation entirely, leading to suboptimal monetization. Monetization decisions remain implicitly owned by engineering, even when they are driven by product, growth, or business needs. This increases iteration cost, slows experimentation, creates hidden queues and dependencies, and pushes teams toward fewer, higher-risk changes instead of continuous optimization. Over time, monetization strategy becomes constrained by deployment cycles rather than user insight. Monetization systems stay reliable and current without ongoing internal maintenance burden Platform feature adoption happens quickly without major engineering projects Anomalies and regressions are detected quickly before major revenue impact Teams maintain continuous awareness of monetization health without manual monitoring Teams can run experiments quickly and confidently measure impact",
"constraints_limits": "RBAC doesn’t decide *what* monetization strategy is right. It only controls who can do what, and reduces blast radius. Without auditability and rollback, RBAC alone won’t prevent mistakes, it just scopes who can make them.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/projects/collaborators#:~:text=",
"decisions_enabled": [
"Should monetization logic live in one centralized system?",
"Should monetization performance be proactively surfaced rather than passively monitored?",
"Should we experiment with alternatives instead of committing to a single monetization choice?",
"Who should own monetization decisions inside an organization?"
],
"canonical_problems": [
"We can’t afford to maintain monetization systems long-term",
"Monetization performance issues are detected too late",
"We don’t know which monetization experiments actually work"
],
"outcomes": [
"Monetization systems stay reliable and current without ongoing internal maintenance burden",
"Platform feature adoption happens quickly without major engineering projects",
"Anomalies and regressions are detected quickly before major revenue impact",
"Teams maintain continuous awareness of monetization health without manual monitoring",
"Teams can run experiments quickly and confidently measure impact",
"Experimentation becomes continuous, compounding small gains over time"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/rbac_monetization_control.json"
}
},
{
"id": "server_side_transaction_validation",
"name": "Server-side transaction and receipt validation",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"iOS",
"Android"
],
"monetization_primitives": [
"Subscription",
"One-time"
],
"what_it_does": "Validates transactions and receipts server-side with platform providers to ensure correctness, authenticity, and up-to-date purchase state.",
"why_it_matters": "The team drifts into partial ownership, inheriting long-term costs without committing to a clear strategy. We need to decide whether to build and maintain our own monetization infrastructure or rely on a platform to handle it for us. Teams delay monetization, accumulate technical debt, or later discover they are locked into fragile systems that slow product development and prevent pursuing new revenue opportunities. Monetization systems become under-resourced, brittle, and increasingly risky over time. Maintaining monetization systems over time diverts engineering effort away from building the core product. Monetization systems fall behind platform changes, bugs accumulate, and engineers spend increasing time maintaining revenue infrastructure instead of improving the product. Monetization infrastructure is shipped without derailing the core product roadmap Engineering time stays focused on product differentiation instead of monetization plumbing Monetization systems stay reliable and current without ongoing internal maintenance burden Platform feature adoption happens quickly without major engineering projects",
"constraints_limits": "Subject to platform receipt formats, latency, and validation rules.",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/welcome/building-new",
"decisions_enabled": [
"Do we want to own monetization infrastructure long-term?",
"Are we willing to staff and maintain monetization infrastructure indefinitely?"
],
"canonical_problems": [
"Do we build or buy monetization infrastructure?",
"We can’t afford to maintain monetization systems long-term"
],
"outcomes": [
"Monetization infrastructure is shipped without derailing the core product roadmap",
"Engineering time stays focused on product differentiation instead of monetization plumbing",
"Monetization systems stay reliable and current without ongoing internal maintenance burden",
"Platform feature adoption happens quickly without major engineering projects"
],
"proof_points": [
{
"name": "Platform uptime",
"type": "Reliability",
"statement": "99.99% uptime with bank-grade reliability"
},
{
"name": "Widgetsmith: Zero payment complaints at scale",
"type": "Reliability",
"statement": "Widgetsmith had zero customer complaints about payment processing issues during their massive scale event. \"The best thing I can say for RevenueCat is that I do not think about it. It has always worked. It has never had a problem. I have never had to keep an eye on it or worry about it. At any level of scale, it just works.\" — David Smith, Founder"
},
{
"name": "OpenAI: Millions of subscribers, traffic not noticeable",
"type": "Scale",
"statement": "ChatGPT scaled to millions of subscribers with traffic not yet noticeable in the macro during launch (within normal fluctuations) using RevenueCat infrastructure processing 2+ billion API requests daily. \"With RevenueCat, we never had to slow down. They made it easy to keep our focus on building the best product while ensuring our mission of accessible, safe AI for everyone.\" — Sara Conlon, Head of Financial Engineering"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/server_side_transaction_validation.json"
}
},
{
"id": "subscription_lifecycle_state_intelligence",
"name": "Subscription lifecycle state intelligence",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web"
],
"monetization_primitives": [
"Subscription"
],
"what_it_does": "Provides forward-looking and state-based views of subscription lifecycles, including active, expiring soon, grace period, billing retry, and lapsed states, enabling teams to understand what is about to happen, not just what already happened.",
"why_it_matters": "f we can’t intervene before monetization fully stops, churn is treated as a single irreversible event instead of a process. We miss high-signal intervention windows such as post-cancellation but pre-expiration, and are limited to late winback attempts when user intent and engagement are already low. This reduces retention effectiveness and increases reliance on discounts instead of targeted recovery actions. Users reduce spending or cancel before the business realizes the full value of the relationship. Revenue declines silently as users leave without any attempt at intervention or recovery. Monetization performance is only visible when someone actively checks dashboards, making it easy to miss early warning signs such as anomalies, regressions, or deteriorating trends. Teams react later than they should, small issues compound into larger revenue-impacting problems, and leadership lacks continuous confidence in the health of the business. Teams lack timely visibility into monetization performance and emerging issues, causing them to react only after revenue-impacting problems have already escalated. Performance regressions, anomalies, and negative trends go unnoticed until they cause meaningful revenue loss. Teams respond late, firefight instead of preventing issues, and leadership lacks real-time confidence in the health of the business. Cancellation intent triggers timely interventions that prevent avoidable churn At-risk users re-engage and remain subscribed long enough to realize value Anomalies and regressions are detected quickly before major revenue impact Teams maintain continuous awareness of monetization health without manual monitoring",
"constraints_limits": "Accuracy depends on timely platform lifecycle event ingestion and correct product configuration; forward-looking “about to expire” views are limited to what the stores expose about renewal/expiration timing.",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/customers/customer-info",
"decisions_enabled": [
"Should we intervene before monetization stops?",
"Should monetization performance be proactively surfaced rather than passively monitored?"
],
"canonical_problems": [
"Users cancel or disengage before delivering full value",
"Monetization performance issues are detected too late"
],
"outcomes": [
"Cancellation intent triggers timely interventions that prevent avoidable churn",
"At-risk users re-engage and remain subscribed long enough to realize value",
"Anomalies and regressions are detected quickly before major revenue impact",
"Teams maintain continuous awareness of monetization health without manual monitoring"
],
"proof_points": [
{
"name": "VSCO membership churn reduction",
"type": "Customer",
"statement": "VSCO reduced membership churn by almost 5% using RevenueCat and Braze integration"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/subscription_lifecycle_state_intelligence.json"
}
},
{
"id": "support_tooling_context_and_actions",
"name": "Support tooling context and actions",
"mechanism_type": "Integration",
"status": "GA",
"platforms": [
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Web purchases"
],
"what_it_does": "Surfaces user purchase history, entitlements, and monetization state inside support tools, and allows support teams to take monetization-related actions.",
"why_it_matters": "All monetization actions must be tied to visible in-app surfaces, limiting our ability to respond to high-signal events like cancellation, refund requests, or expiration in real time. This forces late or manual interventions and reduces the effectiveness of retention, recovery, and support-driven monetization actions. Users reduce spending or cancel before the business realizes the full value of the relationship. Revenue declines silently as users leave without any attempt at intervention or recovery. Cancellation intent triggers timely interventions that prevent avoidable churn At-risk users re-engage and remain subscribed long enough to realize value",
"constraints_limits": "Actions are limited to permissions and supported integrations.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/integrations/customer-support",
"decisions_enabled": [
"Should we take monetization actions without showing an in-app surface?"
],
"canonical_problems": [
"Users cancel or disengage before delivering full value"
],
"outcomes": [
"Cancellation intent triggers timely interventions that prevent avoidable churn",
"At-risk users re-engage and remain subscribed long enough to realize value"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/support_tooling_context_and_actions.json"
}
},
{
"id": "targeting_rules_engine",
"name": "Targeting rules engine",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"iOS",
"Android",
"Web",
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Web purchases"
],
"what_it_does": "Routes users to monetization experiences using shared audience segmentation across Targeting, Experiments, and Refund Control. Supports reusable audience definitions, audience preview, and audience export so teams can apply consistent segmentation in monetization workflows.",
"why_it_matters": "All users are shown the same monetization experience regardless of their goals, intent, or context. This reduces relevance and conversion, forces generic paywalls and offers, and limits the ability to tailor monetization to different user needs, leading to lower performance across the funnel. Different users are shown the same prices, offers, and monetization surfaces despite having different willingness to pay. High-value users are under-monetized while low-value users are over-priced, hurting both revenue and user experience. Monetization experiences are tailored by segment to improve conversion and LTV Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience",
"constraints_limits": "Only works as well as the user attributes and segment definitions provided by the customer.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/tools/targeting#:~:text=Targeting%20allows%20you%20to%20maximize,and%20end%20at%20future%20dates",
"decisions_enabled": [
"Should monetization logic adapt based on user intent or context?"
],
"canonical_problems": [
"All users are monetized the same way"
],
"outcomes": [
"Monetization experiences are tailored by segment to improve conversion and LTV",
"Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience"
],
"proof_points": [
{
"name": "Photoroom trial rates in Japan",
"type": "Customer",
"statement": "Photoroom achieved 2-3x trial rates in Japan"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/targeting_rules_engine.json"
}
},
{
"id": "unified_monetization_backend",
"name": "Unified monetization backend",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"Other",
"Cross-platform",
"Web",
"Android",
"iOS"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Ads",
"Web purchases",
"Future / unknown"
],
"what_it_does": "",
"why_it_matters": "",
"constraints_limits": "Limited to monetization models and platforms supported by RevenueCat.",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/welcome/overview",
"decisions_enabled": [],
"canonical_problems": [],
"outcomes": [],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/unified_monetization_backend.json"
}
},
{
"id": "unified_revenue_model_normalization",
"name": "Unified revenue model (cross-platform normalization)",
"mechanism_type": "Backend service",
"status": "GA",
"platforms": [
"Cross-platform"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Ads",
"Web purchases"
],
"what_it_does": "Normalizes revenue and monetization state across stores and monetization models so reporting and segmentation are comparable across platforms.",
"why_it_matters": "Teams optimize locally while harming overall business performance. Revenue data is fragmented across subscriptions, purchases, and ads, making it difficult to understand true user value. Teams make acquisition and monetization decisions based on incomplete or misleading data. Ad spend data lives in ad platforms (Meta, Google, ASA) while revenue data lives in app stores or subscription systems. Without joining these, teams cannot calculate true payback periods, ROAS, or cost-per-trial by channel. Growth teams over-invest in channels that look good on install volume but have poor payback, or under-invest in high-LTV channels because they can't prove ROI. Budgets are allocated based on incomplete signals. Revenue data and logic fragment across systems, making holistic decisions impossible. Total user value is measured across subscriptions, purchases, and other revenue streams Acquisition and product decisions are based on unified revenue truth rather than partial signals",
"constraints_limits": "Depends on availability of underlying platform signals and the ability to normalize differences across stores.",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/dashboard-and-metrics/charts",
"decisions_enabled": [
"Should revenue data be unified across platforms and products?",
"Do we want to support multiple monetization models in a unified system?"
],
"canonical_problems": [
"We don’t understand true user value across revenue streams",
"We can't connect acquisition spend to downstream revenue to measure channel-level payback"
],
"outcomes": [
"Total user value is measured across subscriptions, purchases, and other revenue streams",
"Acquisition and product decisions are based on unified revenue truth rather than partial signals"
],
"proof_points": [
{
"name": "Photoroom: RevenueCat as single source of truth",
"type": "Customer",
"statement": "Photoroom uses RevenueCat as their single source of truth for subscriptions, spreading reliable data across their entire marketing and analytics stack (Amplitude, Adjust, Braze, Superwall). \"RevenueCat is at the center of our stack for subscriptions. It enables us to have one single source of truth for subscriptions and revenue data and then allows us to spread that reliable data across all of the great integrations RevenueCat has with the rest of our marketing and analytics stack.\" — Olivier Lemarie, Head of Growth and Marketing"
},
{
"name": "Foodvisor: ~100% data accuracy",
"type": "Customer",
"statement": "Foodvisor reports almost 100% data accuracy from RevenueCat subscription event data. \"I am always very cautious of the data sent by analytics platforms because of all the discrepancies that usually exist. This is not the case with RevenueCat, you can trust the data they send almost 100% of the time.\" — Charles Boes, Chief Product Officer"
},
{
"name": "HOLYWATER: Zero data issues in 5 years",
"type": "Reliability",
"statement": "HOLYWATER experienced zero data issues in 5 years of using RevenueCat. \"With other tools, you see outages and data loss. RevenueCat has been solid—and that lets us trust the numbers.\" — Anatolii Kasianov, CTO and Co-founder"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/unified_revenue_model_normalization.json"
}
},
{
"id": "unified_sdk_surface_across_platforms",
"name": "Unified SDK surface across platforms",
"mechanism_type": "SDK",
"status": "GA",
"platforms": [
"iOS",
"Web",
"Android",
"Cross-platform",
"Other"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency"
],
"what_it_does": "Provides consistent SDK interfaces across platforms so monetization logic can be implemented once and reused as distribution expands.",
"why_it_matters": "Monetization behavior becomes inconsistent across platforms, teams, and codebases. Maintaining monetization systems over time diverts engineering effort away from building the core product. Monetization systems fall behind platform changes, bugs accumulate, and engineers spend increasing time maintaining revenue infrastructure instead of improving the product. Monetization systems stay reliable and current without ongoing internal maintenance burden Platform feature adoption happens quickly without major engineering projects",
"constraints_limits": "Feature parity may lag on newly supported platforms.",
"requires_configuration": false,
"docs_link": "https://www.revenuecat.com/docs/platform-resources/sdk-reference",
"decisions_enabled": [
"Should monetization logic live in one centralized system?"
],
"canonical_problems": [
"We can’t afford to maintain monetization systems long-term"
],
"outcomes": [
"Monetization systems stay reliable and current without ongoing internal maintenance burden",
"Platform feature adoption happens quickly without major engineering projects"
],
"proof_points": [
{
"name": "OpenAI/ChatGPT implementation time",
"type": "Customer",
"statement": "OpenAI moved from signing deal to launching ChatGPT on iOS within 2 months"
},
{
"name": "Pixery Labs engineering hours saved",
"type": "Customer",
"statement": "Pixery Labs saves 6,000+ engineering hours per year with RevenueCat"
},
{
"name": "Pixery Labs implementation time",
"type": "Customer",
"statement": "Pixery Labs completed RevenueCat implementation in only 1.5 weeks"
},
{
"name": "Notion testimonial",
"type": "Customer",
"statement": "RevenueCat made implementing and managing Notion personal subscription product on iOS incredibly easy and straightforward"
},
{
"name": "Runna: App Store rejection to live in 1 week",
"type": "Customer",
"statement": "Runna went from App Store rejection to live with in-app purchases in just 1 week using RevenueCat SDK and documentation. \"We were laughing because we could not have imagined that it would be that quick to get in-app payments set up after that first rejection.\" — Walter Holohan, CTO"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/unified_sdk_surface_across_platforms.json"
}
},
{
"id": "web_billing_discounts_and_promo_codes",
"name": "Web Billing discounts and promotional codes",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [],
"monetization_primitives": [],
"what_it_does": "Allows teams to create percentage-based discounts and promotional codes for web purchases directly from the RevenueCat dashboard. Codes can be distributed to users and applied at checkout manually, via URL parameters, or through the Web SDK. Supports configurable duration modes and product scopes. Enables seasonal acquisition campaigns, win-back incentives for churned subscribers, and customer support appeasement discounts — without the free-trial-only restriction imposed by the App Store and Google Play.",
"why_it_matters": "Winback offers are ineffective or overly generous. After users stop spending, it’s unclear when to re-engage them and what offers are effective. Churned users are either ignored or spammed with generic discounts that perform poorly and hurt margins. Exit offers become blunt discounts that erode value. Users show intent to pay but hesitate or abandon when presented with a monetization surface. High-intent users leave without converting, resulting in lost revenue that cannot be recovered later. All monetization is constrained to app store flows and fees, even for high-intent users reached through owned or off-platform channels. This limits pricing flexibility, reduces margin, and prevents monetizing demand that exists before installation. Different users are shown the same prices, offers, and monetization surfaces despite having different willingness to pay. High-value users are under-monetized while low-value users are over-priced, hurting both revenue and user experience. All users are shown the same monetization experience regardless of their goals, intent, or context. This reduces relevance and conversion, forces generic paywalls and offers, and limits the ability to tailor monetization to different user needs, leading to lower performance across the funnel. Churned users receive timed winback campaigns that drive reactivation Winback incentives are targeted and profitable rather than generic discounting High-intent users convert instead of abandoning paywalls Exit offers and alternatives recover would-have-been lost conversions without harming pricing integrity Monetization experiences are tailored by segment to improve conversion and LTV",
"constraints_limits": "",
"requires_configuration": false,
"docs_link": "",
"decisions_enabled": [
"What winback incentive should we offer this user?",
"What alternative offer should we present to this user?",
"Should monetization occur outside app store distribution entirely?",
"Should monetization logic adapt based on user intent or context?"
],
"canonical_problems": [
"We don’t know when or how to win users back after they stop spending",
"Users hesitate or abandon monetization surfaces",
"All users are monetized the same way"
],
"outcomes": [
"Churned users receive timed winback campaigns that drive reactivation",
"Winback incentives are targeted and profitable rather than generic discounting",
"High-intent users convert instead of abandoning paywalls",
"Exit offers and alternatives recover would-have-been lost conversions without harming pricing integrity",
"Monetization experiences are tailored by segment to improve conversion and LTV",
"Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/web_billing_discounts_and_promo_codes.json"
}
},
{
"id": "web_funnels_and_quizzes",
"name": "Web funnels and quizzes",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"Web"
],
"monetization_primitives": [
"Subscription",
"One-time",
"In-App Currency",
"Web purchases"
],
"what_it_does": "Allows teams to configure multi-step web flows that gather user context or intent before deciding whether and how to present a monetization surface. Supports a growing component library including text input, Express Checkout (Apple Pay / Google Pay), and URL-parameter-driven branching. Includes an Experiment step type that randomly routes visitors across up to 4 variants and reports results alongside other experiments. Supports standard OAuth/OpenID Connect authentication, enabling no-code integration with identity providers such as Auth0 and Clerk. Supports RevenueCat Billing, Stripe, and Paddle as payment providers. Teams can add custom components and configurable loading screens, use Firebase authentication with Google or email/password sign-in, and connect Google Tag Manager to send Funnel events to marketing tools.",
"why_it_matters": "Off-platform flows are generic and fail to capture intent efficiently. Different users are shown the same prices, offers, and monetization surfaces despite having different willingness to pay. High-value users are under-monetized while low-value users are over-priced, hurting both revenue and user experience. Users are asked to pay before perceiving value, hurting trust and conversion. Users reach a monetization surface without fully understanding why the product is worth paying for. Conversion rates suffer, users churn early, and teams compensate by discounting instead of improving value communication. Monetization experiences are tailored by segment to improve conversion and LTV Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience Users understand the value proposition before seeing an offer Monetization surfaces align with user intent and the value they care about",
"constraints_limits": "Limited to supported funnel steps, logic, targeting inputs and payment-provider capabilities. Firebase authentication requires a connected Firebase project; email/password sign-in supports optional email verification. Google Tag Manager requires a configured container.",
"requires_configuration": true,
"docs_link": "",
"decisions_enabled": [
"What monetization surface should this user see off-platform?",
"Has this user experienced enough value to justify showing a monetization surface?"
],
"canonical_problems": [
"All users are monetized the same way",
"Users don’t understand the value before being asked to pay"
],
"outcomes": [
"Monetization experiences are tailored by segment to improve conversion and LTV",
"Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience",
"Users understand the value proposition before seeing an offer",
"Monetization surfaces align with user intent and the value they care about"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/web_funnels_and_quizzes.json"
}
},
{
"id": "web_merchant_of_record_integration",
"name": "Web merchant-of-record integration",
"mechanism_type": "",
"status": "GA",
"platforms": [],
"monetization_primitives": [],
"what_it_does": "Enables teams to delegate tax calculation, remittance, legal compliance, invoicing, and dispute management to a third-party Merchant of Record provider for web purchases, rather than handling these obligations directly. Supports Stripe Managed Payments and Paddle Billing across RevenueCat Web purchase surfaces. Provides configurable checkout terms acceptance so merchants can require buyers to acknowledge company terms as part of the purchase flow.",
"why_it_matters": "All monetization is constrained to app store flows and fees, even for high-intent users reached through owned or off-platform channels. This limits pricing flexibility, reduces margin, and prevents monetizing demand that exists before installation. Different users are shown the same prices, offers, and monetization surfaces despite having different willingness to pay. High-value users are under-monetized while low-value users are over-priced, hurting both revenue and user experience. Monetization experiences are tailored by segment to improve conversion and LTV Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience",
"constraints_limits": "",
"requires_configuration": false,
"docs_link": "",
"decisions_enabled": [
"Should monetization occur outside app store distribution entirely?"
],
"canonical_problems": [
"All users are monetized the same way"
],
"outcomes": [
"Monetization experiences are tailored by segment to improve conversion and LTV",
"Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/web_merchant_of_record_integration.json"
}
},
{
"id": "web_paywalls",
"name": "Web paywalls",
"mechanism_type": "Dashboard",
"status": "GA",
"platforms": [
"Web"
],
"monetization_primitives": [
"Subscription",
"One-time",
"Web purchases",
"In-App Currency"
],
"what_it_does": "Allows teams to design and deploy web-based paywalls that can function as the purchase surface itself, including wallet-native checkout (Apple Pay / Google Pay) when available. Supports Stripe Billing products and Stripe Managed Payments (Stripe's Merchant of Record product) across all RevenueCat Web purchase surfaces: web paywalls, web purchase links, web funnels, and related checkout flows. Web paywalls can act as the final checkout step for web-first or app-to-web flows, removing the need for a separate hosted checkout page and reducing friction between purchase intent and payment.",
"why_it_matters": "Off-platform flows are generic and fail to capture intent efficiently. Different users are shown the same prices, offers, and monetization surfaces despite having different willingness to pay. High-value users are under-monetized while low-value users are over-priced, hurting both revenue and user experience. Monetization experiences are tailored by segment to improve conversion and LTV Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience",
"constraints_limits": "Wallet-native express checkout is available only when supported by the browser, device, and billing engine.
Express checkout requires RevenueCat Web Billing and compatible wallet support (e.g. Apple Pay or Google Pay). When unavailable, the paywall falls back to standard web checkout behavior.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/web/web-billing/paywalls",
"decisions_enabled": [
"What monetization surface should this user see off-platform?"
],
"canonical_problems": [
"All users are monetized the same way"
],
"outcomes": [
"Monetization experiences are tailored by segment to improve conversion and LTV",
"Pricing, packaging, and surfaces adapt to user context without fragmenting the product experience"
],
"proof_points": [
{
"name": "CardPointers app store fees saved",
"type": "Customer",
"statement": "CardPointers saved ~27% in app store fees with Stripe integration"
},
{
"name": "Floga pre-launch revenue",
"type": "Customer",
"statement": "Floga generated six figures in revenue in one day pre-launch with commission-free web billing"
}
],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/web_paywalls.json"
}
},
{
"id": "web_winback_campaigns",
"name": "Web Win-Back Campaigns",
"mechanism_type": "Dashboard",
"status": "Beta",
"platforms": [
"Web"
],
"monetization_primitives": [
"Subscription",
"Web purchases"
],
"what_it_does": "Allows teams to configure automated win-back email sequences targeting churned subscribers, with a web purchase link or a Web Funnel as the resubscription destination. Campaigns can target mobile or web subscriptions from apps in the project, and Funnels provide a tailored multi-step return to checkout. Removes the need for external email tools, webhooks, and custom automation chains — the entire flow is configured within RevenueCat.",
"why_it_matters": "Resources are wasted on users unlikely to return. After users stop spending, it’s unclear when to re-engage them and what offers are effective. Churned users are either ignored or spammed with generic discounts that perform poorly and hurt margins. Winback offers are ineffective or overly generous. Churned users receive timed winback campaigns that drive reactivation Winback incentives are targeted and profitable rather than generic discounting",
"constraints_limits": "",
"requires_configuration": true,
"docs_link": "",
"decisions_enabled": [
"Should we attempt to win this user back at all?",
"What winback incentive should we offer this user?"
],
"canonical_problems": [
"We don’t know when or how to win users back after they stop spending"
],
"outcomes": [
"Churned users receive timed winback campaigns that drive reactivation",
"Winback incentives are targeted and profitable rather than generic discounting"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/web_winback_campaigns.json"
}
},
{
"id": "weekly_monetization_performance_summaries",
"name": "Weekly monetization performance summaries",
"mechanism_type": "Surface",
"status": "GA",
"platforms": [
"Cross-platform"
],
"monetization_primitives": [
"Future / unknown",
"Web purchases",
"Ads",
"In-App Currency",
"One-time",
"Subscription"
],
"what_it_does": "Delivers regular narrative summaries highlighting notable changes, trends, and risks in monetization performance, reducing the need for manual analysis.",
"why_it_matters": "Monetization performance is only visible when someone actively checks dashboards, making it easy to miss early warning signs such as anomalies, regressions, or deteriorating trends. Teams react later than they should, small issues compound into larger revenue-impacting problems, and leadership lacks continuous confidence in the health of the business. Teams lack timely visibility into monetization performance and emerging issues, causing them to react only after revenue-impacting problems have already escalated. Performance regressions, anomalies, and negative trends go unnoticed until they cause meaningful revenue loss. Teams respond late, firefight instead of preventing issues, and leadership lacks real-time confidence in the health of the business. Anomalies and regressions are detected quickly before major revenue impact Teams maintain continuous awareness of monetization health without manual monitoring",
"constraints_limits": "Summary usefulness depends on selected metrics and thresholds; summaries may miss context that requires human interpretation or external events not visible in monetization data.",
"requires_configuration": true,
"docs_link": "https://www.revenuecat.com/docs/dashboard-and-metrics/performance-summaries#:~:text=With%20Performance%20Summaries%2C%20you%20can,your%20inbox%20every%20Monday%20morning",
"decisions_enabled": [
"Should monetization performance be proactively surfaced rather than passively monitored?"
],
"canonical_problems": [
"Monetization performance issues are detected too late"
],
"outcomes": [
"Anomalies and regressions are detected quickly before major revenue impact",
"Teams maintain continuous awareness of monetization health without manual monitoring"
],
"proof_points": [],
"competitor_coverage": [],
"paths": {
"per_capability_json": "capability/weekly_monetization_performance_summaries.json"
}
}
]
}