Unit Economics

A Per-Feature Gross Margin Tracking System for AI Products

Q: Why does per-feature gross margin matter in AI products?

In a traditional SaaS product, features have minimal direct COGS — the cost of serving a feature is largely fixed infrastructure shared across all features. In an AI product, each feature triggers inference calls with variable, measurable costs. A document summarization feature may cost $0.15 per use; a keyword extraction feature may cost $0.003 per use. If both features are bundled in the same pricing tier, the summary feature is being subsidized by the keyword extraction feature's margin. Per-feature tracking makes this cross-subsidy explicit and enables pricing decisions that resolve it.

Q: How do you technically tag inference calls by feature?

Feature tagging requires adding a feature identifier to every API call or inference request at the point of invocation. Implementation approaches: (1) Request metadata — if your model provider supports custom metadata in API calls, pass a feature ID with each call. (2) Internal logging — log each outgoing inference request with its feature tag, request ID, and token counts in an internal cost ledger before the external call is made. (3) Function-level instrumentation — wrap each feature's inference calls in a function that logs the feature tag alongside the call. The key requirement: the tag must be applied at the code level where the feature is identifiable, not at a higher layer where multiple features' calls are mixed.

Q: How do you calculate revenue contribution for each feature?

Revenue contribution for each feature requires understanding what portion of the subscription price is attributable to each feature. Two approaches: (1) Usage-weighted allocation — allocate revenue in proportion to usage. If customers use Feature A 60% of the time and Feature B 40% of the time, allocate 60% and 40% of MRR to each feature respectively. (2) Willingness-to-pay research — survey customers about which features they consider most valuable, weight revenue allocation by stated importance. Usage-weighted is simpler and typically sufficient for COGS tracking purposes; willingness-to-pay research is needed for strategic pricing decisions about which features should be premium.

Q: What is the margin stack and why is it important?

The margin stack is a visual representation of all features sorted by their gross margin contribution, from highest to lowest. It makes visible the full range of feature economics: some features generate high positive margins (low inference cost, high usage), some generate modest positive margins, and some generate negative margins (high inference cost, low revenue attribution). The margin stack is important because it reveals which features are funding which other features. A product with five high-margin features and three negative-margin features can sustain the negative-margin features only if the positive-margin features generate enough headroom. When positive-margin features churn out or negative-margin features scale up, the aggregate gross margin deteriorates.

Q: What pricing actions does per-feature gross margin enable?

Per-feature gross margin enables four pricing actions: (1) Tier gating — move high-cost features to higher pricing tiers so the price point reflects the COGS. (2) Feature-based overage — add per-use charges for high-cost features on tiers where they are included with usage limits. (3) Removal from lower tiers — remove negative-margin features from lower tiers where the price point cannot support them. (4) Premium feature pricing — if a feature has high positive gross margin but is currently underpriced relative to its value, surface it as an upgrade vector. Per-feature data provides the economic justification for these actions that is typically missing from pricing conversations.

Q: How do you handle features that share inference costs?

Some product workflows involve multiple features in sequence — a document is first classified, then summarized, then analyzed. The inference calls involved in the sequence must be attributed to the appropriate features, even though a single user action triggers the sequence. The approach: instrument each feature's inference calls separately, even when they are called in sequence. If the classification is Feature A and the summarization is Feature B, the classification API call is tagged A and the summarization API call is tagged B. The user-facing workflow is a bundle of two features; the cost attribution tracks them separately.

Q: What is a reasonable cadence for reviewing per-feature gross margins?

Per-feature gross margins should be reviewed at three cadences: (1) Monthly — as part of the standard gross margin review. Look for features whose margin is trending down (usage growing faster than pricing captures the cost) or features that have crossed from positive to negative margin territory. (2) Quarterly — as input to pricing decisions. Feature margin data from the prior quarter informs tier design decisions for the next quarter. (3) Before each major release — before adding a new AI feature to a pricing tier, calculate its expected gross margin based on estimated usage and known inference cost. No feature should launch to a tier without a documented gross margin estimate.

Q: How does per-feature tracking interact with model routing decisions?

Per-feature gross margin tracking directly informs model routing decisions. If Feature A has a 20% gross margin and Feature B has a 75% gross margin, and both could technically be served by a cheaper model, the optimization priority is clear: optimize Feature A first because its margin has the most room for improvement. Model routing configured at the feature level routes each feature's requests to the appropriate model tier based on the quality requirements specific to that feature — high-margin features that depend on quality stay on frontier models; low-margin features that tolerate lower quality move to cheaper models.

Aggregate gross margin hides which AI features are profitable and which are destroying it. This guide covers how to build a per-feature gross margin tracking system that reveals the cost structure of each AI capability in your product and informs pricing tier design.

