pricing-strategy

name	pricing-strategy
description	When the user wants help with pricing decisions, packaging, monetization strategy, or regional/international pricing. Use when someone mentions 'pricing,' 'pricing tiers,' 'freemium,' 'free trial,' 'value metric,' 'willingness to pay,' 'how much should I charge,' 'annual vs monthly,' 'should I offer a free plan,' 'regional pricing,' 'PPP pricing,' 'price floor,' 'price increase,' 'raise prices,' or 'pricing scripts.'
metadata	{"version":"1.0.0"}

Pricing Strategy

Expert in SaaS pricing and monetization strategy. Design pricing that captures value, drives growth, and aligns with customer willingness to pay.

Before Starting

Read .agents/product-marketing-context.md if it exists — it contains product name, audience, and positioning context.

Gather this context (ask if not provided):

1. Business Context

• What type of product? (SaaS, marketplace, e-commerce, service)
• Current pricing (if any)?
• Target market? (SMB, mid-market, enterprise)
• Go-to-market motion? (self-serve, sales-led, hybrid)

2. Value & Competition

• Primary value delivered?
• What alternatives do customers consider?
• How do competitors price?

3. Current Performance

• Conversion rate, ARPU, churn rate?
• Customer feedback on pricing?

4. Goals

• Optimizing for growth, revenue, or profitability?

---

Pricing Fundamentals

The Three Pricing Axes

1. Packaging: What's included at each tier?
2. Pricing Metric: What do you charge for? (per user, usage, flat)
3. Price Point: The actual dollar amounts

Value-Based Pricing

• Customer's perceived value: The ceiling
• Your price: Between alternatives and perceived value
• Next best alternative: The floor
• Your cost to serve: Only a baseline, not the basis

---

Value Metrics

The value metric is what you charge for. It should scale with the value customers receive.

Good value metrics: Align price with value, easy to understand, scale with growth, hard to game.

Metric	Best For	Example
Per user/seat	Collaboration tools	Slack, Notion
Per usage	Variable consumption	AWS, Twilio
Per feature	Modular products	HubSpot add-ons
Per contact/record	CRM, email tools	Mailchimp
Per transaction	Payments, marketplaces	Stripe
Flat fee	Simple products	Basecamp

Test: "As a customer uses more of [metric], do they get more value?" If yes, it's a good value metric.

---

Good-Better-Best Framework

• Good (Entry): Core features, limited usage, low price
• Better (Recommended): Full features, reasonable limits, anchor price
• Best (Premium): Everything, advanced features, 2-3x Better price

Tier Differentiation

• Feature gating: Basic vs. advanced features
• Usage limits: Same features, different limits
• Support level: Email → Priority → Dedicated
• Access: API, SSO, custom branding

---

Pricing Research

Van Westendorp Method

Four questions that identify acceptable price range:

