Guide users to authorize app to send notification of the actual combat skills

The success of the initial licensing application will largely determine whether the full display of the value of the product to retain users, in this seemingly obscure but almost a blow to determine the outcome of the link, we need to be cautious, for any optimization plan, all the possibilities should be taken into account. Today, share a guide to the actual combat thinking, conversion rate data proved that this article is very valuable.

Our hopper application, every day will analyze the massive ticket price, and can accurately forecast the price change trend, tells the user when buys the ticket the most cost-effective.

Hopper can make very precise price forecasts and tell you whether you should buy a ticket or keep waiting. In the waiting process, you can use the "wait-and-see" feature, the app will continue to look at your attention to the flight, until the price into the "low price" range, you will be pushed to the proposed purchase notice.

We want more users to discover, understand, and use the "wait-and-see" feature and benefit from it. We are very sure that the conversion rate on this feature is far from peaking, stimulating the user's demand for the wait-and-see feature, which is our very important product strategy. Considering that the wait-and-see function itself can enhance the stickiness of the product-for example, even if the user uses the "Wait" will also go back to the app more frequently, look at the information related to the current situation, or try other functions while waiting-we want to make sure that users are fully aware of the value of this feature when they first use the app, and completes the push notification settings correctly. So we decided to optimize the previous novice boot process.

　　Questions about the notification

Clearly, the notice is extremely important for the wait-and-see function – If users do not allow Hopper to send notifications, they will not be able to receive ticket advice when prices reach a low price range, and the wait-and-look function will lose value completely.

iOS will give users the decision whether to allow app to send notifications, and each app has only one chance to trigger permission requests.

If the user chooses "OK", then everybody is happy; If you choose "Do not allow", then even if you change your mind in the future, it will be very troublesome to choose again-they must quit the app, go to the system setup, find Hopper in the app list in the notifications, and reset the permissions.

　　Existing processes

The current process introduces the value and functionality of the product through three guide pages, and then the user goes directly into the app environment, and the Authorization dialog box appears when they use the relevant functionality.

It turns out that the vast majority of users simply don't read even very brief introductory text, and they just want to start using apps right away. Even if the user really to read, such text form and the actual operation interface is also disjointed, the user is difficult to produce association, understanding and memory will not talk about. This form of educational effect is much weaker than we expected.

These boot pages already contain an introduction to the "wait-and-see" feature, but do not visually display the form of a functional interface and notification information, and users are not aware of the relationship between this core feature and iOS permission requests. Whether you read it or not, the end result is that users find it hard to get useful information, and when they face permission requests, the chances of clicking "not allowed" are very high.

　　Get authorization directly from the boot process

We decided to redesign the existing boot process to reduce the steps to two pages: the first page shows the welcome information to provide users with a overall sense of context; The second page focuses on "wait-and-see", briefly describes the function and shows the specific form of the notice. The boot is over and we let him into the app environment before the user loses patience. For other features that require guidance, we provide tips in the actual interface to help users get a more intuitive understanding.

After a rough idea, I quickly drew up some sketches:

This is what happens when you implement the actual UI:

The first two screens are the boot pages, and the Authorization dialog box appears when you click "Allow push Notifications" at the bottom of the second boot page.

We consider this to be a more proactive approach to guidance because:

Even if the user habitually ignores the introductory content in the boot page, when they are ready to click on "Allow push notifications", they also think "What am I allowing?" to go back and read the introductory text.

By reading the content, the user will understand the value of the wait-and-see feature and the connection to the push notification.

We want to know if this improvement will increase the probability of user authorization notification, although this approach is more likely than ever to cause some users to even skip the boot page before abandoning the app. The final validation result is that the proportion of qualified users has indeed been upgraded. The so-called qualified users, refers to those who formally entered the app after the use of the wait-and-see function and benefit from that part of the user.

　　Analysis

The results of the optimization look good, and the proportion of users who use the wait-and-see feature after entering the app is getting higher. But after careful study, we found that the number of qualified users has not really improved, we just changed the way they become qualified users-in the past, almost all users will walk through the process of the boot page into the app environment, they are using the relevant features are asked whether the authorization, those qualified users will agree to authorize, Non-qualified users will reject the authorization and loss. Under the new process, the qualification user will click on the "Allow push notification" at the bottom of the second boot page, and then in the next iOS pop-up Authorization dialog box to select the consent authorization, and then enter the app and use the wait-and-see function; Some of the unqualified users will simply give up when the "Allow push notifications" at the bottom of the boot page. While the other part will click on this button, but in the next iOS pop-up Licensing dialog box will choose to disagree with the authorization, so even access to the app can not use the wait-and-see function. So the fundamental reason for the increase in the number of qualified users in the new process is that those who are not qualified have not been able to get into the app, or even enter it to complete the transformation.

　　Continue to improve

There are two main problems that prevent more users from becoming qualified users who use the wait-and-see feature. First, these users do not read the contents of the boot page, the problem persists, and second, even if some users read and understand the content, they still have doubts about the licensing dialog-they choose to reject the authorization first and then enter the app to feel the product. In fact, as the original process to allow users to experience the product after the wait-and-see function to put forward the authorization application model itself is no problem, users in the actual situation is more likely to produce the desire to use. In reality, it is impossible to hope that the user will be able to choose the authorization in a way that is close to the only chance.

So we're trying to integrate the two options--based on the two-screen boot-page mode below, to provide two choices for users on the second page:

No now-whether or not the user has carefully read the introductions in the two-screen boot page, if they are having difficulty building trust at this point and want to experience the product first, click the button and then go to the app environment without triggering an iOS authorization request. The System's Authorization dialog box does not appear until they use the actual functional interface.

"Notify me!" – Users who trust the product and are willing to use the relevant functionality, click on this button (visual style hardening) to trigger the iOS authorization request and reconfirm the consent authorization.

　　Summary

This model of the real increase in conversion rate, more and more users to complete the flow of the boot process and into the actual experience of the app, and eventually become qualified users.

Looking back at this pattern, it can make the entire boot process natural, the features are introduced without the assumption that the user will read and understand them – the option is left to the user in the last screen of the boot page, and the user who trusts us will be given direct authorization, and those who wish to do the first experience and then make a decision can also enter the app smoothly , in the following practical interface through tips to further participate in the function, until the wait-and-see function, the cognition has been basically established, then trigger the authorization request, consent authorization is a natural thing. Trust is a little bit of a setup – don't force them to trust you immediately, to get the trust of more users.