SaaS Science TeamJune 14, 20267 min read

per feature gross marginai feature cost trackingai product unit economicsfeature level cogsai saas profitabilityai product economicsfeature cost attribution

Key Takeaways

Aggregate gross margin in AI products conceals feature-level economics — a product with 65% gross margin may have individual features generating 90% margin and others generating negative margin, with the aggregate hiding both
Per-feature gross margin requires tagging every AI inference call with the feature that triggered it, then calculating (feature revenue contribution - feature direct cost) / feature revenue contribution for each feature
The most actionable finding from feature-level tracking is the margin stack — which features contribute positive margin to the product and which consume margin generated by other features, enabling tier restructuring that aligns price with cost
Feature gross margin data informs three strategic decisions: which features to gate at higher pricing tiers, which features to optimize for inference efficiency, and which features are generating value but not being captured in pricing
The benchmark for a healthy AI feature portfolio: no more than 20% of features should have negative individual gross margins, and the total positive margin from profitable features should cover negative-margin features with at least 30% headroom

Most AI product teams know their aggregate gross margin. Few know the gross margin of each feature within their product. This gap creates pricing decisions made by intuition rather than economics, optimization investments made by engineering preference rather than ROI, and tier structures designed by what feels right rather than what covers costs.

Per-feature gross margin tracking is the diagnostic system that changes this. When every feature's inference cost is measured and compared to its revenue contribution, the economics of individual product capabilities become visible — and so do the decisions that follow from those economics.

See Your Growth Ceiling NowTry Free

The Problem: Why Aggregate Gross Margin Misleads

Consider an AI product with four features used by the same customer base:

Feature	Monthly Usage per Customer	Cost per Use	Monthly Cost	Revenue Share
Document Summary	50 uses	$0.15	$7.50	40%
Q&A on Documents	200 uses	$0.04	$8.00	30%
Keyword Extraction	500 uses	$0.003	$1.50	15%
Smart Formatting	100 uses	$0.001	$0.10	15%

With a $100/month price point, revenue allocation by usage share is:

Document Summary: $40 revenue, $7.50 cost → 81% feature gross margin
Q&A: $30 revenue, $8.00 cost → 73% feature gross margin
Keyword Extraction: $15 revenue, $1.50 cost → 90% feature gross margin
Smart Formatting: $15 revenue, $0.10 cost → 99% feature gross margin

Aggregate gross margin: $100 revenue, $17.10 cost → 83% gross margin. A healthy number that suggests no action is required.

Now add a fifth feature: Advanced AI Analysis that customers use 20 times per month at $0.90 per use ($18 cost) with 15% of perceived value (justifying 15% of revenue or $15 in the flat price).

New aggregate gross margin: $100 revenue, $35.10 cost → 65% gross margin. Still apparently acceptable.

But the Advanced AI Analysis feature is losing $3 per customer per month on its own. As this feature's usage grows — because it is the most powerful feature in the product and customers find more uses for it — the aggregate gross margin continues deteriorating. Customers with higher-than-average Advanced Analysis usage are unprofitable at $100/month, but the aggregate does not reveal this.

Building the Feature Attribution System

Step 1: Feature Taxonomy

Define the feature taxonomy before building attribution. Every distinct AI capability in the product should have a feature ID — a short, stable identifier that can be used as a tag in infrastructure code without changing frequently.

Feature IDs should map to user-facing feature names but may be more granular. A user-facing "Smart Research" feature might internally consist of three sub-features: "web search," "content extraction," and "synthesis" — each with different inference cost profiles. Granular tagging enables more precise attribution than high-level feature names.

Step 2: Instrument the Inference Layer

Add feature ID tags to every inference call at the call site:

def call_model_with_feature_tag(
    prompt: str,
    customer_id: str,
    feature_id: str,
    model: str = "default",
) -> ModelResponse:
    # Log before the call to ensure attribution even if call fails
    call_id = uuid.uuid4()
    log_inference_start(call_id, customer_id, feature_id, model, prompt)
    
    response = model_provider.complete(prompt, model=model)
    
    log_inference_complete(
        call_id, 
        input_tokens=response.usage.input_tokens,
        output_tokens=response.usage.output_tokens,
        cost=calculate_cost(model, response.usage),
    )
    
    return response

The logging layer creates a cost ledger with a row per inference call, each carrying customer ID, feature ID, token counts, and cost.

Step 3: Build the Cost Attribution Table

Join the inference cost ledger to the customer revenue data on a monthly basis:

SELECT
    feature_id,
    SUM(cost_usd) as total_cost,
    COUNT(*) as total_calls,
    AVG(cost_usd) as avg_cost_per_call
