One best practice that we’ve adopted at our company is an “App Version” event property tied to new releases of our web app.
As our use of heap has evolved over the last 12 months, we’ve found ourselves in common situations where event definitions have evolved. An event defined one way now needs to be defined a new way. In order to keep continuity of historical data, you can then change the event definition based on app version. For example, imagine your URLs changed in your webapp, where a path changed from /bar to /foo.
If you have an app version property, you can do something like this really easily which will ensure you have all historical data for the old definition as well as moving forward:
The nice thing is that Heap can handle semantic versioning, so it knows that 1.5 is greater than 1.4. However, one thing to note is that Heap’s inability to do a “greater than or equal to” clause makes this a little tricky depending on your versioning scheme. This is why I’ve separately posted this:
If like us, you didn’t previously realize the benefits of this, you will have event histories with App Version of undefined. So to handle this, you’d add another criteria in the filter to handle it for “App version is not defined”.
There’s a big opportunity for heap to handle this automatically in the background with some uber configuration. We have found over the years, it to be super difficult to deal with event definition migration while not losing history. One of the biggest things for heap to handle IMO to make heap more durable and scalable.
Best answer by Holly Goodliffe
View original
