I think they both touch on an important part of the analytics process that we don't talk about as often as we should. It would be interesting to get a discussion going.
My own thoughts:
I think that for once we're in (near) complete agreement ;-). But I believe this shouldn't apply to event tracking but to ALL analytics tracking.
There is another important reason for vendor-agnostic data layers. makes the very good point that apps and websites already have a backend data model that is (more or less) transferrable into analytics in its current form. Why ask devs to build one that "fits" into GA's model rather than work with the one that:
a) they already have,
b) makes sense to them and
c) captures the fundamental underlying logic of the business and app.
Another important benefit to the approach is that when you free yourself of "page", "event category", "event action" and "event label" you begin to "see" attributes that carry analytical value that you wouldn't otherwise see (like the date when product was added to site, or its cohort based on date, which you can then use to calculate lifetime merchandise performance -- sure I can infer it based on first date it appeared in content reports but that requires some SQL acrobatics and GA API queries).
I'm currently trying to work out a process to document these interactions in a way that's repeatable across multiple business types and interaction types so any ideas are very welcome.
My current approach is inspired (again) by the guys at Snowplow (read their Event Grammar blog post, it's eye-opening: http://snowplowanalytics.com/blog/2013/08/12/towards-universal-event-analytics-building-an-event-grammar/).
First step would be to first describe each interaction in terms of subject + verb + object e.g. "user sees product". In this case "product" is the entity and "sees product" is the associated interaction.
This is an important distinction to make because entities have a whole host of attributes that exist independently on whether anyone ever interacts with them (i.e. product title, name, classification, etc). These same entities also gain attributes when someone interacts with them (e.g. remaining stock, discount offered -- if not the same for all users, etc).
Once I've mapped the entity dictionary from these two perspectives, I move on to mapping the associated event dictionary (the attributes that refer solely to the interaction, its context -- how, where, when and why). This can include timestamp of interaction, location on site, location on page, if object was above fold (quite critical for enhanced ecommerce when you begin to take product impressions into account). Most of the standard dimensions in GA are in reality event context dimensions.
In the process of mapping both event and entity dictionaries I bear in mind an important distinction. Some attributes should (and can) be captured at data collection time whereas some can only (and should only) be inferred at analysis time. An example is whether a product was added pre-Christmas based on the date it was added, or what market segment a user might belong to. There's a grey area of "where should custom business logic be captured" but that's not the point here.
The idea is that the process of mapping entities and events fully from the start mean that you:
a) document the business logic and understand its ins and outs from the start. I find it an iterative process where I keep asking questions and get stakeholders involved and that's very rewarding.
b) make conscious decisions regarding what to track right now and what to prioritise (e.g. "this attribute is important, can we infer this from the data later or do we need to capture it explicitly now?")
c) have a natural language roadmap for tracking that's in sync with the analytics maturity of the organisation.
Of course, interactions can be quite complex: "user adds product to basket". In this interaction you need to also take into account the entities which are directly affected by this interaction, in this case the Basket and map out their dictionaries accordingly. I've been learning about object oriented design recently and can't help but see deep similarities between the two.
Here's a (very rough) draft of the dictionary for Forms (which form the basis of many special-interest entities) http://clearclu.es/UFaRAy . It contains a mix of attributes that can and should be collected and some which will be inferred later.
I've been thinking about this a lot recently and really do believe the kind of approach Peter and Yali talk about makes analytics tracking really flexible, scalable, intuitive and critically, aligned with the business, analytics and dev perspectives.
cc: , , , , , , ,