Project Overview

During my summer internship, I led an initiative for push notification priming. Much of the actual work product is proprietary, but I'll walk through the solution at a high-level, and describe how I brought this feature to life.

Background

After users download a mobile app on an iOS device, the user is prompted with a few questions that come up through iOS System Prompts. Users are typically asked if the app can have access to the user’s location and if the app can send push notifications. For this particular case, we’ll just be focusing on push notifications.

When the user is prompted with the standard iOS menu to "allow" or "not allow" push notifications, roughly 40% of iOS users (across the entire eCommerce category) typically opt out. The user has no idea if the notifications will have any value, how often they'll receive these notifications, and the total volume of notifications that will be sent.

Objective

The objective of this project was simple: Get more users to enable notifications (1) immediately after registration, and (2) open up the opportunity for users to enable effortlessly later on in-app.

Push notifications drive incremental purchases on eCommerce apps, so a higher percentage enablement leads to an increase in revenue.

Approach

When the standard iOS permission prompt is shown, it's considered a “one and done." If the user chooses to not allow notifications, the app cannot show that same menu again. After that, the only way the user can turn on notifications is through their device settings. This is an extremely high-friction process, so we wanted to avoid that as much as possible.

For the proposed flow, there's one major difference - instead of immediately showing the iOS permissions menu, we'll serve up a custom dialogue asking the user if they'd like to opt in to notifications. This custom dialogue explains the value of push notifications, and how often a user can expect to receive the notifications.

In addition, it's essential that this custom menu includes a “Not Now” option so you reserve the right to ask the user later on in their app experience.

Key to implementation:

• Only show the iOS system permissions menu when you're absolutely sure the user will opt in
• If the user selects "Not Now" then it's important to only reprompt the user at key moments in their future in-app experience. I won't go into too much detail here, but this is a part of the secret sauce we used at Ibotta.

Projected Results

After implementation, it’s projected that the result will look something like this:

Implementation

As noted in the introduction, the solution I helped Ibotta build is proprietary. However, I was involved in the following activities to get this feature shipped.

• Working closely with our designer on concept mock-ups
• Working with our engineering team to figure out the best way to implement, and writing user stories for the product backlog
• Working with marketing to gain consensus on our method of implementation
• Convincing stakeholders that we should prioritize this feature

Expected Business Outcome

This initiative is expected to increase push enablement by 5% for iOS users. Ultimately, this translates to incremental revenues of about $250K per year. Along with other initiatives, the total business impact I drove during my internship was roughly $1M of additional yearly revenue.