Feature Unbundling Tests and Attach Rate Outcomes
Attach rates only matter if customers chose the feature when it carried a price.

What a feature unbundling test measures, and what it doesn't
Vendors across the software market are running the same experiment right now, whether they call it that or not: strip a capability out of the base plan, put a price tag on it, watch who pays. That's a feature unbundling test, and the attach rate it produces answers something no satisfaction survey or usage dashboard can touch. It tells you whether a company built a feature people click on because it's free, or a product line people would notice the absence of. The distinction matters more in 2026 than it ever has, because AI added real variable compute cost to software economics, and "unlimited AI included" turned from a selling point into a margin problem in about a year.
Spend data covering a large pool of software under management points to one dominant vendor pattern heading into 2026: restructuring product lines into multiple SKUs, with the AI layer increasingly positioned as a distinct tier rather than a bundled default. Two forces are pushing this at once. Compute costs no longer hide inside a flat subscription, and investors want AI revenue reported as its own line rather than buried inside base ARR where nobody can size it. Zylo's 2026 SaaS Management Index gives that appetite a number: AI-native application spend grew 108% year over year, and 393% inside large enterprises. That's real money moving, but it only counts as a signal once a company actually separates it out on its own line.
They assume the growth is coming from companies buying more software. The growth is not coming from companies buying more software. The Zylo index shows SaaS portfolios have held flat at around 305 applications per organization even as average annual spend climbed several times over. The growth is coming entirely from how software already in place gets repriced, re-metered, and expanded. Nearly every vendor of consequence is unbundling something right now, and the only question that matters is how to tell if it worked.
A feature unbundling test puts a capability behind its own SKU or its own meter, so a customer has to make a distinct decision, a purchase or a consumption choice, in order to use it. That's the whole mechanism. Once a feature carries a visible price, the test measures revealed preference: does the customer choose it and keep paying, month after month, once the free ride ends?
It does not measure usage, and this is where most teams fool themselves. A feature can rack up enormous engagement inside a bundle and still command zero willingness to pay once priced separately, because usage inside a bundle proves nothing about value outside one. Satisfaction scores don't help. Neither does an adoption rate calculated while the feature was still free. None of those numbers survive contact with a price tag.
Livmo's "Switch-Off Test," described in recent research, cuts through this cleanly: if the AI capability stopped working tomorrow, what changes on the customer's invoice? Nothing changing means the company shipped a feature. A line item disappearing means it built a business. That reframes attach rate from a vanity metric into an accounting question.
Nominal attach rate, the percentage of accounts with the feature switched on, is the number most dashboards show, and it's close to meaningless on its own. Quality attach rate asks the harder question: what fraction of accounts bought the feature deliberately, on its own line, and kept consuming it afterward? Bain's analysis of roughly 200 B2B SaaS companies makes the gap concrete. A company claiming $5 million in ARR, with $1.5 million tagged as "AI revenue," actually splits three ways. $400,000 sits on a genuinely separate AI product line customers chose on purpose, and that bucket survives due diligence intact. $300,000 comes from AI credits customers are actively burning through and topping up, which survives diligence with a margin question attached. The remaining $800,000 comes from customers who bought a plan that happened to contain AI, without ever choosing AI itself. Nobody in that third bucket made a decision about the feature. They made a decision about the tier, and the AI came along for the ride.
That third bucket is the norm. Bain's research shows roughly one in five AI-native software companies still charges mostly per seat and folds AI in for free. The unbundling test exists to convert a vague claim of "we have AI" into a defensible claim of "we have AI revenue," and the gap between those two claims is exactly the gap between the first bucket and the third.
Structuring an unbundling test for clean attach rate data
None of that diagnostic power exists unless the feature gets metered separately the moment the test starts. Without real-time consumption counting, there's no attach rate to read, only an invoice line that's either present or absent, with nothing in between to learn from.
Three decisions decide whether the resulting data means anything, and the first one is where most tests go wrong before they even launch. What's the actual value metric? It has to be the specific unit tracking with what the customer gets: tokens, API calls, agent actions, completed tasks, tied directly to delivered value rather than whatever's convenient to bill. Companies that correctly identify their core value metric grow revenue meaningfully faster than companies still pricing on flat, fixed terms. Second, who's in the test population? New accounts and existing accounts answer different questions, willingness to pay at acquisition versus willingness to pay at expansion, and blending them muddies both answers past the point of use. Third, what's the counterfactual? A control group still on the bundled version, or a clean before-and-after cohort, has to exist, or the attach rate collapses into a plain usage number with no pricing signal inside it.
Pricing history across the industry shows what happens when the first decision goes wrong. Some companies have shifted their core billing metric after discovering the original unit didn't line up with how customers actually experienced value. That's the risk built into metering the wrong thing: the test still runs, the attach rate still comes out a real number, and it still tells nobody anything useful, because it measured the wrong unit from the start.
Most companies now run a hybrid structure as the default test vehicle: a subscription for access, paired with metered consumption, credits, or outcomes, layered on top. The access piece keeps buyers willing to enter the test. The consumption piece is where the actual attach rate signal lives. The access-and-consumption split has emerged as a widely observed pattern in 2026 packaging, for a straightforward reason: it separates the decision to try the product from the decision to pay for using it heavily.
Timing matters as much as structure, and most vendors ignore it. Bessemer Venture Partners characterizes 2025 as a year of "AI adoption at all costs," when price sensitivity was minimal because budgets were loose and nobody had gone through a renewal yet. Many of those same customers hit their first AI renewal cycle in 2026, facing a real budget conversation for the first time about a feature they adopted almost reflexively a year earlier. A test that only ran during that early adoption window overstates the attach rate, because it never priced in renewal-stage scrutiny.
Most companies aren't running these tests at all, and that gap is the real competitive edge. A small fraction of SaaS companies conduct pricing experiments on any regular basis, yet the ones that do tend to grow meaningfully faster than the ones that don't. Running the test consistently, not as a one-off event, is a competitive advantage in itself.
Reading attach rate outcomes: the difference between a feature and a product line
A single attach rate number doesn't say much by itself. Read it against three separate dimensions, each answering a different question about durability.
Take rate on the first offer shows what fraction of eligible accounts activated the SKU or started metered consumption. Retention rate is the harder test: what fraction are still consuming the feature in month two, month three, month six? A take rate that looks strong at launch and collapses two months later is measuring novelty, not value. Expansion rate closes the loop: are attached accounts consuming more over time, a sign value is compounding, or did consumption plateau the moment the account signed up?
That decomposition applies here as the exact lens investors and acquirers use during diligence. The $400,000 bucket of intentional purchases and the $300,000 bucket of active, topped-up credits both survive scrutiny. The $800,000 bucket, tied to plan tiers rather than deliberate feature choice, does not. A company whose "AI ARR" lives mostly in that third bucket has a feature sitting inside a plan, not a product line standing on its own, and no amount of dashboard framing changes that.
A genuine product-line attach rate has a distinct shape. Customers who weren't buying the feature start buying it, they burn through their credits and come back for more, and their consumption climbs rather than holding flat. That top-up behavior, choosing to spend more because the meter ran dry, is the clearest sign of real value capture available in the data. A feature-level attach rate looks nothing like that: high nominal attach inside a bundled tier, almost no revenue on a separate line, no top-up activity, and willingness to pay that evaporates the moment the feature gets priced on its own at renewal. That's the signature of a capability nobody actually chose.
Which brings the renewal cliff into focus. The broader point about 2026 being the first real renewal cycle for AI features means attach rate data collected during 2024 and 2025 pilot windows is now getting tested against budget owners who've had a year to decide whether the feature earned its keep. Renewal retention, not initial take rate, is the cleanest proof a feature actually crossed into product-line territory.
Some vendors are pushing past consumption pricing entirely toward outcomes. Salesforce and HubSpot have each moved toward outcome-based models, representing the direction attach rate data points a company toward once value is clearly tied to tasks completed rather than raw usage volume. That's the direction attach rate data points a company toward once the value metric is clearly tasks completed or results delivered rather than raw usage volume, though only a small fraction of companies have reached that stage so far.
Vendor packaging pivots that illustrate what attach rate signals in practice
Microsoft's structure for 365 Copilot Enterprise shows the hybrid model at real scale. The add-on runs $30 per user per month on an annual commitment, with additional consumption capacity available on top for usage spikes, metered separately from the base subscription. The design captures steady-state value from the flat fee while letting high-consumption workflows generate their own revenue, without forcing a mid-contract renegotiation every time someone's usage spikes. The credit overage layer states the attach rate directly: does this customer consume above the line they already paid for, or not?
New Relic offers the cleanest before-and-after case available. Starting from an ARR base well into nine figures, the company moved off host-based subscription pricing entirely onto pure consumption billing. Attach rate data at scale revealed that value was always usage-driven, and a flat subscription floor had been quietly suppressing expansion the whole time, producing a reported 44% increase in annual revenue run-rate.
Adobe's Firefly packaging works through a credit ceiling rather than a hard SKU split. Higher-tier plans come with a larger allocation of monthly generative credits per user, while base plans include a more limited credit allowance. Customers who blow through their credit allotment and pay for more are the attach rate signal in its purest form. Customers who never come close to the ceiling are, functionally, the bundled population, using the feature because it's there.
SAP restructured its RISE packages into a single consolidated SAP Cloud ERP Private bundle, while pulling certain premium capabilities, AI units and analytics tools like SAP Datasphere, out into optional add-on SKUs. That's unbundling and rebundling happening at once, at enterprise scale, and the attach rate on each new standalone SKU becomes the real measure of which capabilities the market values on their own, separate from the ERP core they used to live inside.
Atlassian blends subscription pricing, bundled AI entitlements, and consumption overages inside a single contract. L.E.K. Consulting noted that Atlassian raised cloud prices by up to 10% that October, citing higher compute demand tied to new AI features. That structure creates three distinct customer populations at once, each generating its own slice of attach rate data across the spectrum from pure subscription to pure consumption.
Some vendors have cycled through multiple distinct pricing models for the same underlying product inside roughly eighteen months, moving from action-based credits to per-user licenses in rapid succession. That kind of rapid repricing suggests attach rate data was actively steering each change, and it exposes the operational cost of doing this without infrastructure built for it. Repricing that fast, that often, is expensive to execute by hand.
Every one of these pivots ran into the same wall eventually. Each required billing infrastructure that could model a new charging dimension and shift the pricing logic without a rebuild each time, and that requirement is exactly where most teams get stuck.
Why running unbundling tests breaks most billing stacks
Most billing platforms were built to handle subscription plans and their renewals. The instant a product needs to charge for what customers actually consume, tokens, GPU-minutes, API calls, individual agent actions, those platforms hit a wall, because they were never built to count any of that.
An unbundling test needs three things a typical subscription billing tool doesn't have. It needs a new charging dimension that can be modeled immediately, because a test requiring an engineering sprint just to configure an AI credits SKU has already missed the window where the test would have mattered. It needs real-time metering of consumption, since attach rate quality depends on knowing whether a customer is actively consuming and topping up, and a batch billing system with numbers hours or days stale can't produce that signal. And it needs to run the old pricing model and the new one side by side, since existing accounts often stay on the bundled plan while new accounts enter the test, and the billing stack has to handle both without spinning up a separate reconciliation process just to cope.
Every month, finance reveals the tell that a company is stuck here. Finance runs three separate billing codepaths and spends the first week of the month reconciling numbers across all three, because each unbundling attempt bolted on a new codepath instead of extending one system that could already handle it.
The common fix, bolting a metering tool onto a billing tool through integration, creates a maintenance surface that worsens with every new pricing dimension added on top. Around 73% of vendors now charge separately for AI features. The entire market is hitting this same wall at roughly the same time. Once a product has to bill across tokens, GPU-minutes, audio minutes, megapixels, and hardware tiers all at once, no single ad hoc fix covers every dimension, making the problem structural rather than a configuration headache. Only infrastructure built from the ground up for multi-dimensional consumption survives that kind of pressure.
Billing infrastructure requirements for continuous pricing tests
Hiring more engineers doesn't fix this. Treating metering and billing as one problem from the start, instead of two tools stitched together after the fact, does.
Real-time event ingestion is the floor, not the ceiling. For AI products specifically, that means recording tokens and API calls at roughly the speed they happen, not batching them into a nightly job. The full pipeline, ingestion, metering, rating, has to run continuously, because a pipeline that wakes up once a day can't tell anyone whether a customer topped up their credits an hour ago.
The choice between stream processing and batch processing decides whether attach rate data is something a team can act on or just something they look at after the fact. A stream architecture applies billing logic the instant an event lands, which is what makes live spend dashboards, real-time alerts, and hard usage limits possible: limits that can actually stop a request the second a customer's credit balance hits zero. Batch systems can't do any of that. Their billing state is already stale by the time anyone looks at it, and the one signal that matters most, whether a customer topped up, becomes visible too late to act on.
Recovery matters as much as speed. For billing specifically, the accepted target is zero lost events: every token consumed gets counted exactly once, no exceptions. That means idempotency key support in the ingestion layer is required. It's the mechanism that keeps a retried request from getting billed twice.
Prepaid credit wallets need to sit on the same engine as postpaid invoices, not bolted on separately. The voluntary top-up behavior that signals a genuine product-line attach rate is a wallet mechanic by definition: a customer choosing to add money to a balance they control. A billing system that can't model a prepaid balance living next to a normal invoice cannot see, or charge for, the single most important signal in this entire exercise.
Pricing itself has to become a lever product and finance teams pull without filing an engineering ticket. The typical SaaS company already adjusts pricing and packaging several times a year, and its infrastructure has to make each adjustment, a new value metric, a different credit price, a fresh tier, safe and fast rather than a multi-week project.
Customers need to see their own spend with the same clarity. Roughly 78% of IT leaders report unexpected charges tied to consumption-based or AI pricing, and more than 90% of CIOs name cost management a major obstacle to getting real value out of AI. Real-time usage dashboards and spend alerts aren't a side feature. They decide whether a customer trusts the meter enough to keep letting it run.


