Snowplow Ruby Tracker 0.2.0 released
We are pleased to announce the release of the Snowplow Ruby Tracker version 0.2.0. This release brings the Ruby Tracker up to date with the other Snowplow trackers, particularly around support of self-describing custom contexts and unstructured events.
Huge thanks go to Elijah Tabb, a.k.a. ebear, for contributing the updated
track_screen_view tracker API methods among other features!
Read on for more information…
- New tracker initialization method
- Updated format for unstructured events
- Updated format for custom contexts
- Setting the event ID in the tracker
- Other improvements
- Getting help
The initialization method for the Tracker class has been updated. This is its new signature:
The change is that the
context_vendor argument has been removed. This is because contexts are now self-describing JSONs, so sending a
context_vendor is redundant.
An example of tracker initialization in version 0.2.0:
Previously, several arguments were required to build an unstructured event: the name of the event, the JSON describing the event, and the event vendor (the company that developed the event model). Now the signature of
track_unstruct_event has been simplified:
A usage example:
event_json argument has two fields: “schema” and “data”. The schema field contains a reference to the JSON schema for the event, and the data field contains describes the event itself. Together they constitute a self-describing JSON.
tstamp argument is unchanged: it’s an optional timestamp for the event, given in milliseconds since the Unix epoch.
The next section deals with the changes to how the
context argument works.
Custom contexts describe the circumstances around an individual event. In this version, custom contexts must be self-describing JSONs. Each of the Ruby tracker’s
trackXXX methods accepts an array of custom contexts as the penultimate optional argument (before the
An example, attaching two custom contexts to a page view event:
When tracking an ecommerce transaction, you can attach an array of custom contexts which will be sent with the transaction:
Under the hood, this complicated example will send three events: one transaction event and two transaction item events. The transaction event has an array containing one “page_type” custom context attached. The first transaction item event has an array containing one “promotions” custom context attached.
We are phasing out the old “tid” transaction ID field because, as a random 6-digit number, it wasn’t sufficiently unique. It has been replaced with an “eid” field containing a UUID. If set, this “eid” UUID will be used as the “event_id” for this event.
This is hugely valuable if the Snowplow Enrichment process is running in an at-least-once stream processing system, because you can use the tracker-set event ID to identify duplicates downstream of the Enrichment.
We have also:
track_screen_viewto send a valid self-describing JSON - thanks @ebear! #21
- Fixed broken links in the README #27
- Fixed the coveralls.io button in the Github repository #17
If you have an idea for a new feature or want help getting things set up, please get in touch. This is only the second release of the Ruby Tracker, so we’re keen to hear people’s opinions. And raise an issue if you spot any bugs!