
Segment raises $64M led by Y Combinator - gwintrob
https://segment.com/blog/segment-raises-64m/
======
tonydiv
Had nothing but problems with their product over the years. In 2012, they had
a bug in their analytics.js which resulted in me losing about 10k new users.
Last year, I was experiencing multi-day delays between an event and it
appearing in Mixpanel, Intercom, etc. Prior this year, I was using Branch and
then realized how many sacrifices you make when you use Segment – they will
never be up to date with all the most recent SDKs/APIs, so you will always be
pulling your hair out. We ended up using Segment + 4 other services, it would
have been better to not use Segment at all.

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.

~~~
pkrein
Shoot. I'm sorry this happened. I'd love to chat more about your experience
with Branch SDK/APIs recently. I found your email in another HN comment and
will reach out shortly.

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](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.)

~~~
Hydraulix989
Latency can be more or less questionable depending on when the stopwatch
button is pressed. For example, in VR, the gold standard is "motion to photon"
\-- anything else is just not representative of what actual latency means for
actual users (i.e. getting motion sick). There are many definitions of
latency, so it's important to choose the right one (the one that matters for
your users).

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.

~~~
calvinfo
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.

------
jzebedee
We used Segment for application analytics and exception reporting in an
enterprise setting. Their .NET libraries were abysmal and had some show-
stopper bugs that we wrestled with, particularly broken dependencies. I
eventually had to fork the Analytics.NET repo and fix them myself. It was
months before I heard any response to the issues or PRs, although they did
eventually get merged in. It was just disappointing overall. I don't know why
they'd release .NET tooling but have it be broken out-of-the-box, or maintain
an open source project but not respond to any contributions.

~~~
ivolo
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.

------
mijustin
I've been a Segment user, and advocate, from the beginning. It was highly
recommended in the book Marketing for Developers.

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.

~~~
pkrein
thanks justin! would you be open to putting a badge on your site (similar to
mixpanel's)?

we also have an incubator/accelerator discount for pre-series a, just email
friends@segment.com and we can get you set up.

~~~
sorich87
I'm not the GP but we would totally be open to putting a badge!

We got 3 months free from Founderskit (via Startup School). Is there a better
discount than that? If yes, that would be helpful!

------
maccaw
I'm a massive fan of Segment - we use it everywhere at my company (Clearbit)
and my only regret was not integrating it sooner. For example, some things we
do:

* 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

------
jdotjdot
Segment is one of my favorite products, and I consider it a core part of our
stack. It's enabled us to be leaps and bounds ahead of other companies our
size as far as analytics tracking, distribution, analysis in our warehouse,
and more. We use pretty much every piece of it--even the esoteric options like
their embedded pixel API. It's such a core part of my day that I sometimes
actually spend time daydreaming about new features I'd add to the product
rather than actually doing my job :)

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!)

~~~
pkrein
thanks jj! happy to get you into the kafka beta — shoot me an email peter at
segment.

~~~
dookahku
So if I'm reading Segment's page correctly, Segment is a service that reads
other API data and warehouses it into a single place to be read later?

I feel like I'm missing a lot of the picture. :)

~~~
danenania
I'm not a Segment user, but my understanding is that it allows you to track
events via a single API, and then push those events to lots of other services.
So instead of needing to have js script tags/tracking codes/event calls for
Google Analytics, Mixpanel, Optimizely, etc. etc., you just send your events
to Segment, and Segment sends them on to wherever you want.

------
pclark
I'm a massive fan (and user!) of Segment. I think it could be revolutionary. I
do worry a lot about how they tell the world about what they _are_ though,
it's an inherently complex and technical product - and often the buyers of
this software may not be technical enough to appreciate the sophistication of
this product. In my experience Segment is confusing to explain until you
actually use it, then you love it.

~~~
irq11
I keep going back and forth between understanding the value of this product
(dashboard for marketing to add integrations w/o dev time; better integration
of analytics), to wondering why technical people pay for this. It doesn't seem
cheap, and you're throwing a lot of control over latency-sensitive data to a
black box.

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.

~~~
bendavis381
Snowplow is open-source, although certainly not trivial to set up.

