Really improve conversion rate! Practical skills to guide users to authorize APP to send notifications

The success or failure of the initial authorization application will largely determine whether the product value can be fully demonstrated to retain users. In this seemingly insignificant but almost decisive link, we need to be extremely cautious and take all possibilities into consideration for any optimization plan. Today I will share a practical thinking on the onboarding process. The conversion rate data proves that this article is very valuable.

Our Hopper app analyzes a large amount of airfare prices every day, accurately predicts price trends, and tells users when it is most cost-effective to buy tickets.

Hopper can make very accurate price predictions and tell you whether you should buy a ticket or continue to wait. During the waiting process, you can use the "wait and see" function. At this time, the app will continue to wait and see the flights you are interested in until the price enters the "low price" range, and then push a notification to you suggesting purchase.

We hope that more users can discover, understand, use and benefit from the "wait and see" feature. We are very sure that the conversion rate on this feature is far from reaching its peak, and stimulating users' demand for the wait and see feature is a very important product strategy for us. Considering that the wait and see feature itself can increase the stickiness of the product - for example, even if users are using "wait and see", they will return to the app more frequently to view information related to the current situation, or try other features while waiting - we want to ensure that users can fully understand the value of this feature when they use the app for the first time and correctly complete the push notification settings. So we decided to optimize the previous novice guidance process.

Questions about notifications

Obviously, notifications are extremely important to the wait-and-see feature - if users don't allow Hopper to send notifications, they won't receive a recommendation when the price reaches a low price range, and the wait-and-see feature will be completely useless.

iOS gives the user the power to decide whether to allow an app to send notifications, and each app has only one chance to trigger the permission request.

If the user selects “OK,” everyone is happy; if they select “Don’t allow,” then even if they change their mind in the future, it will be very troublesome to re-select - they must exit the app, go to system settings, find Hopper in the list of apps in “Notifications,” and then re-set permissions.

Existing Process

The current flow uses three screens to briefly describe the product’s value and features, and then users are directly introduced to the app environment; when they use the relevant features, the authorization dialog box will appear.

It turns out that most users don’t read even the brief introduction text; they just want to start using the app right away. Even if users do read it, the text is disconnected from the actual interface, making it difficult for users to relate to it, understand it, or remember it. This form of education is much weaker than we expected.

These guide pages actually include an introduction to the "wait and see" function, but fail to show the function interface and notification information in an intuitive way, and users are unable to realize the relationship between this core function and iOS permission application. Regardless of whether they read it or not, the end result is that users find it difficult to get useful information, and when they face permission application, the probability of clicking "Don't Allow" is very high.

Obtain authorization directly in the onboarding process

We decided to redesign the existing onboarding process and reduce the steps to two pages: the first page displays a welcome message to provide users with an overall sense of context; the second page focuses on "wait and see", briefly introduces the function and shows the specific form of the notification. The onboarding stops here, and we let the user enter the app environment before he loses patience. For other functions that require onboarding prompts, we will provide some tips in the actual interface to help users understand more immediately and intuitively.

After deciding on the general idea, I quickly drew some sketches:

This is how the actual UI looks like:

The first two screens of the *** row are the guide pages. Click "Allow Push Notifications" at the bottom of the second guide page, and the authorization dialog box will appear.

We believe this is a more proactive onboarding strategy because:

• Even if users habitually ignore the introduction content on the guide page, when they are about to click "Allow push notifications", they will think "What am I allowing?" and go back to read the introduction content.
• By reading the content, users will understand the value of the wait-and-see feature and how it relates to push notifications.

We want to know whether this improvement can increase the probability of users authorizing notifications, although this method is more likely to cause some users to abandon the app without even going through the guide page. The final verification result is that the proportion of qualified users has indeed increased. The so-called qualified users refer to those users who use the wait-and-see function after officially entering the app and benefit from it.

analyze

The optimization results look good. The proportion of users who use the wait-and-see function after entering the app has increased. However, after careful study, we found that the number of qualified users has not really increased. We have only changed the way they become qualified users. In the past, almost all users would go through the guide page process and enter the app environment. When they use the relevant functions, they will be asked whether to authorize. Those qualified users will agree to authorize, while unqualified users will refuse authorization and churn. Under the new process, qualified users will click "Allow Push Notifications" at the bottom of the second guide page, and choose to agree to authorization in the authorization dialog box that pops up next on iOS, and then enter the app and use the wait-and-see function; some of the unqualified users will give up directly when they see "Allow Push Notifications" at the bottom of the guide page, while the other part will click this button, but will choose not to agree to authorization in the authorization dialog box that pops up next on iOS, so even if they enter the app, they cannot use the wait-and-see function. Therefore, the fundamental reason why the proportion of qualified users has increased in the new process is that those unqualified users have not been able to enter the app at all, or even if they have entered, they cannot complete the conversion.

Continue to improve

There are two main problems that prevent more users from becoming qualified users of the wait-and-see function. First, these users do not read the content on the guide page, and this problem still exists; second, even if some users read and understand the introduction, they will still have doubts when facing the authorization dialog box - they will choose to refuse authorization first, and then enter the app to experience the product. In fact, the model of allowing users to apply for authorization after experiencing the product and entering the wait-and-see function as in the initial process itself is fine, and users are more likely to have the desire to use it in actual situations. It’s just that in reality, we can’t expect users to make a rational choice to authorize in that almost only chance.

So we tried to combine the two solutions - based on the two-screen guide page pattern, we provided users with two choices on the second page:

• “Not Now” – Regardless of whether the user has read the two-screen introduction carefully, if they are struggling to build trust at this point and want to experience the product first, they can click this button and then enter the app environment without triggering the iOS authorization request. The system authorization dialog will not appear until they use the actual functional interface.
• “Notify Me!” – Users who trust the product and are willing to use related features can click this button (visual style enhancement) to trigger the iOS authorization request and confirm their consent to the authorization again.

summary

This model has actually increased the conversion rate. More and more users have smoothly completed the guidance process and entered the app to actually experience various functions, and eventually become qualified users.

Looking back at this model, it allows the entire onboarding process to be completed naturally, that is, the function is introduced without assuming that the user will read and understand the content - the choice is left to the user in the first screen of the onboarding page, and the users who trust us will directly authorize, while those who want to experience it first and then make a judgment can also smoothly enter the app, and further participate in the function through the guidance of tips in the next actual interface, until they reach the wait-and-see function, the cognition has been basically established, and then the authorization application is triggered, and it is natural to agree to the authorization. Trust is built up little by little in this way - to gain the trust of more users, don't force them to trust you immediately.