Sement.io now https://segment.com/ is a highly popular way of "routing" your analytics data/events to various service to several services including Google Analytics, MixPanel, Facebook Ads, etc.
Q: Why should we attempt to match the format of events & function invocation from analytics.js?
A: Because if we make our events compatible with analytics.js we can eliminate any (technical) objection to adoption/usage andminimise the "friction" to switching.
We want to make a dramatically simplified Analytics UX that (digital) Product Owners will actually look at and use to be more "data driven".
Our experience of working with a many (70+) Web Product Owners over the past 17 years
building web sites and Sites/Apps - ranging from basic single-page apps to global multi-lingual billions-in-revenue e-commerce mega projects and everything in between - has taught us a lot about how people actually use (but most often fail to use) analytics to drive business decisions.
Most projects/apps have Google Analytics and a few even use Segment.com or MixPanel,
but in our experience there is no habit of consulting the data (insights) during daily stand-ups, feature/backlog/sprint planning meetings or Demos.
We feel this a crying shame. 😢
Because it means that:
a) the team (devs, designers, PO) isn't focussing on
what works ✅,
what's "broken" 💔 and
how to delight users.😍
b) users are almost invariably getting a worse experience that only meets some of their needs
c) the "wrong" thing is being built. e.g: more features built when users needsfewer better ones.
d) everyone's time is being wasted! ⏳
What?
A distillation of analytics.js down to the bare essentials.
So that we can build/use just (exactly) what we need.
Who?
The ideal person to do this work is someone who has used analytics.js a few times in "production".
I (Nelson) have only used analytics.jsonce (despite having used GA/GTM many times).
Thankfully if we build something useful and "Show HN",
we will get enough feedback from the community to "steer" us.
[ ] Build a Prototype Application that Demonstrates Logging Analytics Events using:
[ ] Elixir (Phoenix) for the Server (because it handles more requests and is fault tolerant!)
[ ] ES5 JavaScript (possibly PureScript) for the client component.
[ ] Attempt to create a "framework" that treats all data updates as analytics events.
such that when a user submits a form, we don't need to log the event twice;
the submission is the event! (i.e. the analytics needs to be "full stack". both an API and a module.)
nelsonic
commented
6 years ago
Context
Sement.io now https://segment.com/ is a highly popular way of "routing" your analytics data/events to various service to several services including Google Analytics, MixPanel, Facebook Ads, etc.
Many people (projects/teams/organisations) use
Analytics.jsfrom Segment.io: https://github.com/segmentio/analytics.js because it allows you to write code once.Why?
Q: Why should we attempt to match the format of events & function invocation from
analytics.js? A: Because if we make our events compatible withanalytics.jswe can eliminate any (technical) objection to adoption/usage and minimise the "friction" to switching.We want to make a dramatically simplified Analytics UX that (digital) Product Owners will actually look at and use to be more "data driven".
What?
A distillation of
analytics.jsdown to the bare essentials. So that we can build/use just (exactly) what we need.Who?
The ideal person to do this work is someone who has used
analytics.jsa few times in "production". I (Nelson) have only usedanalytics.jsonce (despite having used GA/GTM many times). Thankfully if we build something useful and "Show HN", we will get enough feedback from the community to "steer" us.How? (
#TODO)[ ] Go through the API https://segment.com/docs/sources/website/analytics.js with a "beginners mind" (but factoring our experience of building many apps) and summarise how to use it.
[ ] Build a Prototype Application that Demonstrates Logging Analytics Events using:
PureScript) for the client component.[ ] Attempt to create a "framework" that treats all data updates as analytics events. such that when a user submits a form, we don't need to log the event twice; the submission is the event! (i.e. the analytics needs to be "full stack". both an API and a module.)