What is the difference between Self-described event and custom context?


#1

I’m confused about self-described events and custom context. They should be totally different things as for me, but the look like very similar idea.
Custom context, as for me, is additional fields that you want to attach to standart event, you have provide JSON schema, create table in Redshift, and result data will be placed in events table + custom table for additional fields.
Self-described event is not standard event that is coming with JSON schema also, you have also provide custom Redshift table for its values and as fat as I understand it will be still coming with lot standart values, so it will be stored in events table + custom table also.

So looks like the different will be in value of field ‘event’ in events table and how the called from JS tracker, all the rest technical items will be the same. With self-described event you are still extending standard set of fields, but save it with different value in field ‘event’, am I correct?

I have found outdated intro for unstructured events: https://snowplowanalytics.com/blog/2013/05/14/snowplow-unstructured-events-guide/ From very begining it looks like mixpanel free type events, very easy to, but now as far as I understand it can not be used without JSON schema. So unstructured events (self-decribed event) are very similar to custom context now.


#2

Hi @sphinks,

From analysts’ perspective, the main difference between two is that self-describing (unstructured) event has an one-to-one relationship with an actual event (or none-to-one in case of legacy events such as page_view, struct_event) and contexts have many-to-one. In other words, any event can have as many contexts as you think it makes sense, including contexts of the same schema.


#3

I’d use some real examples to explain it. The core event is the verb, and stuff associated with that verb (and only that verb). The contexts are about the objects and subjects of the verb.

So here something that happened:

Logged in user “abc123” read a recipe titled “Tournedos rossini”

The verb is content view which is a self-describing event with a mandatory content ID, environment ID (production, dev etc).

The custom contexts are:
article which contains an author, publish date, number of words and some content metadata that is used for all types of content.
recipe is content metadata specific to recipes: ingredients, difficulty, main ingredients, number of steps.
user is metadata about the identified user from the CRM. Possibly just a CRM identifier.

Now that core event could be a “Structured Event” but there’s a few problems with the Category > Action > Label model. It’s inflexible: when you decide you need to extend beyond that model, you’re out of luck. It also doesn’t have anything mandatory, so you can’t enforce say having a CMS content ID in it. Finally, it’s often overloaded with all kinds of meanings by GA users and you’ll find developers will just port over whatever overloaded logic is used in GA, which is just confusing and unnecessary.

We tend to push customers to use custom events for everything that isn’t a pageview.