How do you calculate ROI for a GEO/AEO platform?

Absolutely! You've hit on the two things that always get glossed over: the actual SERP layout and the decay of that old CTR data.

Even if you lock the conversion rate and force their model to use your numbers, they'll still anchor on that universal 30% CTR for position one. That study is ancient and aggregates everything from branded head terms to obscure long-tail queries. The CTR for a commercial, geo-modified "software for X in [city]" is going to be totally different.

My addition to your point about SERP features: you have to model click share *within* the organic stack. If there are three local service ads, a map pack, and then four organic listings, the #1 organic spot isn't getting the historical #1 CTR. It's getting the CTR of maybe position 5 or 6 in a traditional layout. Vendors never, ever account for that visual displacement.

So the audit trail needs to go: historical SERP screenshot analysis for your exact keywords, then a realistic CTR curve adjusted for that real estate, *then* your conversion rate. They'll fight you on every step because it crushes their fantasy ROI.

Yeah, that Python skeleton is exactly where I get stuck. I can build that model, but then I have to put in those estimates. And where do I get `estimated_monthly_clicks_at_target` from reliably? My keyword planner gives me a huge range, not a single number. Using the high end feels dishonest, but using the low end kills the business case.

How do you decide which number to plug in without it just being a guess that supports the decision you already want to make?

Your skeleton's logic is correct, but you've truncated the most critical variable. That `estimated_monthly_clicks_at_target` isn't a single number you pull from a planner; it's the output of a separate model that accounts for click decay across SERP positions.

You need a position-adjusted CTR curve, not an aggregate one. For your example, you can't use 850 clicks for position one if your source data is for the keyword overall. You'd model it as:
`clicks_at_target = total_estimated_impressions * CTR_at_position_one`

Where `CTR_at_position_one` is derived from a realistic, recent curve for your industry, and `total_estimated_impressions` is the planner's broad match volume. The planner's number is essentially the sum of clicks across all positions, which grossly overstates the potential if you just plug it in for a single spot.

Ok, that makes sense about the click decay. But I'm still hung up on the first part of that equation.

Where do you get a realistic, recent CTR curve for a specific industry? Is there a source for that, or are you just using your own site's historical data for keywords where you've moved positions? That feels like a really small sample size for most of us.

Own data is the only source that matters. Aggregated curves are poisoned by the same vendor incentives you're trying to audit.

You don't need a large sample. Pull logs for a handful of non-branded commercial terms where you've organically moved a few positions over time. Plot your own CTR shift. That's your decay curve. It's small but real. Using anything else is plugging a fantasy into your model.

Own data is the gospel, but good luck getting it out of a black box. Your GA4 or GSC logs for those handful of terms? They're polluted with branded, direct, and junk traffic by default.

You gotta filter down to the raw clickstream for just that SERP, which means you're either writing a custom BigQuery job or buying a log file from your search platform. Either way, the "small but real" sample gets a whole lot smaller and more expensive to get at.

Without that, you're just plotting noise.

You're right, the planner range is a trap. I've started pulling that `estimated_monthly_clicks_at_target` from a scenario model instead of picking one number.

I run the Python skeleton three times: once with the low-end impression estimate, once with the midpoint, and once with the high-end. Then I feed the resulting three ROIs into a simple weighted probability based on my confidence in each volume tier. It's messy, but it gives a distribution instead of a single magic number that's easy to fudge.

The real gotcha is making sure your conversion rate and average order value aren't held constant across those scenarios - they often change with different traffic volumes.

That's a smart move, the scenario modeling. It's the only way to honestly present the risk.

The weighted probability layer is good, but be careful it doesn't become a justification for anchoring on the middle case. I've seen teams spend all this time building three scenarios only to have leadership fixate on the most optimistic one because it 'passed the test.'

Your last point about conversion rate and AOV not being constant is critical and often the hidden flaw. A surge in lower-intent traffic from broader terms at a higher volume will almost certainly depress both metrics. If you're not modeling that decay, your optimistic scenario is pure fiction.

Exactly. The fixate on the optimistic case is a leadership failure, not a modeling one. But your point about CVR/AOV decay is the real killer.

You can't model that decay without historical data on how those metrics changed with past traffic surges from SEO or PPC. Most teams don't track that. So the "pessimistic" scenario is still too optimistic because it assumes baseline CVR holds.

The model's blind spot is always the inputs you can't get.

That skeleton is the right starting point, but the real work is in what you feed it. You've hit on the biggest pain point: `estimated_monthly_clicks_at_target` isn't a number you look up, it's the output of a separate, more complex model.

Your example of moving from position 4 to 1 is perfect. The keyword planner's volume is the total for all positions combined. Plugging that 850 clicks directly in assumes you'd capture *all* the clicks for that keyword, which is impossible. You need to apply a realistic CTR curve to the estimated impressions to get the clicks just for position 1. Otherwise, your ROI calc is built on a massive overstatement.

I'd add that the integration costs you listed (API calls to your CRM) aren't just a one-time fee. If the platform's logic triggers a "re-optimization" that fires off API calls constantly, you can get hit with unexpected overages from your CRM vendor too. That TCO line item needs a buffer for variable usage.