I would like to note an obvious, but very important thing right away: you should be prepared for the fact that the search for the perfect entry window never ends – the search for ways to increase conversion continues, tests are constantly being conducted, new options are being generated. And only with such tireless work and care for the authorization function, we significantly increase registration conversions. Details are below.
What was before the changes
Previously, when entering the KION application, the user immediately got to the main page, to the content showcase. Our initial hypothesis was that before asking the user to register, we need to give him the opportunity to get acquainted with the value of the product: the films and series available on the KION storefront.
And only then, when the user entered the card of the selected movie and clicked on the “Watch” button, he received an offer to register on the platform.
We decided to change this scheme. The fact is that experiments have shown that such a path is incomprehensible to the user: by clicking on the content card, a person expects the viewing to begin, and he is shown a registration form. Our team began to think about how to change the path. Ultimately, we decided to ask the user to register immediately upon entering the application. We were a little scared, because such a hypothesis is counterintuitive: it seems obvious that it is better to always let the consumer “feel” the product.
What and how did you decide to change
Why didn’t we do it right away? Because there were two main hypotheses:
First – the user first needs to show our serviceshowcase a variety of content.
The second – the user must be registered immediatelywithout disrupting the usual course of action. This is a more natural and familiar pattern: the user enters the service and immediately registers. Everything else – after registration.
At first, we were afraid that registering “on the threshold” would scare away some users. Looking ahead, I will say that the fears were in vain. All the same tests (don’t forget about them!) showed that people calmly register in the service before they get acquainted with it in detail. There is no problem in this. Moreover, the second scheme has an advantage – we immediately get the opportunity to communicate with the user, send him push notifications. We see information about him, we can see what kind of subscription he has.
What the login page will be like and at what point it will appear depends largely on the purpose of the service, business tasks. We had a goal – to authorize as many users as possible, to increase the base, so the whole process was “sharpened” precisely to achieve the goal. After all, if we increase the number of registrations while maintaining the conversion of registrations to a paid service, we will increase income. This, by the way, we have achieved (more on this below).
Other projects, even in the same niche, may have other tasks – for example, to sell a subscription. In this case, the login page may contain information about tariffs and trial periods, in the spirit of “subscribe such and such a subscription now, the first X days are free.”
Registration first. Everything else – later
The registration window in our case is one of the most important windows in the product, since only an authorized user has the opportunity to consume the main value of the KION product, namely, to watch content. Our task at this stage of the funnel is to register as many users as possible. It is this screen that onboards the user to register in the KION service.
When working on the registration window, we were frankly afraid of breaking our metrics. Since this is a completely new screen, which was not there before. Nevertheless, we really wanted to answer the question “What if the user is immediately prompted to enter the service?” It must be admitted that the competitive environment has already made this pattern of behavior habitual for the user, and we decided to try it. Plus, we already had a successful experience of running a similar screen on Android TV.
When we designed this screen, we knew it had to be fast. All the studies that we conducted told us that the user does not make more than 2 clicks at the onboarding stage, so we faced a difficult task – to try to tell about the benefits of KION within one screen and it is desirable to do it differently from others. And we found the solution in the interactive feed. It is implemented as a drum with advantage cards. This drum makes you want to flip through because it responds nicely thanks to the slide effect. Leafing through such a tape, the user feels a pleasant vibration.
All information is stored on the server, which means that we can quickly change the set of benefits on this screen at the request of our marketing. In total, we rolled out this screen as an experiment for users and saw that the results of conversion to authorization are quite good.
Announce the results please
And please! Here are the most revealing results of the testing experiment on different user groups, with devices on Android, iOS and Android TV.
On Android devices (excluding Android TV), the growth was over 7 percentage points! Excellent result. And we didn’t drop the conversion to paid actions. The experiment was conducted with two groups of users, each of which had over 100,000 participants.
The results of the experiment showed that the first onboarding on Android significantly increased:
conversion to authorization on the day of the install – as mentioned above, by 7 percentage points
conversion to VOD and Live viewing — by 1.7 p.p.
weekly TVTu VOD and Live – by 8.67 min.
conversion to signing up for a subscription — by about 0.49 p.p.
On iOS devices, the increase in conversion from install to registration was less and amounted to more than 3 percentage points. The experiment was conducted with two groups of users, each of which had several tens of thousands of participants.
But here it is interesting that there were no changes in other metrics, as in the case of Android. Perhaps this is due to the fact that on iOS the conversion was initially higher than on Android. Therefore, it was not possible to greatly expand the first version of the funnel, with a significant impact on other product metrics. And we once again convinced ourselves of the validity of one of our principles: do not extrapolate the results of Android A / B tests to iOS (and vice versa). Still, despite all the similarities, the behavior patterns of Android and iOS users are different.
On devices with Android TV, the conversion from install to registration increased by 4 percentage points. The group of users who were asked to log in at the entrance showed a higher conversion to authorization/registration.
In addition, the results of the study showed that a lot depends on who specifically comes to the service. In other words, you need to adapt the login window to different audiences and different traffic sources. If this is organic traffic (for example, a person who typed KION in the search, downloaded the application and logged in), then showing a request to register is quite appropriate. The user knows what an online cinema is and assumes that he will be immediately asked to register.
If this is advertising traffic, then we do not show such a window, because here the user has a different logic. If a user sees a banner ad for our series and clicks on a link, they don’t expect to have to wade through onboarding and authorization. He is already interested in the content and understands the value for which he came to the service, he wants to switch to watching rather than waste time viewing additional offers. This nuance is worth considering.
A few tips from personal experience
In the process of working on the login page for the KION online cinema, we got several important results that are worth additionally fixing:
at the first stage, the user needs to be registered, so you should not do some kind of detailed onboarding at the entrance – this is too long. A simple and fast screen that is clear to the user works best
it is also extremely important to be able to manage the landing page settings from the server. This allows you to quickly adapt to possible changes. It doesn’t cost anything to hardcode, “nail” something in the client itself. This generally applies to any application screen, not just the login screen.
as for traffic, it is important to be able to change the login window depending on the type of traffic, we have already discussed this in detail in the article
the user’s path cannot be interrupted. So, for example, if a user is recommended some kind of content card, then clicking on it should open this content, and not the registration window, subscriptions, etc. Otherwise, the user can be lost
no need to assume that Android and iOS are similar. A/B experiments should be conducted on each of the platforms (and also separately on the mobile and desktop web applications)
don’t be afraid to do counterintuitive things. Sometimes there are unexpected and profitable insights behind them.