FROM inference_cost_ledger
WHERE month = '2026-06'
GROUP BY feature_id;

Then join to revenue allocation data (calculated from usage weights or pricing research) to compute feature-level gross margin:

Feature Gross Margin = (Feature Revenue Contribution - Feature Direct Cost) / Feature Revenue Contribution

Step 4: Visualize the Margin Stack

Sort features by gross margin contribution (from highest to lowest) and visualize as a stacked bar — positive margins above the axis, negative margins below. The margin stack immediately shows:

Which features are profitable and by how much
Which features are unprofitable and by how much
Whether the total positive margin exceeds the total negative margin

The margin stack is the core deliverable of feature gross margin tracking and should be reviewed monthly.

The Decision Framework: What to Do With Feature Margin Data

Decision 1: Gate Negative-Margin Features at Higher Tiers

The most direct corrective action for a negative-margin feature: move it to a higher pricing tier where the price point can support its cost.

Advanced AI Analysis at $0.90/use with 20 uses/month costs $18/month per customer. A tier at $150/month that includes this feature at its current usage level prices it correctly. An alternative is including a fixed allocation (e.g., 10 uses/month) in the $100 tier with per-use overage charging thereafter.

Decision 2: Optimize High-Cost, High-Value Features

For features that are both high-value (high usage, high revenue attribution) and high-cost, optimization investment has clear ROI. The ROI calculation:

Optimization ROI = (Current Cost - Post-Optimization Cost) × Monthly Calls × 12 months
                   ÷ Engineering Investment in Optimization

A feature with $8/month/customer cost that can be reduced to $5/month/customer through prompt optimization — at 1,000 customers — saves $36,000/year. If the optimization requires two weeks of engineering (approximately $15,000 in loaded cost), the ROI is 2.4× in year one.

Decision 3: Price-Signal Underpriced High-Margin Features

Features with very high gross margins (90%+) may be underpriced relative to their value. If customers use a feature extensively and value it highly, the current pricing may not capture the value being delivered.

High-margin features that are strategically important (driving retention, enabling expansion) are candidates for premium tier inclusion or feature-based upgrade prompts. For example, if Keyword Extraction has 90% feature gross margin and is used heavily by customers who upgrade to higher plans, it is a strong expansion vector — surfacing its value in upgrade conversations has positive margin impact.

Decision 4: Remove Structurally Unprofitable Features from Lower Tiers

If a feature has negative gross margin at a given tier and optimization cannot make it margin-positive, it should be removed from that tier. This is a hard decision that requires customer communication, but it is preferable to a feature that silently erodes margins as usage scales.

The communication framework for removing a feature from a lower tier: announce the change 60–90 days in advance, offer an upgrade path to a tier where the feature is included, and provide a transition incentive (discounted upgrade pricing for the first year).

Benchmark: Feature Gross Margin Targets

Based on unit economics benchmarks from KeyBanc Capital Markets' SaaS survey and SaaS Capital's AI product benchmarks:

Feature Category	Target Feature Gross Margin	Action Threshold
Core features (define the product)	55–75%	<40% → optimize or reprice
Value-add features (drive expansion)	70–85%	<55% → reprice or gate
Premium features (high value, high cost)	45–65%	<35% → reprice
Commodity features (table stakes)	80–95%	<60% → optimize

No feature category should have a consistent negative gross margin in production. Negative-margin features should be in an active remediation program (optimization, repricing, or tier restructuring) with a timeline to resolution.

For the broader gross margin context, see AI-Native SaaS Gross Margin Decomposition. For how per-customer cost attribution complements per-feature tracking, see AI Inference Cost Allocation by Customer.

Conclusion

Per-feature gross margin tracking transforms the economics of AI product development from intuition to measurement. When every feature's cost is visible against its revenue contribution, pricing decisions are calibrated to economics rather than competitive benchmarking, optimization investments are ranked by ROI rather than engineering preference, and tier structures reflect the actual cost of delivering each capability.

The system requires an engineering investment — instrumenting inference calls with feature tags, building the attribution join, and creating a monthly review process. The return is permanent visibility into which features are building the business and which are eroding it.

See Your Growth Ceiling Now

Calculate when your SaaS growth will plateau — free, no signup required.

Calculate Your Growth Ceiling

Frequently Asked Questions

Why does per-feature gross margin matter in AI products?

In a traditional SaaS product, features have minimal direct COGS — the cost of serving a feature is largely fixed infrastructure shared across all features. In an AI product, each feature triggers inference calls with variable, measurable costs. A document summarization feature may cost $0.15 per use; a keyword extraction feature may cost $0.003 per use. If both features are bundled in the same pricing tier, the summary feature is being subsidized by the keyword extraction feature's margin. Per-feature tracking makes this cross-subsidy explicit and enables pricing decisions that resolve it.

