Live data from Hacker News

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

mcfunley.com

61–66 of 66 posts

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

#61
post #54

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 reas…

Isn’t that last sentence sort of a reason to prefer real-time analytics? If you can make development a fast paced game, no doubt you’ll keep your team more productive and engaged. Granted, it needs to be engineered in a way to ensure that productivity is aimed correctly (“how we decide which things we do”) as you point out in your great article.

Good question, though what you have in mind might be real time metrics, not analytics. Even then you might not need real time metrics to know whether your rapid changes are breaking things. An already established dev culture built on CI/CD, actionable health checks, feature flags/toggles, easy release rollbacks in emergencies are what you’d want. This way, your deploys are boring and you can focus on introducing new regressions, uh I mean features, fearlessly. :)

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

#62

Earlier quoted context omitted.

How does an typical NHST A/B system resolve this?

You tend to stop while the experiment is running, and then spend time looking at the results once it's done. The real benefits here are getting a better understanding of what levers drive your product metrics, as you'll inevitably mess up the first n or so experiments (if I could give you only one piece of advice, it would be to use stratified randomisation, but everyone seems to have to make this mistake for themsel…

Advice appreciated but I'm exceedingly familiar with experimental design haha, what I understand far less well though is the integration of the toolset into a business/product development context. I can see how having a staggered cadence of stopping, reflecting on the experimental design, and making a decision is wise. But it still seems that you could perform the experiment using MAB to keep the profit motive happy (you don't want to waste potential click-throughs just because you like p-values, maybe tune it to be more conservative about shifting heavily to one arm) and then have some period where you stop the experiment to pause and reflect.

Heck you don't even have to do MAB if you don't want to, just don't use NHST. The Bayesian "flavor" of NHST (credible intervals around posterior expected values) has absolutely no problem with optional stopping. Run the experiment until you've got a precise enough estimate, then sit back and make your product decisions.

I guess where I'm going with all this is that it seems like the post's strongest point is "good product decisions require time, and realtime analytics bamboozle us into thinking fast decisions are better". All the stuff about NHST seems kind of tangential. Looking at it again I see that it's like a decade old, so I think this is the best explanation for why they were targeting NHST more aggressively. I would hope in our post-replication crisis world (hopefully "post", anyways) data scientists and A/B testers are more prudent about some of these better-known pitfalls.

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

#63

While there are probably all sorts of problems with marxism when it comes to economics, in large companies there should be a 'vanguard party' of statisticians who prevent the masses from making false claims of causality from p-hacked tests.

Andrew Gelman is truly our Vladimir Lenin

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

#64

As I have grown older, I have realized more and more that the most important things can't really be measured directly. Yes you can measure some related things that give you some hints about the thing you care about, but they are fragile. To borrow from Goodhart, if you make the related things a target, they will stop giving you even these hints. This applies not just in software development, but life in general.

I agree with you.

This is why I think the idea of technocracy or "evidence based politics" is ultimately a mirage. Sure you can maybe assess some policy but the metrics you're choosing to measure or optimise for are political by their very nature. One's evidence based policy isn't the same as mine.

Health-outcomes-wise it would be better to force everyone to eat salad or whatever but that's only one dimension to optimise on at the expense of freedom and life enjoyment.

Tying it back to tech maybe going down market improves your conversion and lowers your CAC but maybe you've just acquired a bunch of customers with low value, high churn and high costs.

Maybe the sales of Amazon Prime are showing gangbusters returns with the dark patterns but now people loathe your brand and are hoping to see you hit with an FTC banhammer.

There's no silver bullet to this stuff, sure you should probably measure it but ultimately you have to make a decision and be guided by gut instinct and beliefs.

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

#66

Earlier quoted context omitted.

Because it is difficult to map that onto real business decisions and requires oftentimes supporting a large space of possible UI combinations because they haven't been fully ruled out yet.

Doesn’t that problem also exist with NHST based A/B testing?

I think business decisions map very well onto the binary decisions implied by NHST A/B testing, which is partly why we put so many resources into studying those problems in the early 20th century.
Post reply on HN