I wanted to share with you some of my experiences developing proprietary event trackers to see if there’s an interest in adopting those ideas here, by this community.
In my experience with large, popular destinations between 40% to 60% of web traffic serviced by web servers never renders in the browser.
- In both of those two cases outlined above events were registered by the backend and middleware and were not registered by the front-end. We were paying attention to the front end and were oblivious to the body of the iceberg. But sometimes things can get even more embarrassing. Front end developers were pretty damn sure they have enabled event logging across the board, say 99% of the possible ways of interacting with the application were covered. Who gives a damn about the last mile, right? Then one shiny day, after the webdev resources moved on to other projects we find out it wasn’t 1% that was left behind… or overnight due to buzdev or marketing activities 1% ballooned into 30% or 50%. How do you know you did everything right? Well, five hundred years ago, professional accountants figured out how - they count everything twice, all the time. And if at the end the two sides balance to zero, then they did it right. If it didn’t, then they did it wrong. That simple.
Now let’s review what can be done to bridge these gaps. Currently snowplow does not integrate into web application backends easily. But let’s take RoR or Spring Framework or PHP as an example.
a. no this is not a generic page view event, change it to something more closely descriptive of the business logic.
b. add event specific context
c. change a default or two, because you know better.
Done and Done.
Now, by constantly monitoring what is captured on the front-end and back-end sides of the “event accounting” we can easily isolate any attributes (browser versions, ip addresses, cookies…etc) that cause lump-sided event tracking and fix the problem before it becomes an embarrassment or a a threat to the businesses bottom line.
In our proprietary event logging frameworks we have often stitched multiple parts of the same logical event from independently logged parts into single record similar to de-duplication feature recently added to snowplow. Example:
Part A: Server generated content to render (size, timings on API calls are logged)
Part B: Page lazy loaded on the browser (load times, modules loaded)
Part C: Google client side ads we requested ( 10 requested, 3 delivered, 3 displayed )
And with snowplows ability to add contexts to existing event logs, stitching logic is probably going to be very simple!