analytics scope

[sean-roberts]

So, what this really is, is counting of events on a specific key. I wanted to open up the conversation around opening up the scope of this project. Views was a good start, but it seems a bit odd to me that the db adaptors can support arbitrary key/values but we limit the scope to views explicitly.

But keeping with the counting strategy, we could simply offer ways for users to specify the type of information segments being tracked. What this allows for is the ability to track counts in semantic groupings.

For example, I might want to track user interactions, page views, page load times, etc. But as it is right now I could try to track that with MA as it is today but it could really overcomplicate querying.

like as a major version change what if we supported something like:

analyticsservice.com/count/:trackingSegment/:key analyticsservice.com/count/:trackingSegment?key=:key

breaking that down:

• keep the simple structure of the endpoints that we have today
• add /count/ prefix path to indicate the action/type of data.
  • supports backward compatibility with what is there today. (unless someone's path is /count/)
  • indicates the action and data type when getting and putting. This allows us to support different types later on potentially.
• trackingSegment is what we should group the metric
  • examples: /count/views/, /count/purchased/
• :key is, like we have today, the string that would be captured as the key
  • ?key=:key seems like a good idea in general so that you can wrap it in quotes and pass non uri safe values as the key. ?key='/path?otherquery&params'
• remove the views counting object field. so "/hello":{ views: [] } -> "/hello":{ count: [] }

Diving more into the tracking segment. The goal would be that you have something like

{
  // could be any string tracking segment name 
  // like interactions, checkouts, etc.
  "views": {
    "/hello": {
      "count": [{
        "time": 123
      }, {
        "time": 124
      }]
    }
  }
}

since we have this segmenting of data being tracked, our querying will also be segmented by that type. Allowing us to track multiple types of data and querying isn't "looking for a banana but you got the gorilla holding the banana and the entire jungle."

And supporting what we have today can have this: analyticsservice.com/my/path be applied to the db as if it were: analyticsservice.com/count/views/my/path

[mxstbr]

I like your thinking, but don't quite see the benefit of having a strict schema for it. 99% of this works today—as an example, imagine users having a setup like this:

// analytics.js

export const track = (type, id) => {
  fetch(`analyticsservice.com/${type}/${id}`)
}

// Usage:

track('click', 'home')
track('scroll', 'bottom')

// track() could even be more strict to only allow specific key-value paris so nothing like scroll:logout goes through

The only major difference I can see in your proposal compared to what micro-analytics already does is that getting the data out is slightly different, as it's now grouped by the first level instead of all in one, but even that's doable with the getAll filtering:

// Get all the click events
fetch('analyticsservice.com/click?all=true')

// Get all scroll events
fetch('analyticsservice.com/scroll')

What am I missing here?

[sean-roberts]

You're right, I forgot about the?all does matching not one-to-one mapping. So this is more approachable than I thought it was today. That's a not so obvious feature :P

That said, I keep wanting the quick access to the aggregated counts. So GET purchases?inc=false but I suppose that might be better suited for a different tool that consumes this api for now.

Another thing that is suggested is opening up the "here's what micro analytics can do". Which, even today, isn't only page view counting.

[mxstbr]

Yep that I totally agree with, definitely a docs problem. Because it's so flexible, when used right, this tiny amount of code is actually really powerful!

We should reflect that in the README, I haven't been able to really get this across. Mind taking a stab at it?

[sean-roberts]

Sure, I can give it a shot.

But, there are a few other things mentioned above as well:

• renaming views to counts
• allowing a ?key param to send non uri safe values or to not collide with any special params that we have

what do you think?

[mxstbr]

For the first, that's fine but a breaking change so we'll do that when time has settled down a bit and people won't get angry if we break all their code. 😉

For the second see the discussion in #24!