Yesterday my coworker Meredith and I were discussing retention rates and were stumped on what to call a certain retention metric. Specifically, what do you call the % of users that performed an event during the week following the user’s sign up date?

It’s an important metric to measure because for most services the sharpest drop-off will be the day users sign up so it’s useful to know what % of them return and use the service at some point in the week that follows.

I wound up tweeting about it and received a lot of responses which I’ll summarize below.

Before we dive into the options, it’s important to note that the day the user signed up is typically referred to as D0. Because users signed up that day, D0’s retention rate is always 100%. D1 then represents the % of users that were active on the day after sign up, D2 the % that were active two days after sign up, and so on.

Here are a few options with my 2c on their pros and cons:

Week 1 retention or Week 1 active – The main problem here is that it’s easy to misinterpret for folks seeing it for the first time: Does this mean a user was active 0 – 6 days after signing up (though this doesn’t make sense when you think about it because 100% of users are active on day 0) or 1 – 7 days (the first week after the sign up date)? Or if you confused it with the similarly-named 1 week retention does it mean 7 – 13 days (one week after the sign up date) or 8 – 14 days (one week after the day after sign up)? 😱

Post-first day active users, week one – +1 for specificity, -2 for the length :)

Week 0 retention or Week 0 active – This is less ambiguous, and is probably my second choice for what to call this metric. “Week 0 retention” would have to mean 1 – 7 days after sign up because a user isn’t considered retained on the sign up date and the zero makes it difficult to represent anything beyond days 1 – 7. The main problem for me is just that it takes too much thought and will constantly have to be explained to folks.

D1-7 – This is my favorite because there’s no ambiguity plus it’s nice and short. To me it’s hard to interpret this as anything but the metric we’re after. The downside is that it’s cumbersome to say out loud (“the day one to seven retention rate”) but in the end I think the pros outweigh that con. Hat tip Jan Piotrowski for suggesting it.

Thanks everyone for their feedback, especially Meredith who asked the question and whose insights on the naming I largely echoed in this post.

When it comes to naming your analytics events, consistency is key.

For example, if you name one event “Signed In” (titleized, spaces, past tense), then name your signed-out event “Signed Out” not “signed out”, “Sign Out”, “signed_out”, “signOut”, etc.

Ideally you should decide on naming conventions before you start tracking any events. The reason is that once you start tracking an event under one name, most analytics services won’t let you rename it. You can rename the event you send the analytics service, but then you wind up losing the historical trends with the old name. Because of this, normally you’ll wind up sticking with the original name even if you later wish you could change it.

If you can, wrap the analytics event API call with your own validation logic to ensure that everyone is forced to use the same conventions. Also, create solid documentation so there’s a resource for new developers to learn best practices.

At Automattic we have our own internal analytics service called Tracks. Here’s a summary of the guidelines we provide our developers for event naming conventions:

• Use lowercase letters.
• Numbers are allowed.
• Separate words with underscores.
• Don’t abbreviate unnecessarilly.
• Don’t programmatically create event names; hardcode them all. This prevents developers from accidentally flooding our analytics tools with thousands of event names. It also makes the event names easily searchable in our codebase.
• For page loads, use “view”, not “visit”, “load”, etc.
• Use present tense for verbs (why used “signed_out” when the shorter”sign_out” will do?). In practice most developers forget this so we don’t enforce it.

We also format our event names so that the source (Calypso, Akismet, etc) is first, the context is second, and the verb is at the end. This makes them appear next to each other in alphabetized event lists in our tools. For example:

akismet_product_purchase
akismet_product_refund
calypso_product_purchase
calypso_product_refund

There is an argument to be made for having a single product_purchase event and passing a property such as source that is set to akismet, calypso, etc but we generally don’t do that because a) Putting the source first lets us partition the databases based on it to make querying for events faster and b) In many cases even though the event is conceptually similar, they wind up varying a lot in the properties attached to them. For example, maybe on one service users buy plans and another service they buy upgrades. If both services share the same event name, you would probably want to ensure a consistent property name that represents what the user purchased. Do you use plan, upgrade or something more generic? To keep things simple, we simply use similar event names but prefix them with their source (ie, akismet_product_purchase and calypso_product_purchase).

We also enforce that property names use similar formatting conventions (lowercase, letters only, snake case).

I hope this gives you some things to think about next time you’re setting up tracking for your apps.

If you have any best practices at your company for naming events, I’d love to learn how you all go about it.