Migrated from Hotjar to FullStory - 3 month deployment post-mortem for a mid-market e-commerce

Our migration from Hotjar to FullStory was completed three months ago, and I believe we have now gathered sufficient operational data to perform a meaningful post-mortem, specifically on the pricing and licensing implications. The decision was driven by a need for more granular session replay and better integration with our existing event-driven architecture. However, the shift from Hotjar's relatively simple per-session model to FullStory's more nuanced consumption-based pricing revealed several unforeseen cost dynamics that I suspect are common in the analytics vendor space.

The core of the issue lies in the transition from a **session-centric** to a **data-usage-centric** model. Hotjar's pricing was based primarily on the number of recorded pageviews/sessions per month, which, while potentially expensive at scale, was predictable. FullStory, in contrast, employs a model based on **captured event volume**, measured in "events captured per month." This includes every DOM mutation, network call, click, and console log we choose to ingest. Our initial estimates, based on extrapolated session counts, proved to be significantly inaccurate.

We made two critical miscalculations:
* **Event Density:** We failed to account for the default event capture richness of FullStory. A single user session on our complex product pages generates an order of magnitude more events (e.g., every mouse movement, element visibility change) than the equivalent "session" in Hotjar.
* **Instrumentation Sprawl:** As developers, once we had access to the powerful API, we began instrumenting more custom business and performance events for deeper analysis. This directly and linearly increased our monthly event count.

A concrete example: our "Add to Cart" flow. In Hotjar, it was a recorded click. In FullStory, it became a composite of:
1. A custom `Business:CartAdd` event.
2. Dozens of associated DOM read/mutation events from the UI update.
3. Network events for the API call.
4. Console logs from the service worker.

This richness is valuable, but it directly translates to cost. We breached our contracted monthly minimum within the first 45 days, triggering overage fees.

Our current strategy to manage this involves aggressive data sampling and filtering at the source. We've moved from full capture to a targeted approach, using FullStory's configuration to exclude noisy, low-value events and to sample sessions based on user segment. Here is a simplified snippet of our current initialization configuration, which has stabilized our monthly event volume:

```javascript
window['_fs_debug'] = false;
window['_fs_host'] = 'fullstory.com';
window['_fs_script'] = 'edge.fullstory.com/s/fs.js';
window['_fs_org'] = 'XXX';
window['_fs_namespace'] = 'FS';
window['_fs_sampling'] = 0.5; // 50% session sampling rate
window['_fs_cookie_secure'] = true;

FS('set', {
'sitewide_elements': {
'exclude': [
'[data-testid="recommended-products"]', // Exclude high-churn, low-insight components
'[class*="advertisement"]',
'.chat-widget *'
]
},
'metric': {
'include': ['Business:*', 'Error:*', 'Performance:CLS', 'Performance:LCP'] // Only include specific custom metric classes
}
});
```

The hidden costs extended beyond raw event overages:
* **Increased storage footprint:** The richer sessions consume more data, impacting our internal log aggregation and archiving costs.
* **Compliance overhead:** With more granular data captured, our data retention and PII scrubbing processes became more complex and resource-intensive.
* **Performance tax:** While minimal, the client-side capture script has a non-zero performance impact, which required us to adjust our Core Web Vitals SLOs and monitoring.

Ultimately, the migration has provided superior diagnostic capabilities for our support and product teams, but the total cost of ownership is approximately 2.3x our initial projection. The lesson is that with powerful analytics platforms, the licensing model is intrinsically tied to implementation discipline. A "capture everything" approach is financially unsustainable; the system must be treated as a monitored service itself, with clear SLIs (e.g., event capture rate, cost per session) and SLOs. I am interested to hear from others in the mid-market space about how you've structured your contracts—do you negotiate hard caps, sliding scales, or employ other technical mitigations to keep consumption-based pricing predictable?