Segment raises $64M led by Y Combinator

Segment is perfect example of a small solution that proved to be extremely useful for everyone. I imagine Segment can grow to an extent that it'll start affecting other products' customer base—or maybe it already has. Earlier if a company was using Mixpanel, moving away would have meant wasting hundreds of man-hours to switch to a newer solution, which could have deterred companies from having that discussion. With Segment, it'll only take a few clicks.

We need more solutions similar to Segment which make we-are-too-much-invested-in-that reason less and less common.

Hey, this is Ilya - i'm one of the co-founders and original author of the .NET library - I'm really sorry that happened. In the early days, I was the author of 5 of our open source libraries and also a student of the .NET platform.

Today we have a larger team working on our libraries - .NET in particular has 200+ customers (mostly on our business tier) and we're processing 21B+ API calls/mo originating from .NET. If you could send me an email at ilya@segment.com, I'd love to chat live and collect any other feedback you have from the experience. Thanks again for leaving the note.

Any individual connection is simple. Website to Mixpanel? Easy. Mobile app to Facebook App Events? Also simple. Both website and mobile app to warehouse? Bigger investment but still doable. Data out of Stripe and Zendesk into the warehouse? Also reasonable straight forward to build, more annoying to maintain, very annoying to scale.

The issue is that companies need all of this together. And they need it now. Many enterprises have 100+ business units each using 50+ tools and all of that needs to be connected together.

So the issue isn't that building a single connection is hard. It's that managing N interconnected things is N^2 hard, and N^2 gets big very very fast. Wrangling that mess is just way too complicated for an open source project... even though analytics.js is open source, the vast, vast majority of a.js users only use it through Segment.

I've personally built all of the things you're talking about, on real products, with lots of traffic, and it just isn't that hard. Annoying, yes, but arguably a core competency of any data team, and something you want to think very carefully about outsourcing. Also, most teams won't have to "scale" many of the things you're talking about...that's a problem that you only have to solve when you're the central point of failure for lots of companies.

As for the n^2 problem, yes, I can see that argument, but in my experience, n is always a small number (i.e. 2-10), and they rarely need to cross-communicate in a fully connected graph. In short, piping everything through an expensive, centralized point-of-failure run by strangers seems like such a risky proposition that I can't imagine many companies would have the integration complexity to justify the risks.

But again, people seem to be finding value in it, so maybe I'm missing something. I was honestly expecting you to tell me something about advanced data warehousing or integrated analytics tools or something like that. If you tell me that integrating with segment automatically starts correlating session data across providers, well...that starts to be compelling.

Hey, I’m one of the Segment founders. I helped instrument a lot of these metrics and built the status page Peter linked to above. I’m hoping I can help shed some light on some of those numbers.

The 44ms you’re referring to is the time it takes our API to respond to an incoming call and ingest an event. It’s certainly not the wall clock time, but it is a good measure of the overall health of the system. Your feedback about its prominence is definitely good–it’s our goal to be transparent, not misleading. We’ll change the area where it’s displayed shortly.

If you’re looking for the ‘end-to-end’ wall clock time, you can find that a little further down the page. For every event coming through our pipeline, we average the time from ingestion to successful delivery and display those metrics on a per-destination basis.

You can see right now that the Google Analytics end-to-end delivery latency is ~400ms within the past hour, and is pretty consistently near that number. We’ve also developed internal systems which break down exactly how many events from a given source were delivered to a given destination, and what the latency distribution for those events was.

The ordering problem you mention is indeed tricky. Like TCP, if we wanted to keep a loose ordering, we’d have to keep a window and ensure the partner API would then re-order messages appropriately. If you want a total ordering, this window of delivery _has_ to be 1 for a given user. It does have some pretty serious implications on the throughput of the system, so we’ve been working with both Mixpanel and Intercom (we’re users ourselves) to try and solve the issue just with timestamps. Ideally, partners would be able to re-order events received based upon time, which is what we do inside of customers’ data warehouses.

As far as the deliverability issues you mentioned, I’m terribly sorry to hear that we failed you here. We’ve hit some scaling bottlenecks that we’ve been working hard to fix–and we do our best to keep the status page updated whenever we have production incidents.

All that said, reliability is our top focus as a company. Teams present their SLA metrics on a weekly basis at all hands, and it’s a key part of our monthly board reporting. We’ll be surfacing these metrics and event traces inside the webapp so as a customer can see exactly where your data is, and what has been delivered. And we’re in the process of building an entirely revamped pipeline that will provide better deliverability guarantees. We plan on sharing the architecture on the blog once it’s all rolled out. Giving you transparency into where your data is stored and how it is processed is exactly what we want to achieve as a company.

If there’s anything I missed–please reach out! I’m calvin at segment.