When to track features with events or attributes
A feature can be anything in your product, big and small. It can be user facing, like a key interaction in the UI, a minor preference-toggle or even a background job.
Features are different and have varying usage patterns. Some features are meant to be used once and some should be used frequently. For some features, it makes sense to track retention, for others it doesn’t.
Depending on the feature type you’d like to track, you can choose between tracking features using events or attributes.
To help you decide between the two, let’s use Slack as an example.
Let’s say we want to track 1) how often users send messages, 2) how many users have the Stripe Slack app installed, and 3) how many users have any Slack apps installed.
Sending a message (event-based tracking)
Sending a Slack message should happen daily or at least very frequently. For this type of feature, you therefore want to track the message sending cadence. To do that, we need a timestamp for every message being sent. Event-based tracking is perfect for this use case.
On Bucket, you’d track this feature by sending an event whenever a user sends a message. First, identify who’s logged in. You only do this once when loading the app.
Identify the user (PII not required)
Associate the user with a company
Then, we send the event whenever the user sends a message.
Once the data is coming in, we’re ready to create a feature report for the messaging feature on Bucket. It’s super easy:
That’s it! We now get this feature report out of the box:
We bucket users into adoption states to give you a quick overview of the usage distribution. Adoption states are important as we want to track the user progression as they go from never using the feature (“Never”), to trying it (“Tried it”), to becoming an active user (“Using it”) and then to potentially churn away from the feature (“Stopped”).
The charts show how users have moved in and out of Using it over time and how frequently they use this feature on average.
Slack Apps (attribute-based tracking)
Installing a specific Slack App is something you can do just once. For this feature type, we’re interested in checking which users have a specific Slack App installed.
Attributed-based tracking is perfect for this use case. Primarily because attribute-based tracking supports historic interactions. Companies that installed the Stripe app long ago wouldn’t be included, if we started tracking this feature with events today.
On Bucket, you’d track this feature by sending a Company call (apps are installed at the Slack workspace level, not the user level) whenever the user logs in.
In Slack, there’s already a list of installed apps, so we grab that data and put it in the tracking call as a comma-separated list. We also count the installed apps in the "apps_count" attribute.
Once you have the updated "bucket.company()" attributes in place, go to Bucket to create the feature report, like so:
(If you want to track how many users have any apps installed, replace the above filter with "apps_count" greater than "0")
That’s it! We now get this feature report out of the box:
You’ll notice this report looks almost identical to the event-based report. We think it’s really important that feature reporting is consistent and easy to understand for everyone on the team.
Here, the adoption states show users who have never had the Stripe app installed (“Never”), users that currently have the Stripe app installed (“Using it”), and finally users who had the Stripe app installed at some point, but don’t any longer (“Stopped”).
The chart shows how users have moved in and out of Using it over time. In other words, when the user’s "apps" attribute started to include “stripe”, and when it potentially disappeared again. Bucket automatically keeps track of attribute value changes over time, which is a super powerful feature! ✨
Support for attribute-based features rolls out to everyone very soon.
Happy shipping!