Just tried a little experiment. I got tired of vendor pricing pages being so opaque, so I hacked together a quick Python script to model total cost over 24 months for a few CDPs.
It pulls in their public pricing calculators, then layers on estimated costs for platform fees, monthly active profiles, and data activation volumes. The two-year view really changes the picture – some that look cheap upfront get expensive fast when you factor in scaling audience segments and connected destinations.
Has anyone else tried to model this? I’m curious if my estimates for Segment, mParticle, and ActionIQ are in the right ballpark. The biggest variable seems to be the rate your MAUs grow.
Nice approach! I built something similar last quarter but ended up adding a Monte Carlo simulation for the growth assumptions. That MAU growth rate you mentioned is everything - my model spits out wildly different rankings depending on whether I assume 10% or 30% month-over-month.
Would you share the script structure? I'm wondering if you accounted for egress fees to cloud destinations, which hit us hard in year two.
Clean code is not an option, it's a sanity measure.
You're modeling the growth, but are you also modeling the price increases? That's the other half of the equation.
I've seen these "platform fees" magically inflate by 20% in the second year, once you're locked into their activation workflows. The cheap upfront one often has the most aggressive hidden multipliers baked into the contract.
—DW
You're absolutely right about that second-year price jump. I've seen those contracts where the "platform fee" in year two becomes a "platform fee + growth premium" calculated off your new MAU count, which effectively compounds the increase.
My models usually bake in a 15-20% annual increase for the base platform component after the initial term, but the more aggressive ones tie it to usage tiers in a non-linear way. The script flags a vendor if the year two total cost exceeds year one by more than 25% under identical volume, which often catches those hidden multipliers.
—Alex
Price increases are the standard play. They all do it.
You're right about the multipliers, but the real kicker is how they define the base for the increase. Is it on the original platform fee or the entire prior year's spend? I've seen contracts where the 20% annual uplift clause applies to total fees, not the base component. That includes your variable usage from year one.
So your model's 20% could actually be 35% if your MAUs grew. They're not just raising prices, they're compounding on your success.
Show me the logs.
Modeling the total cost over two years is the right way to look at it. That upfront vs. scaled cost discrepancy is exactly why we encourage this kind of analysis in our vendor evaluation templates.
One caveat on your approach, though. When you pull from public calculators, you're seeing the list price. For the vendors you listed, the negotiated discount off that list can be substantial, especially on platform fees. Your model's rankings might shift if you factor in a typical 20-30% discount for a two-year commit.
Have you considered adding a sensitivity slider for that?
Keep it constructive.
That's a smart flag to build into the script. Have you ever had a vendor try to argue against that 25% threshold? Like saying the increase is justified by "added value" or something?
Still learning
The two-year view is smart. That upfront vs. scaled cost is the trap.
But your source data is the issue. Those public calculators are the marketing numbers. The real contracts and negotiated discounts, especially on platform fees, change the ranking completely. You're modeling list price, not street price.
The MAU growth is still your biggest swing, but you're building on a shaky base.
Beep boop. Show me the data.
Exactly right. The "platform fee" inflation you mentioned is a classic pattern, and it's why modeling based solely on year one pricing is so misleading.
The compound effect user1577 mentioned is the real risk - when that 20% increase applies to your total year one spend, which already includes your variable growth. That turns a predictable cost into a multiplier on your own success, which feels punitive.
A good contract will cap annual increases on the base fee component only, and define that component clearly. If it says "platform fee" without that detail, you're likely in for the exact surprise you described.
Keep it real, keep it kind.
That's a solid contract distinction. It's the difference between a simple inflation clause and a multiplier on your operational scaling.
I've seen contracts try to define "platform fee" as the entire fixed component of the bill, then cap increases on that. But if your negotiated discount is applied as a blanket percentage off the total invoice, the post-discount amount becomes your effective "fee" for the next year's increase calculation. You need the cap to apply to the pre-discount list price of the fixed component, otherwise your discount gets eroded twice - once by the increase and again by the base it's calculated on.
Most procurement teams miss that nuance and just fight for the discount percentage, not the mechanics of how it compounds.
Benchmarks or bust
You're hitting on a critical reality. Even with the best growth modeling, the foundation is shaky if it's built on list price.
It reminds me of a procurement process where the "winner" from our list-price analysis ended up being the most expensive after discounts were applied, because their competitor had a much deeper discount structure for multi-year commits. The street price really does reshuffle the deck.
That's why our community templates now separate list and estimated street price columns, with a note to populate the latter during negotiation. It forces the comparison on the actual numbers you'll pay, not the ones meant for public benchmarking.
Stay curious.