How do you technically tag inference calls by feature?

Feature tagging requires adding a feature identifier to every API call or inference request at the point of invocation. Implementation approaches: (1) Request metadata — if your model provider supports custom metadata in API calls, pass a feature ID with each call. (2) Internal logging — log each outgoing inference request with its feature tag, request ID, and token counts in an internal cost ledger before the external call is made. (3) Function-level instrumentation — wrap each feature's inference calls in a function that logs the feature tag alongside the call. The key requirement: the tag must be applied at the code level where the feature is identifiable, not at a higher layer where multiple features' calls are mixed.

How do you calculate revenue contribution for each feature?

Revenue contribution for each feature requires understanding what portion of the subscription price is attributable to each feature. Two approaches: (1) Usage-weighted allocation — allocate revenue in proportion to usage. If customers use Feature A 60% of the time and Feature B 40% of the time, allocate 60% and 40% of MRR to each feature respectively. (2) Willingness-to-pay research — survey customers about which features they consider most valuable, weight revenue allocation by stated importance. Usage-weighted is simpler and typically sufficient for COGS tracking purposes; willingness-to-pay research is needed for strategic pricing decisions about which features should be premium.

What is the margin stack and why is it important?

The margin stack is a visual representation of all features sorted by their gross margin contribution, from highest to lowest. It makes visible the full range of feature economics: some features generate high positive margins (low inference cost, high usage), some generate modest positive margins, and some generate negative margins (high inference cost, low revenue attribution). The margin stack is important because it reveals which features are funding which other features. A product with five high-margin features and three negative-margin features can sustain the negative-margin features only if the positive-margin features generate enough headroom. When positive-margin features churn out or negative-margin features scale up, the aggregate gross margin deteriorates.

What pricing actions does per-feature gross margin enable?

Per-feature gross margin enables four pricing actions: (1) Tier gating — move high-cost features to higher pricing tiers so the price point reflects the COGS. (2) Feature-based overage — add per-use charges for high-cost features on tiers where they are included with usage limits. (3) Removal from lower tiers — remove negative-margin features from lower tiers where the price point cannot support them. (4) Premium feature pricing — if a feature has high positive gross margin but is currently underpriced relative to its value, surface it as an upgrade vector. Per-feature data provides the economic justification for these actions that is typically missing from pricing conversations.

How do you handle features that share inference costs?

Some product workflows involve multiple features in sequence — a document is first classified, then summarized, then analyzed. The inference calls involved in the sequence must be attributed to the appropriate features, even though a single user action triggers the sequence. The approach: instrument each feature's inference calls separately, even when they are called in sequence. If the classification is Feature A and the summarization is Feature B, the classification API call is tagged A and the summarization API call is tagged B. The user-facing workflow is a bundle of two features; the cost attribution tracks them separately.

What is a reasonable cadence for reviewing per-feature gross margins?

Per-feature gross margins should be reviewed at three cadences: (1) Monthly — as part of the standard gross margin review. Look for features whose margin is trending down (usage growing faster than pricing captures the cost) or features that have crossed from positive to negative margin territory. (2) Quarterly — as input to pricing decisions. Feature margin data from the prior quarter informs tier design decisions for the next quarter. (3) Before each major release — before adding a new AI feature to a pricing tier, calculate its expected gross margin based on estimated usage and known inference cost. No feature should launch to a tier without a documented gross margin estimate.

How does per-feature tracking interact with model routing decisions?

Per-feature gross margin tracking directly informs model routing decisions. If Feature A has a 20% gross margin and Feature B has a 75% gross margin, and both could technically be served by a cheaper model, the optimization priority is clear: optimize Feature A first because its margin has the most room for improvement. Model routing configured at the feature level routes each feature's requests to the appropriate model tier based on the quality requirements specific to that feature — high-margin features that depend on quality stay on frontier models; low-margin features that tolerate lower quality move to cheaper models.

Allocating AI Inference Costs Back to Individual Customers

AI inference costs pooled at the company level create invisible margin problems. Here is a complete system for allocating inference costs to individual customers, surfacing unprofitable accounts, and pricing corrective action before margins erode.

9 min read

Setting Per-Account Token Budgets Before Margins Erode

Token budgets at the per-account level prevent high-usage customers from consuming margin generated by the rest of the customer base. This guide covers how to design, implement, and communicate per-account token budgets that protect gross margin without creating customer friction.

7 min read

The Breakeven Math on Self-Hosting vs API Inference

Self-hosting AI models promises dramatically lower inference costs but requires significant engineering investment and infrastructure overhead. This guide walks through the complete breakeven calculation — including hidden costs — so you can make the switch at the right time.