Segment raises $64M led by Y Combinator
segment.com
segment.com
I hope they sort these problems out, and build a better developer product. Right now, they're focused on the enterprise, and I'm amazed their product is sufficient.
I'm writing this because their team is amazing and kind, but I hope they improve their product.
On the other two issues...
Analytics.js launched on HN in December 2012. It had some bugs in its early form, but it has certainly become a lot more stable in the five years since then. Today it runs without issue on 500m+ browsers and hundreds of thousands of websites each day.
For event delivery, you can see real-time event deliverability and latency stats on our public status page: https://status.segment.com
For most services we deliver data in a few hundred milliseconds, but some services consistently drop data. We retry that data over the next 12 hours, and this actually increases the deliverability to our partner endpoints. (For example, we're improving deliverability to Iron.io from 95.4% to 98.4% right now.)
For us, latency means the time between when the _event_ actually occurs in real life (user clicks on a button) and when it showed up in all of our analytics integrations (Mixpanel, Intercom, etc.). As developers, this is the definition of "latency" that really matters for us because it represents the minimum time before we can take action on our users' behaviors.
The reason I'm very skeptical is because what we were actually seeing was orders-of-magnitude differences from the 44 ms "latency" claimed on your status graph and what we were measuring ourselves (~1-10 hours for us) -- not just 10% differences which would have been more than acceptable for our use case.
For example, Intercom support were able to identify a four hour delay from when the /identify actually took place and when Segment sent the event to Intercom. Segment Support then mentioned a race condition with their Intercom integration that they had yet to solve (we ran into this ourselves -- we had to guarantee we called /identify BEFORE calling any /track calls).
With Mixpanel, not only were we experiencing multi-hour delays, we also experienced many nonsensically mis-ordered events when using Segment (even with timestamping -- it turned out that Mixpanel still relied on events being ordered properly within a 2-minute window -- something we were only able to guarantee by directly sending events to Mixpanel ourselves).
Segment's response: "Our infrastructure is built on top of a queue system that accommodates high scalability. The drawback to this is that sometimes events are received by our API in a mixed up order because we have multiple queues feeding events to multiple workers."
These problems were all resolved immediately when we started issuing direct calls to our various analytics providers.
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.
This. I call it "end-to-end latency" and it doesn't get nearly as much attention as it should. This is, by the way, why it's a bad idea to use most OLAPs (like Redshift) as a backend for Segment if you want "real-time" analytics. Column-oriented OLAPs are not designed for real-time ingest because either they don't support streaming inserts (Redshift) or it's not particularly reliable (BigQuery).
Separately, you can always use BigQuery's federated query capability of Bigtable.
(work at G)
I've heard this from many users through my work on Fluentd (in fact, many end up using fluent-plugin-bigquery because they don't want to deal with the minutiae of insertId and whatnot on their own).
Also, I don't think a lot of people fully understand the quota policy and get tripped up: https://cloud.google.com/bigquery/quota-policy
>Separately, you can always use BigQuery's federated query capability of Bigtable.
Yes, and very few people understand what that means (I had to look up, and I am reasonably educated on GCP). This is not necessarily product shortcomings but packaging deficiencies that can be addressed with better product marketing.
There was one short outage I can remember in 2015, the only other issues we ever had, we traced back to misconfiguration on our side.
I think Segment's core code is _really solid_, it shows in how fast a relatively small company is able to iterate, update and release new product.
I think their biggest challenge is educating potential users on what they do (no exact competitor) and educating new users on how to set it all up properly (gotta read the documentation.)
I think judging a 6-year old startup based on what its product was one year into the company is rather unreasonable. To put this into perspective, 80% of the company's lifespan has occurred after the grandparent's negative experience. Things change dramatically in that period of time.
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.
One thing I'd like to see is a better free tier for developers starting new projects. Currently, you're limited to 1000 visitors per month.
Even indie projects can quickly run up monthly costs of $100+.
As a comparison, Mixpanel's free tier gives devs 20 million data points per month.
we also have an incubator/accelerator discount for pre-series a, just email friends@segment.com and we can get you set up.
We got 3 months free from Founderskit (via Startup School). Is there a better discount than that? If yes, that would be helpful!
* Sync Salesforce to Redshift - then perform queries across it * Sync all incoming lead to Salesforce * Enrich incoming leads with person/company data * Fire webhooks to lambda processing incoming signup events, qualifying them, and then triggering subsequent events
All I need now is for them to add the ability to push my events in real time to my Kafka cluster. (Please add that!)
I feel like I'm missing a lot of the picture. :)
The founder straight-up admits in this article that the problems they're solving are largely simple. To my mind, there's no need for a hosted service. Why hasn't Segment been replaced by an open-source project?
I'm not trolling here...I really don't understand the full value.
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.
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.
We're in a world where people would rather self-host github to save a few bucks...this is an easier problem.
Analytics.js could be replaced by a self-hosted/bundled solution in theory, but Segment's server-side integrations are an extremely valuable piece of network plumbing. It's awfully nice that I was able to set up a few endpoints on our API (quick) and went through the approval process (sorry, not quick) and now my customers have a super-easy option if they want to point their data hose at us.
All they need to do is install some dashboard, data processing tools and think of what data they want to correlate with other data and if that correlation has any interesting meaning.
But of course having your company listed at a hot startup site is simply exposure or marketing too. Maybe those companies don't even use it, they just want their logo to be shown every where on the 'hot' parts of the web.
And having listed on your site that 15.000+ companies trust you? Why do you still need to raise money then? Start charging people if your product has value.
Also as a private citizen can i request at Segment if you are storing, processing or handling my private data (provided by parties i did business with) in anyway?
And special kudos to Peter, who provided direct hands on tech help for one of my clients during our crunch time.
We need more solutions similar to Segment which make we-are-too-much-invested-in-that reason less and less common.
Their pricing plans seems to reflect this by have a 'free' tier that supports nothing more than a quick test MVP, then a paid plan in a VERY high price range that would be considered negligible for someone who has just secured $100M in venture cap.
Feel for we founders who want to stay bootstrapped, and who will be paying for tools out of nothing but slowly trickling in revenue from paying customers. For us, $250+ per month is a real cost, and not a flippant consideration in the early stages of our growth.
I'd much prefer to see vendors have more gradually tiered pricing plans, or else peg the cost to a meaningful metric, such as 'per paying customer' rather than 'per anonymous site visitor' etc.
I have been very impressed with the content of their engineering blog lately, and am not surprised to hear they are doing well. They have an awesome team, and a lot of developers really respect them.
Some other comments in here mentioned having a bad experience with their product, but I think that was back in 2012 when they were still a small start up. In my experience, their product is solid.
That said, there are quite a few places left for us to optimize. We're hoping to share more of the techniques and architecture we've used to get better performance in upcoming blog posts.
[1] https://segment.com/blog/the-million-dollar-eng-problem/ [2] https://segment.com/blog/spotting-a-million-dollars-in-your-...
doing the math... you have $50m in revenue so you can buy another $25m in recurring revenue with that. and then you need another $50m in capital from somewhere to add the other $25m in recurring revenue to get to $100m ARR total.
it also follows from the math above that the faster you grow revenue, the more capital you need. :) saas math is a bit funky.
As a counter example, many companies are using excess cash to buy back stock and not grow the biz.
As another example, what did Github did with their $100MM? I'd argue that the Github product and client base looks substantially similar to what it did before a16z gave them that chunk of change.
Great people, great product and great contributions to OSS. Well deserved and keep rocking!