Analyse analytics.js API to Match Event Format

## _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.js`** from 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_ with `analytics.js` we 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".

> 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 **needs** ***fewer 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.js` _once_ (_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:
+ [ ] 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._)

Start by reviewing the linked Segment Analytics.js API documentation and the issue's three proposed work areas. The payload names an Elixir/Phoenix server prototype and an ES5 JavaScript client, but no repository files or tests. Done would require an API summary, a working event-logging prototype, and a defined approach for treating data updates as analytics events.

Written by the indexing model from the issue text.