snowplow / snowplow-javascript-tracker

Snowplow event tracker for client-side and server-side JavaScript. Add analytics to your websites, web apps and servers.
http://snowplowanalytics.com
BSD 3-Clause "New" or "Revised" License
547 stars 220 forks source link

Explore internal tracker logging with trackError #576

Open chuwy opened 7 years ago

chuwy commented 7 years ago

This is superior of https://github.com/snowplow/snowplow-javascript-tracker/issues/556.

We can check for invalid tracker state and use trackError (or even introduce special schema) to warn user (user installed tracker, not end-user) that tracker is in invalid state or some exception occur. Unlike console.log approach which will be observed only by end-user (which is undesirable) trackError approach has more chances to be observed by right person.

chuwy commented 7 years ago

Does it belong to https://github.com/snowplow/snowplow-javascript-tracker/milestone/33?

alexanderdean commented 7 years ago

No I think I will scrap that milestone...

chuwy commented 7 years ago

Just realized it really could help us to explore those hard-to-debug situations (#568, #494). We can add new function:snowplow_name_here('enableDebug', predicate, extractState) which catches necessary tracking function calls with predicateFunction and sends debug data with internal tracker state to the collector.

So, to debug all calls of pageView we could use following:

function extractState(tracker) {
  return { someState: getStateFromTrackerObject(tracker) }
}

function predicate(args) {
  return args[0] == 'pageView'
}

snowplow_name_here('enableDebug', predicate, extractState)

It can be much more useful if decide to extend https://github.com/snowplow/snowplow-javascript-tracker/issues/548, exposing all tracker state properties as context for example.

The disadvantage I see is that user will need to pollute their analytics data with debug messages, but I don't see this debug enabled all the time, but only if user suspects tracker doesn't work as expected.

chuwy commented 7 years ago

I see this potential schema iglu:com.snowplowanalytics.snowplow/javascript-tracker-state as great way to start to adding static types to tracker.

All these properties would look nice in custom context (except functions). If we add it we won't provide cherry-picked access to each property (#573, #574, #575) anymore, but will provide them all at once (not sure whether it's good choice from architecture point of view, but they're ready-only anyway).

alexanderdean commented 7 years ago

I really like the way you are thinking about all this @chuwy . Using Snowplow's own error tracking as a way of essentially implementing a form of "gradual typing" for our dynamic-language trackers is genius... /cc @yalisassoon

paulboocock commented 4 years ago

Thisn is a very similar technique that has just been implemented in the Android tracker https://github.com/snowplow/snowplow-android-tracker/issues/343