Facebook prototypes tool to show how many minutes you spend on it | Hacker News Reader

Facebook prototypes tool to show how many minutes you spend on it

techcrunch.com

33 pointssaleemkce13 comments

This is what we revealed a couple of months ago on hackernews https://saleemkce.github.io/timeonsite and the web analytics tool based on it. https://medium.com/swlh/introducing-time-on-site-analytics-f...

> It may take from 1 week to 10 days for us to generate and send your licence key. But you could start using the software from the moment you made the purchase.

Sorry, that's a guaranteed dealbreaker.

It's an odd way of selling software in 2018. I sell a product written for developers and in JavaScript, too--and I effectively sell access to an NPM registry, I don't fearmonger at people like "it's illegal!"; practically there's no serious way for a developer to get even business-level pirates to actually respond. Instead, I don't give people access to Pro-tier features and I open-source the application because it's still useful to people even without those Pro-tier features, rather than freeloading on GitHub's servers?

(Also, the turnaround time is under 24 hours, rather than a week...and that's just because I haven't yet wired up a webhook to create a user in my SSO solution yet.)

But that relies on actual features and not a timer with some local storage. $38 is too expensive for that given the time a developer would have to spend vetting the software to make sure it's any good rather than writing functionally similar code that syncs with existing infrastructure rather than having some separate dashboard.

"$38 is too expensive for that given the time a developer would have to spend vetting the software". If so, do you point out a web tracker that captures time on site metric (ignores inactive tab time, multi-tab precise time computing, both real-time and offline time-on-site data feed and so on) so effectively that provides all these great features along with free timeonsite analytics tool https://github.com/saleemkce/timeonsite_analytics. Given all these critical metrics, $38 is not a big cost/per year for a company that likes to take intelligent decisions out of product usage & user behaviour. That's why big companies like Facebook and Instagram invest time on building this time metrics feature.

Facebook and Instagram spend time building this stuff because buying it off-the-rack would cost more. That tends to be true for a lot of stuff at Facebook scale, but that's also true for much smaller companies that need (note: not "think they need") the feature, too. It's neither complicated nor complex as a feature--the hard part, and the meaningful part, is contextualizing that timer with regards to the application and the decisions being made with that application. Your "free" analytics tool actually costs them a lot of money (because developer time isn't free) and there's an inflection point at which building a tool, bringing the knowledge and ability to maintain it in-house, makes a lot more sense than buying.

It's not that the feature isn't good, or the feature isn't worth $38 in a vacuum. It's that that $38 buys negative value for teams working on products that would derive value from the feature. You're trying to sidestep an existing metrics ingest pipeline and existing analytics tools. But the people who have metrics don't want you to sidestep it and the people who don't aren't the people who would materially benefit from this feature.

> "It's that that $38 buys negative value for teams working on products that would derive value from the feature. You're trying to sidestep an existing metrics ingest pipeline and existing analytics tools."

How do you say that it buys negative value? Additionally, We're not trying to sidestep an existing metrics; yes, this metrics is already available but with poor accuracy and implementation issues. Check the numerous issues with Google Analytics here: https://www.google.com/search?rlz=1C1CHBD_enIN777IN782&ei=Gb... So, we try to fix & improve the well-known metrics so that our products benefit straight away with accuracy and metrics-reliability.

#analytics #GA #timeonsite

Oh. Okay. Where's your Influx backend? Where's your CloudWatch Metrics backend? How do I get your measurements in Graphite? Is it going to take longer to write it myself to use those pipelines? If it takes more work to hammer what you have into the metrics tooling and pipelines everybody who actually needs this product already has, you present negative value.

Jimbo's PHP Site doesn't need this, they can't materially act on the information it provides and don't know how to read it meaningfully anyway. The companies that benefit from this are already actively metrics-oriented. And you are sidestepping existing metrics pipelines. It's easier to build over the fairly trivial feature set you present and integrate it with the kinds of monitoring you get out of the box with AWS et al. than to bend somebody else's questionable code--and don't take that personally, everyone who isn't me's code is questionable until proven otherwise, but your "you need a license for this code that talks to a webservice you have to host and puts it into a MySQL database you also have to host" stuff sure doesn't help--into acting right.

And, uh. You should really, really stop with the hashtags nonsense. Don't be gross.

Intrigued to see Facebook following Apple and Google's footsteps[0] in deploying a tool for its users to keep track of their application/website usage time.

Wonder how much of an impact this tool will have in bringing more internet-IRL balance to millions glued to their screen, given that this move is a complete 180º from Facebook core business model.

[0] https://www.theverge.com/2018/6/5/17426922/apple-digital-hea...

yes, you are right. This data is formidable. https://medium.com/swlh/introducing-time-on-site-analytics-f... Look at the post images(time metrics) by various measures, I wrote about time-on-site metrics on just 100K records in Mysql DB. The results were curious and compelling. Imagine what if we apply this solution over 10M, 100M, 1B or more records. It's definitely worth finding analytics and usage patterns.

It seems like a tobacco company making a tool that tells you how many cigarettes you smoke per day, and the results are displayed on the pack of cigarettes.

yes, sometimes you don't need real-time data. Offline works well in many cases to help you take decisions consciously.

All this is ridiculously silly compared to making it a useful site in the first place, notably by removing ads and using a chronological timeline. To make myself a broken record, I would certainly pay for such a useful social network. Facebook is not that, and had shown little inclination in providing this value to their users.

yes, useful site needs analytics/precise metrics to make it even better and user-focused, right?

Reply on news.ycombinator.com