🔓Unlock better UX for your Slack App with App Home Opened 🛠

3 Ways to improve your user experience with the new and awesome Slack Event app_home_opened!

App_home_opened is an essential Slack event for app developers that want to better understand how users interact with their app in order to improve their app’s user experience.

By subscribing to this event, Slack will notify your app whenever a user opens a direct message with your app (You can think of this as equivalent to an impression on a web page).

We first read about this event in Halp’s post “Thoughtful app onboarding”, which details how to subscribe to this event and focuses on using it to effectively onboard different types of users. For a reference, here’s how we configured this event with Node.js and botkit.

const Botkit = require('botkit');
const controller = Botkit.slackbot();
controller.on('app_home_opened', async (bot, message) => {
  // Your code here
});

In this article, we’ll discuss further use cases for app_home_opened and give a description of how we implemented these features in our app, Grow.

Grow is a Slack-first platform that facilitates personal growth through continuous and actionable feedback with your team. We use app_home_opened to:

• Better understand how users interact with our app: Grow users select from our list of “nudges” to schedule reminders for themselves throughout the week. We use app_home_opened to understand how effective each nudge is, which is critical towards helping us design better nudges.
• Pre-load common actions for user convenience: Through app_home_opened, we noticed that many users would open our app but then not do anything. Through further user testing, we found that some users don’t remember or even like using commands (even “hi” or “help”). We addressed this by pre-loading common actions when users open the app, which has led to a significant increase in our baseline engagement.
• Effectively roll out new features and tips to users: It can difficult to spread the news about new features that might benefit many of your users. Many of our users follow us on social media or subscribe to our product update newsletter, but for those that do not, we’ve found the best way to notify them is by rolling out feature updates during app_home_opened. Sending users unprompted feature updates is often viewed as being “spammy” while prompting after app_home_opened seems more respectful and convenient.

Better Understand How Users Interact With Your App

One interesting metric you can now approximate is how often a user opens your app and then leaves without doing anything (similar to a website’s bounce rate). We roughly approximated this by measuring whether or not a user performed any action in our app within an hour of their app_home_opened event.

You can also use this event as an approximate “read” receipt. If your app sends scheduled messages (Note: always get user/team consent before scheduling messages!), it is reasonable to assume that receiving an app_home_opened event, after you sent the message, means that the user has read the scheduled message.

Grow’s scheduled messages often have a specific “call to action” (e.g. give or request feedback). By analyzing how often a user reading the message converts into the suggested call to action, we can improve our messages in a data-driven way. We are able to A/B test with different messaging copy and block layouts to find the most effective combination.

Pre-load Common Actions for User Convenience

When we first started looking at the data, we were surprised by how often users opened our app and then did nothing. Based on our own user testing, we found that many newer users of Slack are just not that familiar with the concept of bots and shy away from slash commands or even “hi” or “help”.

In an effort to improve our “bounce” rate, we started sending users a user message with give and request drop-downs (our two most common actions) when we received an app_home_opened event.

User getting a “welcome back” when opening Grow

A word of warning: Slack will send you the app_home_openedevent every time a user opens your app. If your app has no concept of state, then you could end up sending the same user the same message over and over again. This is a poor user experience!

We designed guardrails to prevent this in two ways.

First, we store the timestamp of the user’s last app_home_opened event. If a new app_home_opened event timestamp is less than an hour from the last one we received for that user, we do not send the user a message.

Second, we use Slack’s conversation history API to extract the last message in the conversation. If the user has no conversation history (i.e. messages.length === 0), we kick off an onboarding flow similar to what was described in Halp’s article.

User getting an onboarding message

This approach does not work for ephemeral messages, since those are not returned by the conversation history call. We send all of our direct messages as non-ephemeral so that we can utilize app_home_opened more effectively.

If the timestamp of the last message is before the last app_home_opened event we stored for the user, then we assume the user has not read the last message we sent. We avoid overwhelming the user by not sending any more messages.

Also, if we know that the last message in the conversation history already has a clear call to action, we avoid sending another message with actions. Giving a user too many possible actions can be overwhelming or frustrating.

To implement this logic, we use a pattern where we encode a message type constant into the block_id of the first block over every message.

const messageTypes = {
  OTHER: 'OTHER',
  GIVE_REQUEST: 'GIVE_REQUEST',
  // Your other message types here…
};
const blockMessage = [
  {
    block_id: JSON.stringify({ messageType:             
    messageTypes.GIVE_REQUEST }),
    type: 'divider',
  },
];
function determineMessageType(message) {
  if (message.blocks && message.blocks.length) {
    const blockIDJSON = JSON.parse(message.blocks[0].block_id);
    // Slack generates a string block ID if one is not   
    provided
    if (typeof blockIDJSON !== 'object') { 
      return messageTypes.OTHER;
    }
    const { messageType } = blockIDJSON;
    if (messageTypes[messageType]) {
      return messageType;
    }
  }
  return messageTypes.OTHER;
}

Effectively Roll Out New Features and Tips to Your Users

Another benefit of knowing a user’s last app_home_opened timestamp is that you can now tell if you’ve released a new feature since the last time they’ve engaged with your product. You could also have a rotating list of helpful tips for users.

Again, a word of caution, this event fires every time a user opens your app, so avoid overloading the user. For example, if User A sends a message to User B in your app, you probably don’t want to send an additional message to User B when they open User A’s message. Having too many things to focus on could be confusing to the user. We mitigate these types of issues by using the last message type logic described above.

Wrapping Up

We hope you’re as excited as we are about using app_home_opened as a powerful tool for better understanding how users interact with your app, pre-loading common actions for user convenience, and effectively rolling out new features and tips to your users.

Comment below if you’re excited about app_home_openedor if you have any questions! We’d love to hear how you’re using the app_home_opened event (or other features) to create great Slack experiences.

Check out Grow’s use of app_home_opened. Get started by visiting their listing in the Slack App Directory.