1. At what price is it too expensive? (wouldn't consider)
2. At what price is it too cheap? (question quality)
3. At what price is it expensive but you'd consider it?
4. At what price is it a bargain?

Analyze intersections to find optimal pricing zone.

MaxDiff Analysis

Identifies which features customers value most. Show sets of features, ask most/least important. Results inform tier packaging.

---

When to Raise Prices

Signs It's Time

Market signals: Competitors raised prices, prospects don't flinch, "it's so cheap!" feedback.

Business signals: Very high conversion (>40%), very low churn (<3%), strong unit economics.

Product signals: Significant value added since last pricing.

Price Increase Strategies

1. Grandfather existing: New price for new customers only
2. Delayed increase: Announce 3-6 months out
3. Tied to value: Raise price but add features
4. Plan restructure: Change plans entirely

---

Pricing Page Best Practices

• Clear tier comparison table, recommended tier highlighted
• Monthly/annual toggle, annual discount callout (17-20%)
• FAQ section, money-back guarantee, customer logos
• Anchoring: Show higher-priced option first
• Decoy effect: Middle tier should be best value
• Charm pricing: $49 vs. $50 (for value-focused)
• Round pricing: $50 vs. $49 (for premium)

---

Pricing Checklist

Before Setting Prices

• Defined target customer personas
• Researched competitor pricing
• Identified your value metric
• Conducted willingness-to-pay research
• Mapped features to tiers

Pricing Structure

• Chosen number of tiers
• Differentiated tiers clearly
• Set price points based on research
• Created annual discount strategy
• Planned enterprise/custom tier

---

Consumer App Subscription Pricing (Mobile)

Proven pricing structure for subscription apps on App Store / Google Play. The weekly price is intentionally aggressive to anchor the longer-term option as the obvious deal.

Tier	Price	Purpose
Weekly	$12.99/week	Anchor (makes everything else look cheap)
6-month	$59.99/6mo	Target (most users land here)
Exit offer	$39.99/6mo + 3-day free trial	Catches users trying to bail at the paywall

The exit offer alone can 2x your ARPU vs the "$9.99/month" trap. Always split-test: different prices, paywalls, onboarding screens, value props. Every week the funnel should get sharper.

Hard Paywall vs. Free Trial (the no-trial school)

A competing camp of mobile operators runs no trial, 100% pay-to-access and reports better economics than trial funnels. The logic: free users convert at <3%, so a trial mostly subsidizes people who were never going to pay and trains the rest to expect free. A hard paywall filters for intent at the door.

Reported patterns from operators running no-trial stacks (validate against your own funnel before copying):

• A no-trial offer stack pairing a weekly, an annual, and an annual retention offer can run profitably on paid social when creative volume is high (test many angles at low daily spend, scale winners).
• Operators report moving a weekly price up (e.g. $6.99 to $9.99/wk) with "conversion hardly dropped": evidence the weekly is often price-inelastic in the impulse range, so underpricing it leaves money on the table.
• Retention offer (Apple now allows): e.g. 50% off the second billing cycle. A lifetime option priced at ~3x annual can capture price-insensitive whales.

The tension to resolve per product: hard paywall maximizes revenue-per-install and works for impulse/novelty/high-emotion consumer apps. It is the wrong default for trust-and-credibility products (finance, health) where the user must believe the product before paying, and where torched App Store reviews from a no-trial wall are a permanent moat-killer. If your product is in that trust camp, prefer a trial or freemium taste over a hard wall, and never run a no-trial paywall on cold high-consideration traffic.

Market-Validation Heuristic (before pricing anything)

Don't ask "is this market big enough?" Ask: "are multiple apps in this category all making money?" If several competitors are clearly monetizing, the market validated itself, repeatedly, without your spend. A single big-TAM number is theory; multiple profitable incumbents is proof.

Consumables and App Store Whales

Subscriptions cap spend. Consumables create room for power users to spend more when the app has repeatable high-emotion value.

Common consumables pattern: some apps find that after launch users repeat a high-value flow (e.g. photo/profile generation) more often than expected, so the team adds paid credit packs on top of the subscription. The theory: like dating apps and games, a small top-percentile user segment can drive a large share of revenue when there is no hard cap on useful spend.

Use consumables when:

• The value repeats naturally: more photos, more analyses, more reports, more generations, more scans.
• The marginal result is personally meaningful or status-linked.
• The subscription covers baseline access, while credits unlock extra volume or premium outputs.
• The user can understand what one credit buys without reading docs.

Avoid consumables when they make the core subscription feel incomplete or nickel-and-dimed.

Adaptation for content/insight products: good consumables are premium deep-dive reports, extra AI reviews, or high-touch audits. Do not sell basic daily value piecemeal.

---

Regional / International Pricing

For apps with a global user base, regional pricing is a high-leverage but dangerous lever. The naive approach (PPP discounts everywhere) can destroy unit economics.

Why Pure PPP Fails for AI/LLM Apps

PPP (purchasing power parity) pricing works when marginal cost per user is near zero (Spotify, Netflix). It breaks when each active user has real variable costs (LLM API calls, compute). A $30/yr subscriber in a low-PPP market who uses the AI features actively can be net-negative after the app store's 30% cut.

The math to run before setting floors:

1. Gross price x 0.70 (after App Store/Google Play 30%) = net revenue
2. Estimated LLM cost per active user per year (check your provider dashboard)
3. Net revenue must exceed LLM cost with margin, even at the floor price

Cost-Floor Pricing (Preferred Over PPP)

Instead of PPP ratios determining every price, set floors based on unit economics and let PPP only influence the range above the floor.

Three-tier model:

• Tier 1 (Premium): US, UK, Switzerland, Scandinavia, Germany, Gulf states. Full price or above.
• Tier 2 (Mid): Canada, Australia, Japan, Korea, most of Europe. 15-25% discount off US price.
• Tier 3 (Growth): Brazil, Mexico, India, Southeast Asia, Africa. Hit the floor. PPP ratios are irrelevant here; the floor does all the work.

Data-Driven Floor Setting

Before choosing a floor, query actual conversion data by price point and country:

• Dialog completion rate = subscribers / (subscribers + cancels at Apple/Google dialog). Truest signal of price acceptance.
• Paywall-to-subscribe rate by country = subscribed / paywall_views. Identifies which markets actually convert.
• If a market converts below 2-3% regardless of price, lowering further won't help. The problem is intent, not affordability.

See references/regional-pricing-analysis.md for the analytics query patterns and how to pull your own regional benchmarks.

Retention layer PPP analysis usually misses (cost per RETAINED sub)

Price/conversion is only half the picture. Cheap emerging installs can look great on cost-per-install and even cost-per-subscriber while churning 40-60% in 60 days, so the true unit is cost per RETAINED subscriber and store-only ROAS = store_revenue(country) / spend(country). It is common to see emerging markets churn 2-3x faster than premium markets (e.g. 50-60% vs 8-25% at 60 days) and post ROAS well below 1x even when they look cheap to acquire. So "this market is cheap to acquire" is NOT a reason to keep spending there. Pull churn by country before defending emerging spend using your own subscription analytics (RevenueCat, Appfigures, Amplitude, or App Store / Play Console reports). Note some analytics APIs cannot return country-level revenue or bulk customer data, so you may need dashboard exports or a store-level report for per-country retention.

Psychological Pricing for International Tiers

• Anchoring with weekly: A $5/week plan ($260/yr) makes a $104/yr annual plan feel like 60% savings. The weekly isn't there to sell weeklies; it's an anchor.
• Higher price = higher dialog completion: Counter-intuitively, higher-priced plans can convert better at the OS purchase dialog because the higher price filters for serious buyers. Impulse tappers attracted by low prices bail at the real payment step.
• Don't show your cheapest plan as default. A low default price attracts impulse tappers who inflate your funnel but never convert. Lead with your target price.

Retention / Promo Offer: verify the SKU BEFORE fixing prices

A promotional or retention offer is per-product. An offer attached to a subscription the live paywall does not sell will never appear in the cancel sheet, no matter how correct its prices are. Before touching any promo-offer price points:

1. Find the offering with is_current: true (RevenueCat list-offerings) and read its $rc_annual package's product.store_identifier (get-offering with expand=["package","package.product"]). That is the SKU the paywall actually sells — verify, don't assume.
2. Check which promo offers already exist on THAT sub (ASC /subscriptions/<id>/promotionalOffers). The sold SKU often already has the retention offer built; the real bug is then the RC retention wizard mapping (Dashboard > Lifecycle > Retention), not a price write.
3. Only if the correct offer's own price points are wrong do you write — and write to the sold SKU, never a dead duplicate.

Watch for multiple coexisting annual SKUs that are easy to confuse (a product can have several annual products live at once: e.g. <ANNUAL_SKU_A> = "Annual full price", <ANNUAL_SKU_B> = the one actually sold, <ANNUAL_SKU_C> = a secret/discount variant, plus sibling-app variants). A ticket can name the wrong one. Also sanity-check the discount math against the sub's CONFIRMED current base when it shows multiple tiers (e.g. two different base prices on the same product). Corruption pattern seen in the wild: a "30% off" point that was only 25% off, and a foreign point at 2.3x base (a markup labeled as a discount). The deep ASC/RC catalog-diagnostic mechanics (price-point base64 decoding, raw curl recipes) belong in your store-CLI tooling's reference docs.

Apple & Google Regional Pricing Scripts

If your app is already PPP-priced live on both stores, CHECK the live per-territory price before recommending "re-run the PPP scripts" for a market. Emerging markets often already sit at or near your floor, so re-running the scripts moves almost nothing. When a low-price market still converts poorly, the blocker is frequently payment rails (card penetration, local billing support) and intent, NOT price, so lowering further will not help. Treat any older "uniform price worldwide, scripts never ran" note as potentially stale and verify against the live catalog.

Verify live prices (do this before any PPP recommendation):

• iOS: asc subscriptions pricing summary --subscription-id <SUBSCRIPTION_ID> --territory <ISO3> (ISO3 like USA/IND/PHL).
• Android: Android Publisher API /subscriptions via a service-account JSON (androidpublisher scope); read basePlans[].regionalConfigs[].price.

A typical initial-ladder script set for a NEW product's territory pricing:

• update_apple_prices.py: maps PPP source data (e.g. Spotify per-country prices) to Apple price points per territory
• pricing_utils.py: shared PPP data and country code mappings
• spotify_prices_usd.csv: source PPP data (per-country reference prices)

Key config fields in each script's CONFIGURATIONS list:

• US_ANNUAL_USD: The US base price (annualized)
• MIN_ANNUAL_USD: Floor (annualized)
• MAX_ANNUAL_USD: Cap (annualized)
• PERIODS_PER_YEAR: 52 for weekly, 12 for monthly, omit for annual

Apple requires: an API key ID and issuer ID (store them in your environment / credential store) plus a .p8 key file. Google requires: a service_account.json in the scripts directory.

Always --dry-run first. Apple price changes are scheduled (not immediate) and require advance notice to existing subscribers.

---

Related Skills

• churn-prevention: Cancel flows, save offers, revenue churn
• growth: Pricing page optimization, paywall CRO
• copywriting: Pricing page copy
• marketing-psychology / persuasion review: Pricing psychology principles
• revenuecat-cli: Pull subscription metrics, product catalog, and customer data for pricing analysis