Explore internal tracker logging with trackError

[chuwy]

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]

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

[alexanderdean]

No I think I will scrap that milestone...

[chuwy]

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]

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]

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]

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