[https://github.com/snowplow/snowplow](https://github.com/snowplow/snowplow)

~~~
jackgolding
yup snowplow's devops requirements and lack of evangelism are hurting them IMO
but these are probably the challenges every open source product has.

------
philip1209
I was implementing Segment this week, and I was excited to see that they do
far more than customer analytics now. With a single installation of
analytics.js, you can turn on tools like Sentry.io error tracking, HelloBar
announcements, or secure user accounts with Castle.io. With a single
integration, Segment is becoming an app store for websites.

~~~
FLUX-YOU
As we learned in another post, having the name analytics.js can get you
blocked by Ad block extensions. Expect analytics.js to not run in your apps.

~~~
jaequery
this is definitely a deal breaker. other than server-side, are there any other
work arounds? like roll your own domain proxy or something?

~~~
bendavis381
Just bundle it in with the rest of JS payload with something like webpack.
Individual calls to certain domains (GA, Heap, etc) might still get blocked,
but the payload itself will be fine.

~~~
chatmasta
Does that cause problems with segment's servers being unable to see the user's
remote address?

------
soared
Odd to see hn cheering on segment, but hate on analytics solutions in almost
every other thread. Is it okay because anything yc does is good, or is
enabling analytics different than using analytics somehow?

~~~
soared
It's not that surprising. Hn isn't a single being.. it's a bunch of
individuals with differing opinions. Some are web devs who like usage
analytics, some email from the command line because they're afraid of web
browsers.

~~~
Hydraulix989
I'm very confused because you replied to your own comment as if you were a
different person.

~~~
SonOfLilit
It's not surprising, soared isn't a single being... :-)

~~~
gricardo99
lol! You made my day with that one. Just the right amount of snark and wit.

------
jph
Congratulations! I'm totally impressed by the excellent company the Segment
team is creating-- both the product and the support are first rate.

And special kudos to Peter, who provided direct hands on tech help for one of
my clients during our crunch time.

~~~
pkrein
thanks for being a customer :)

------
dzink
Strong work! CloudFlare may be on their tail with Apps.
[https://www.cloudflare.com/apps/](https://www.cloudflare.com/apps/)

------
shubhamjain
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.

------
cyberferret
From the discussion here, it appears that a lot of 'picks and shovels' app
tool providers seem to expect that their customer base will be well venture
funded companies.

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.

------
pcl
Interesting... this is the first time I've heard of YC leading a Series C. Is
there a new later-stage fund? Or is this just a case-by-case thing?

~~~
aetherson
New later-stage fund: YC Continuity.

------
aloisbarreras
I work at Astronomer, another company in the clickstream and data integration
industry, so I am very familiar the problem they are trying to solve. From an
engineering perspective I can attest that they are tackling some huge and very
complex problems, especially with the massive volume of events they process.

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.

------
naturalgradient
Have not used the product but have highly enjoyed reading their tech blog,
great stuff.

~~~
fouadmatin
Thanks! Glad to hear it :) Keep your eyes peeled for some really exciting
upcoming posts! (there's also a subscribe link at the bottom of posts)

------
AndrewKemendo
We use Segment and it's incredibly useful to be able to turn on and off
services, especially for reporting tools like mixpanel.

------
jgalt212
90% of this money is going straight to AWS.

~~~
calvinfo
This comment might be in jest, but we've actually been working on a few
different ways to help optimize [1] and manage our AWS spend [2].

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/](https://segment.com/blog/the-million-dollar-eng-problem/) [2]
[https://segment.com/blog/spotting-a-million-dollars-in-
your-...](https://segment.com/blog/spotting-a-million-dollars-in-your-aws-
account/)

~~~
jgalt212
yes, sorry for the snark. It was more about, how does one go about spending
$94MM in this day and age? And even after reading your well written post on
AWS cost control, I still can't figure out how to spend that much money on a
software biz other than given the lion's share to AWS. e.g. even if your
engineers and salespeople cost (all in) $200K a year. $94MM = 470 person years
of expensive staff.

~~~
pkrein
completely theoretically with nice round numbers, let's say a SaaS company has
$50m in annual revenue, and they want to grow to $100m in annual revenue next
year. lastly, let's assume time required to pay back the cost of customer
acquisition (marketing, sales, setup support) is 24 months, and customers
always pay annually up front. (24 months is kind of a long payback time, so
this is a bit extreme.)

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.

~~~
jgalt212
fair enough, but sometimes no matter how much you spend you won't be able to
double revenues from $50MM to $100MM. Will the market allow you to grow that
fast? So yes, the math is 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.

------
gjmveloso
Congrats!

Great people, great product and great contributions to OSS. Well deserved and
keep rocking!

------
dirkdk
congrats! Awesome company

------
dhruvsodumb
True story one of the cofounders of segment once saved me from drowning in the
Charles river. Great company all around.

