Event tracking is something all web apps need. Own your own infrastructure, don't rent it. This post will show you how.
Whether you're a SaaS app, e-commerce storefront, or a media publisher, you need event tracking to help you make informed decisions. When I say "event" I mean everything from a simple page visit, to a completed purchase, to the general use of your application.
In this post, I'll walk you through setting up what I believe to be the best event tracking system available. There are many reasons I refer to this as the best but here are the top three:
This system uses an open-source, abstract library to collect events. Those events are then sent to your data warehouse as well as any third-party tool you like. This is the opposite of a common scenario where you allow third-party tools to collect your events then pass the data they collect to your data warehouse.
For example, when a visitor loads a page we will record a "page visited" event and tell Google Analytics about it rather than letting Google Analytics record it with their script. Doing it this way results in several key benefits:
If you buy something like Segment you are giving up control and the ability to customize your pipeline (beyond what they expose in their interface). You will also be paying extra for seemingly trivial changes to data transport. For example, it's a premium feature to send data to some sources but not others.
It's relatively low cost and a helluva lot cheaper than something like Segment (for the record, I think Segment is a great product and many of my clients love it).
Now that you're sold on owning your own, let's get started by getting more familiar with our new stack (shout-out to Jonathan Geggatt who taught me a lot about these components).
We need to manage the triggering and recording of events (pageviews, purchases, app-specific behavior, etc.)
We also need the ability to tie pre-signup, anonymous behavior to post-signup user behavior. This is often referred to as "identity resolution"