[saleemkce]

"$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.

[eropple]

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.

[saleemkce]

> "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

[eropple]

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.