reply on: The lifespan / churn of a SN user? \ stacker news ~meta

pull down to refresh

62 sats \ 7 replies \ @k00b 14 Jan \ on: The lifespan / churn of a SN user? meta

I haven't looked at these stats in a long time (kr took lead on this), but we did a serious review them after SN was around a year old. One of the crazy things was that we retained ~80% (IIRC) of people for at least a month, after they received a comment or zap on something.

Anyway, you made me curious so I looked. Here's the result of a quick query. This would be cool to add to the analytics dashboard.

count	avg	max
25736	90d	1316d

The header is how many at least stayed that long.

1w	2w	1m	2m	3m	6m	1y	2y
10698	9531	7861	6437	5677	4155	2399	695

13 sats \ 5 replies \ @pillar 21h

@k00b thinking out loud: could you guys be interested (aka have budget) for developing internal analytics for stacker.news instances as part of the app itself?

0 sats \ 4 replies \ @k00b 21h

We have some analytics but you mean something else?

13 sats \ 3 replies \ @pillar 13h

I'm thinking of something similar to a static site generator. You define s set of queries towards Postgres and visuals with code, check it into git, build it periodically. You can serve the pages publicly or keep them internal. All based on FOSS.

0 sats \ 2 replies \ @k00b 2h

Hmmm static would be interesting. The way our analytics work currently is we generate materialized views periodically, then query those (basically we query expensive aggregate queries we precompute). We use metabase for our internal dashboard, which is FOSS, to do this kind of thing internally.

I've thought it'd be neat to externalize a read-only metabase - something that requires less work than our current setup.

Are you interested in building something like this or just brainstorming? If it's something you'd like to work on, we can make a gihub issue, work out the details, and put a bounty on it.

0 sats \ 1 reply \ @pillar 47m

I get your analytics approach regarding materialized views + metabase. That makes sense.

Knowing that's what you are using I think you could appreciate some of the advantages of the approach I'm proposing. For instance, I'm kind of guessing you might be irritated by the fact that with Metabase is hard to version control and build with regular git ways of working (e.g. PR flows). Or not having clear dependency mapping regarding which dashboards rely on which tables of your backend, which means you might blow up some dashboard accidentally when working on the backend database.

Regarding internal/external, I think it could be used for any of the two really.

I could be interested in building hands-on.

What do you think about this:

I make a standalone repo on github that showcases in a very stupid, hello-world grade way the approach while reading from some mock Postgres tables that resemble real tables from stacker.news.
You take a look and see if it clicks in your mind.
If you're interested, then we can discuss which serious, useful analytics internal use cases or page features this could be applied to. And open issues, discuss bounties and the like.