To make Snowplow event tracking as robust as possible in the face of unreliable network connections, we have added support for outbound event caches to our event trackers. The principle is that the tracker adds a new event to the outbound event cache, attempts to send it, and only removes that event from the cache when the collector has successfully recorded its receipt.
One of the implications of this approach is that the
collector_tstamp is no longer a safe approximation for when a long-cached event actually occurred - for those events, the
collector_tstamp simply records when the event finally made it out of the tracker’s cache and into the collector.
This is a challenge, not least because our device-based timestamps are no more accurate than they were before. The problem is illustrated in this diagram:
The first step in fixing the challenges set out above is to refine the temporal terms we are using:
dvce_tstampis really our
dvce_tstampfor events when we know precisely when they happened. We should create a new “slot” for this timestamp to remove ambiguity - let’s call it
collector_tstampas a proxy for the final, derived timestamp. Let’s create a new slot for this, called
Let’s assume that we can update our trackers to send in the
true_tstamp whenever emitting events that truly know their time of occurrence. In this case, the algorithm for calculating the
derived_tstamp is very simple: it’s the exact same as the
derived_tstamp for events which do not know when they occurred is a little more complex. Remember back to the diagram in 2.2 above - all three of the timestamps were drawn in red because they were each inaccurate in their own way.
For us to calculate a
derived_tstamp for possibly cached events from devices with unreliable clocks, we need to start by making two assumptions:
dvce_sent_tstampare both inaccurate, they are inaccurate in precisely the same way: if the device clock is 15 minutes fast at event creation, then it remains 15 minutes fast at event sending, whenever that might be
collector_tstampas 0 seconds
This now gives us a formula for calculating a relatively robust
derived_tstamp, as shown in this diagram:
In other words, this formula lets us use what we know about the event and some simple assumptions to calculate a
derived_tstamp which is much more robust than any of our previous timestamps or approaches.
We have already added
true_tstamp into the Snowplow Tracker Protocol as
ttm. Next, we plan to:
true_tstampto Snowplow trackers, particularly the server-side ones most likely to be used for batched ingest of historical events (e.g. Python, .NET, Java)
dvce_created_tstampto remove ambiguity
derived_tstampfield to our Canonical Event Model
Expect new Snowplow tracker and core releases in support of these steps soon - in fact starting with the next release, Snowplow R71 Stork-Billed Kingfisher! And with these steps implemented, we can then start to prioritize our new
derived_tstamp for analysis over our long-serving
That completes this update on our thinking about time at Snowplow. And if you have any feedback on our new strategies regarding event time, do please share them through the usual channels.