Live data from Hacker News

Whom the gods would destroy, they first give real-time analytics (2013)

mcfunley.com

31–40 of 66 posts

Re: Whom the gods would destroy, they first give real-time analytics (2013)

#31
I think the point of real-time analytics is not to make product decisions but to get a sense of presence from your product and celebrate with your team.

As an engineer on many teams shipping features I've found that it's somehow underwhelming to finally launch something after months of work. You launch and the only thing you get to celebrate is some donuts in the office and if something goes wrong a notification from Sentry or Datadog :P

I've spent the past 3 years building a product analytics tool (https://june.so) and I think product analytics can deliver some real-time value to teams.

Some of the ways we've built our product to do this is:

- Live notifications in Slack for important events - to get pinged in a Slack channel when users use the feature you just launched

- Achievements on reports for your features - to celebrate the first 5, 10, 25 and 50 users using your product, see the progress live

I think for team morale, especially in the earlier days of a company it's great to celebrate small wins and as engineers we should be more connected to what happens inside of the products we build - not only when things go wrong.

Re: Whom the gods would destroy, they first give real-time analytics (2013)

#33

I think the point of real-time analytics is not to make product decisions but to get a sense of presence from your product and celebrate with your team. As an engineer on many teams shipping features I've found that it's somehow underwhelming to finally launch something after months of work. You launch and the only thing you get to celebrate is some donuts in the office and if something goes wrong a notification from…

If that's all you're going for, you don't need timeliness, comprehensiveness, accuracy, accessibility, performance, and durability.

Re: Whom the gods would destroy, they first give real-time analytics (2013)

#34

I think the point of real-time analytics is not to make product decisions but to get a sense of presence from your product and celebrate with your team. As an engineer on many teams shipping features I've found that it's somehow underwhelming to finally launch something after months of work. You launch and the only thing you get to celebrate is some donuts in the office and if something goes wrong a notification from…

Not sure about this for larger teams, but for very early stage teams I agree.

Seeing people using a hard-to-build feature a couple times a day, then more, until eventually you have to mute notifications to focus on work is a great way A/ to feel the progress, and B/ notice trends you can't pick out in averages.

Example for A: Just yesterday our CTO wrote in a feature-specific channel: > This page is now unreadable due to volume of usage pings! Go team!!

Example for B: Intuitively noticing whether your tool, that has say 6 DAUs on a team, is being used once by all 6 people, or in 3 pairing sessions, or something in between. Yes could run an analysis for this, but at an early stage co it's easier to just notice.

We became June users at our pre-launch co a few months ago, and the feature 0xferruccio mentioned is part of what sold me initially.

Not sure how long it'll remain useful but loving it for now.

Re: Whom the gods would destroy, they first give real-time analytics (2013)

#35
post #9

Just use Amplitude

Last I used Amplitude it was insanely expensive. Is that not still the case?

We’re working on it! Free up to 10M events, more to come later this year.

What would reasonably costed look like to you?

More on my view on real-time analytics here: https://news.ycombinator.com/item?id=15380607

Re: Whom the gods would destroy, they first give real-time analytics (2013)

#36
Author here. The main thing that inspired this happened a few years before I wrote it down. Etsy had gotten a new CEO, and they spent one of their first few weeks in long hours at my desk, iterating on the homepage design in what could only be described as a radically fast iteration loop. We'd ship a tweak, look at statsd for ten minutes, then change something else. This would have been a bad idea for all of the reasons of statistical validity listed, even if we hadn't built statsd to use UDP.

Emphasizing working on the homepage was also analytically dumb in a more meta way, since item/shop/search were really nearly all of traffic and sales back then. Anyway, I felt motivated to get that person to think first and fire the code missiles second.

At the end of the day, I think back on it fondly even though it was ludicrous. Shipping that much stuff to production that quickly and that safely was a real high water mark in my engineering career and I've been chasing the high ever since.

Re: Whom the gods would destroy, they first give real-time analytics (2013)

#37

Massive fan of this piece. I linked it in another comment yesterday. The place its truth has been most obvious to me is in analyzing subscription businesses. Your customers pay once a month, or once a year. Nothing, absolutely nothing you do on a minute-by-minute basis is relevant to strategic business decision making. Yet these businesses will invariably want real-time analytics. It serves no purpose! You simply can…

This is something I have been grappling with for a while - I work with data in an industrial plant there is a lot of legacy data systems here and "data latency" has been a real issue - real time dashboards are seen by some subset of management as the holy grail, being able to look at any part of our plant and see what is happening in real time is extremely attractive to certain people.

For a longtime there has been a lot of resistance "real time is too hard" used to get thrown around a lot- what is really driving it in last two years or so are Machine Learning and computer vision applications. There has been a huge push to integrate ML models (for example live defect detection) into our operating process which has necessitated low latency access to real time plant data.

The data pipelines we've had to build to enable these ML applications have bough latency way down all over the place and have kind of bought other applications like real time dashboards with them for "free".

Re: Whom the gods would destroy, they first give real-time analytics (2013)

#38

Massive fan of this piece. I linked it in another comment yesterday. The place its truth has been most obvious to me is in analyzing subscription businesses. Your customers pay once a month, or once a year. Nothing, absolutely nothing you do on a minute-by-minute basis is relevant to strategic business decision making. Yet these businesses will invariably want real-time analytics. It serves no purpose! You simply can…

This is something I have been grappling with for a while - I work with data in an industrial plant there is a lot of legacy data systems here and "data latency" has been a real issue - real time dashboards are seen by some subset of management as the holy grail, being able to look at any part of our plant and see what is happening in real time is extremely attractive to certain people. For a longtime there has been a…

I started in manufacturing with a similar view. What turned me around was reading “The Goal” by Goldratt and “Out of the Crisis” by Deming, and seeing just small applications of their principles yield significant results.

Re: Whom the gods would destroy, they first give real-time analytics (2013)

#39
Building a commercial real-time analytics system and running ops for it myself was the single hardest dev challenge I’ve ever tackled successfully. I came out of it one hell of a developer. GA real-time killed us a year later. We pivoted into cybersecurity and have a kickass business and team today that is 100% founder owned. Forged in the fires of Mount Doom comes to mind. It’s very hard and performance issues and bugs are impossible to hide from end users.
Post reply on HN