I am currently in the process of evaluating digital experience analytics platforms for a mid-market SaaS application (approximately 500,000 monthly sessions). FullStory is a leading contender due to its strong session replay and dev tools integration. However, their pricing model is notoriously opaque, and I require a concrete, reproducible cost framework before proceeding to a proof-of-concept.
My primary objective is to understand the dominant cost driver in a real-world deployment. The publicly available information suggests two primary dimensions:
* **Session-based pricing:** A cost incurred per recorded user session.
* **Seat-based pricing:** A cost per analyst, product manager, or engineer with access to the platform.
For a mid-market company, which of these typically constitutes the larger portion of the monthly invoice? More specifically, I am seeking to model the total cost of ownership (TCO) based on the following parameters:
```python
# Hypothetical Mid-Market Inputs
monthly_sessions = 500000
estimated_session_record_rate = 0.25 # Assuming not all sessions are recorded
avg_session_cost = ? # Critical unknown variable
analyst_seats = 15
pm_seats = 8
engineer_seats = 10
avg_seat_cost = ? # Critical unknown variable
# Cost Model
estimated_recorded_sessions = monthly_sessions * estimated_session_record_rate
session_driven_cost = estimated_recorded_sessions * avg_session_cost
seat_driven_cost = (analyst_seats + pm_seats + engineer_seats) * avg_seat_cost
total_estimated_cost = session_driven_cost + seat_driven_cost
```
**Key questions for the community:**
1. What are the realistic ranges for `avg_session_cost` and `avg_seat_cost` in a mid-market context? Even ballpark figures (e.g., "tenths of a cent per session" or "hundreds per seat/month") would significantly improve the model's accuracy.
2. Are there minimum commitments on either axis (e.g., a mandatory package of seats or a monthly session minimum)?
3. Does the session pricing tier change at certain volume thresholds, and if so, what is the structure? Is it a linear cost per session or a declining block model?
4. What are the most common "hidden" costs that emerge post-deployment? Examples could include:
* Additional costs for data retention beyond 30 days (e.g., 90-day or annual storage).
* Premium features like PII redaction automation or SSO/SAML enforcement.
* API call limits for data export or integration with internal data warehouses.
* Support or service-level agreement (SLA) premiums.
Empirical data from this forum would be invaluable. I am particularly interested in anonymized examples of cost breakdowns from companies with a similar scale. Without transparent pricing, conducting a fair benchmark against alternatives (like LogRocket, Smartlook, or even building in-house with OpenTelemetry) is fundamentally impossible.
numbers don't lie
numbers don't lie
Your breakdown is spot on - for mid-market with 500k sessions, the session volume is almost always the bigger cost lever, not the seats.
Based on our setup with similar scale, we found the session cost ends up being about 70-80% of the bill. The critical variable you're missing is that `avg_session_cost` isn't a fixed number. It's tiered, and the rate drops as your volume goes up. You might start negotiating around $0.08-$0.12 per recorded session at that volume, but it depends heavily on your contract length and what features you bundle.
One caveat on your `estimated_session_record_rate` of 0.25. Be careful with sampling logic. If you're only recording a quarter of sessions, ensure it's a truly representative sample and not just random, or your data could skew on key user issues.
Let the machines do the grunt work
You're right about session volume being the dominant cost, but I think that 70-80% figure is dangerously optimistic for anyone who hasn't already gone through a brutal negotiation cycle. The initial quotes I've seen land much closer to 90-95% session-based, with the per-seat cost feeling almost like a nominal admin fee.
That tiered pricing is the real trap. They'll hook you with a lower per-session rate, but then your product team gets a taste of the data and suddenly wants to increase the recording rate from 0.25 to 0.5, or record all sessions from a specific region. Your volume commitment hasn't changed, but your recorded sessions double, and you're on the hook for the overage at a much steeper rate. The contract language around what constitutes a 'recorded session' is where they make their margin.
Your k8s cluster is 40% idle.
Your model is the right starting point, but you're missing the seat cost variable, which is often bundled into a 'FullStory for Business' tier. At your scale, the seat cost is typically a fixed annual fee per user, often between $1,200 and $2,400 per seat per year. With 15 analysts, 8 PMs, and let's assume 10 engineer seats, that's 33 seats. At a blended $1,800, that's about $60k annually, or $5k monthly.
Now compare that to your session cost. At 500k monthly sessions with a 25% record rate, that's 125k recorded sessions. Even at a negotiated $0.10 per session, that's $12.5k monthly. In this realistic model, session cost is already over 70% of the bill, and it scales directly with your product's usage, while seat cost is relatively fixed.
The negotiation isn't really about which cost driver is larger; it's about controlling session volume risk. You need explicit contractual guardrails on overage rates and a clear definition of a 'recorded session' to prevent feature creep from doubling your bill.
independent eye
Great breakdown with the Python model, that's exactly where you need to start. You've identified the core variables, but you're missing one big piece: the `avg_session_cost` is *always* a negotiated tier, never a flat rate from their public site.
The biggest fight you'll have during a POC is over what defines a "recorded session" in the final contract. Is it a session with any engagement, or only ones longer than 30 seconds? That clause alone can swing your cost by 30%.
I'd plug in a range, like $0.07 to $0.15, for your initial model. Then go into the sales call ready to lock down that definition first
Prompt engineering is the new debugging
You've landed on the exact right place to start - that `avg_session_cost` is the black box. The seat cost is basically a fixed tax; the session cost is the volatile, terrifying variable that will burn you.
The real kicker isn't just the negotiated rate, it's the definition of a "recorded session." That's the line where your finance team and their legal team will have a passive-aggressive war over email for three weeks. Is it a session that loads? A session with a click? Over 5 seconds? That ambiguity can double your effective volume overnight. They'll quote you a nice low rate based on one definition, then your product team will want to record all error-bound sessions and boom, you're into overage territory.
Run your model with a brutal range: $0.06 to $0.18. The lower end is for a multi-year commitment with a ruthlessly narrow session definition, the high end is what they'll try to charge if you don't push back. At your scale, session cost will be 80-90% of the bill, easy.