More control, 90% less spend with new CDP
A few months ago, I was reviewing our RevOps budget when one line item jumped out: our Customer Data Platform (CDP) spend. It hadn’t changed in over a year, but our use of the platform had. That moment kicked off a deeper audit of our tracking stack and led to one of our most impactful optimizations this year.
As a SaaS company, we rely heavily on event tracking. Whether it’s product analytics, marketing automation, or internal alerts, event tracking touches almost every team.
In our case, everything goes through our tracking setup: backend events from our app, client-side events from the app and website, blog interactions, form submissions. It’s all in there.
We route these events to Snowflake for analytics and further data modeling, Customer.io for marketing, and n8n to power various workflows and automations.
Why we used Segment in the first place
We implemented Segment 3.5 years ago. At the time, it was the obvious choice being the de-facto CDP, with a complete feature set: event tracking, identity resolution, audience building, Reverse ETL, and more.
Around that period, we also rolled out Snowflake as our data warehouse, dbt for data modeling, and later n8n along with custom Python functions on AWS Lambda for workflows and processes.
This is how our stack looked:
Segment integrated with most of the tools we were either using or considering: Customer.io, Mailchimp, Intercom, virtually every SaaS tool out there. We wanted flexibility as we figured out our product analytics and marketing stack.
Plus, Segment came with a lot out of the box: identity resolution (e.g., recognizing the same user across different interactions), data governance, and audience/segment management. Thanks to its rich knowledge base and community, we were fully up and running within a couple of months, and it was working great.
The challenges
As we grew and matured as a business, Segment’s strengths became limitations or simply not needed. For example:
- Identity resolution didn’t work for us due to some complex practices we have in managing users with multiple accounts.
- Too many integrations we no longer needed, as we simplified our stack.
- Audience building was mostly used for marketing, which Customer.io can handle well.
In short, we were using fewer Segment features, and the pricing started to feel unjustifiable. We didn’t need all the bells and whistles that came with the price.
Evaluating alternatives
We considered a few options:
- Composable CDPs like Rudderstack, Hightouch, or Census. Great tools, but still more than we needed, often at similar or higher costs.
- Snowplow: solid for event tracking, but complex, no longer open-source and enterprise-focused. We’d still need a downstream setup.
- Customer.io CDP: tempting, but not out-of-the box compatible with our requirements and we also wanted to avoid vendor lock-in.
- PostHog: combines analytics and tracking, but not optimized for our use case.
- Jitsu: open-source, Segment-compatible, includes Airbyte for ETL, and has a cloud offering. It is simple and powerful and it hit the sweet spot.
Migration plan
Once we picked Jitsu, our plan looked like this:
Set up
We went with Jitsu Cloud over self-hosting. The cost/effort tradeoff made sense, and we can always move to open-source if needed.
Migrate sources
We switched SDKs to send events from:
- Backend
- Client-side
- Custom sources
- Mobile apps
Because Jitsu is Segment-compatible, this was straightforward, only very few modifications were needed.
Connect destinations
- Snowflake: out of the box.
- Customer.io: a couple of lines of JS within Jitsu
- Google Tag Manager + Google Ads: simply enabled, out of the box
- Webhooks: simple configuration, also easy.
Rebuilding the ecosystem
The ecosystem post event capture is mainly split into 2 categories:
Real-time workflows
Many events trigger real-time flows. Example: “Trial Started” triggers cleanup, sales assignment, Slack notifications.
Here’s how that works:
- Jitsu sends the event to Hookdeck
- Hookdeck handles retries/rate limits and forwards to n8n
- n8n invokes custom AWS Lambda functions (managed in Git)
All we had to do was update the webhook URLs and everything else just worked.
Daily syncs
We’re warehouse-first, with all data (including events, backend data etc) living in Snowflake and modeled via dbt models.
Previously, Segment handled Reverse ETL. Now, we do it ourselves:
- Use dbt snapshots to track specific columns. These run every day, so we have a table like this:
- An n8n workflow checks the table and updates the fields accordingly.
Each day, we check for records where:
dbt_valid_from = today AND dbt_valid_to IS NUL
It’s simple, raw SQL within dbt and a daily trigger in n8n. But it works flawlessly.
Audience building
With updated data in Customer.io, we use their segment builder to define audiences like:
“Users who are admins in accounts with X setting enabled.”
These audiences then receive targeted emails or in-app messages.
The new architecture
After all the changes, the new setup looks nearly identical, just simpler. The only real change is how we handle daily syncs.
The results
Cost savings
Huge. Jitsu Cloud costs just 10% of what we paid for Segment. No hidden costs, as we were already managing Snowflake, dbt, n8n, and Hookdeck.
The only new addition was the dbt snapshots for Reverse ETL, but the Snowflake cost for that is negligible.
Control and flexibility
Jitsu’s UI is basic, but functional. It’s actually better than Segment’s for debugging recent events.
Additionally, instead of relying on its own “Cloud Integrations” to bring data in from other systems, Jitsu uses Airbyte connectors, which are far more flexible and follow a more standardized approach. This turned out to be a huge side benefit we didn’t fully anticipate.
Our setup is now clean and modular. No vendor lock-in, we can swap tools anytime.
Support & experience
Frankly, we were a bit nervous about losing Segment’s strong support. But our experience 6 months down the line:
- Jitsu’s team is quick to respond
- Documentation is solid
- Slack community exists (though we haven’t used it/needed it much)
Most importantly, there was no internal disruption and the team is happy with the move.
Final thoughts
This migration wasn’t just a cost-saving exercise. It reminded me how important it is in RevOps to regularly question inherited systems.
Tools that were right for us 3 years ago may not be the right ones now. And sometimes, simplicity beats sophistication.
