Fully Full Stack

On my first day at @Gett as an android developer, I had already figured out what my first feature would be. During one of my intro meetings with my manager and our android tech lead, I had noticed that a very common feature on many phone-authentication-based-apps in the android universe was not developed, nor planned. That feature is called: Automatic SMS Verification with the ‘SMS Retriever API’, or in short: Auto SMS. Since I was quite experienced with this feature in my previous workplaces, I was very eager to actually implement it in Gett’s rider app.

I had presented my tech lead and manager with a short introduction about the feature, including a tech summary of what is needed, and they said I should go for it. And so I did. A couple of days later, really, the feature — from Android perspective — was done.

This sort-of-short blog is not a technical blog on how to set up the Auto SMS on android, nor on the server, as this is quite simple if we were to be honest. It is about the process of how I, as a dev operating within a domain, finds, design and eventually develop features which create valuable impact for the app and the company I am working for. It is also about looking at features from a different perspective — business one, and as hardcore developers, this is something we sometimes forget to do.

Why Auto SMS?

The idea behind Auto SMS is quite simple: as we need to authenticate a user cell phone number during the registration or the login process, we send an SMS with x length of digits to the user, and the latter need to type it into an input field which in turn will be sent to our server to complete the verification flow. This process can be troublesome for multiple reasons:

1. The user needs to copy/remember the verification code from another application, usually SMS app or from the notification bar as a push is received from the sms app. In later versions of android it is sometimes even auto-suggests above the keyboard as it does on iOS devices. This means that the attention of the users spans outside the app. On some android OS’s and devices, auto-suggest does not always work — and in those cases we rely on users to be able to correctly remember the code going back into the app and successfully input it.
2. SMS might be forwarded to the spam folder, users might miss it completely. In this case, the user might get a generic “message moved into spam”, and might not link it in their mind to the Gett verification process. Also, in many cases, with non tech- savvy users, they might be completely unaware of the spam folder entirely, and might wait and wait, which might lead to “resend code” again and again but pointlessly, as it will always land in their spam folder.

Historically, many apps tried to tackle these issues directly by trying to streamline the verification process on their own. This required accessing the user sms messages, which requires asking the user their permission to view/read their SMS. Now this by itself might affect the login flow and the user retention, as users grow more and more aware of their privacy. Needless to say, this is also quite redundant as we have no real use of reading the SMS apart from retrieving the code. The rule of thumb is, when asking for permission — always verify that it is actually needed.

Enter Google Auto SMS Retriever API.

Simply put, the google auto SMS can help us perform user verification via sms automatically without requiring any user permission for the process.

The benefits are clear: first, we have a serious 3rd party sdk/api that streamline the verification code from the SMS inbox to the app, without requiring us to seek for further permissions. Second, on some android OS and some devices, this can also be triggered from a spam message (not to be confused with blocked messages). The entire process can be done automatically without the user needing to do anything on their side.

The integration of the auto SMS is quite simple. On the android side there’s a few steps to be performed:

1. Include the Gradle Dependencies.
2. Start the SMS retriever client when needed and add necessary task callbacks. it will listen for up to 5 minutes.
3. It will wait for a broadcast message to be received from the auto SMS service which will include the verification code.

One caveat though, is that for the service to actually notify our app with the code, it needs to include in the SMS message a unique string made of 11 chars that represents the app sha-256 hash, compiled from the app’s package name and the app public key certificate. Without this string, the service has no way of communicating the message forward to the specific app. This means that the server which sends the SMS needs to include this string in its SMS message.

While this sounds like a simple task, and to be honest — it is, getting a priority for this task takes time, and more importantly — a lot of convincing.

Go Full Stack, ‘Fully Full Stack’.

For most of my professional career I have been an android developer. I have dealt with a lot of server tasks before, built server environments from scratch, deployed apps on them, created leaderboards for games, but it is not my forte. Being an android developer, you focus mainly on the application you’re working on, not on the sources of information you receive the data from.

As I mentioned at the beginning of this blog, I have integrated the android side of the task quite quickly. But I needed the server to send the actual hash inside the SMS message. I had presented the feature to our product, who were very impressed with it, but as I’ve learned from their response, Gett has different priorities than this ‘nice-to-have’ feature. Maybe in the future we will be able to allocate resources on the server side for it.

After about six months, failing to recruit the product for this task, and subsequently — having server resources to implement the server side of the task, I have decided to bring this issue up with my manager. To my surprise, he suggested a simple solution: be the product, be the server, or simply put: ‘Fully Full Stack’

Product wise, I needed to receive some data from our wonderful analytics sources regarding the registration process. How the login flow is actually performing. The second thing I needed to do is to integrate the server side by myself. The task itself was not too complicated, as the server only needs to take the regular SMS message and append the app hash to it. But since we only want to append it on messages sent to android, and not ones being sent to iOS, or earlier versions of our android app which did not include the Google Auto SMS Retriever, we needed a mechanism to sort this out.

Now as an Android developer I needed to dig into code by another domain, in a different language. In android we write in Kotlin or Java. On the server side we write in many languages, but the one for this task is Go. Like in any new areas we explore as developers, there was a learning curve to conquer. I needed to find out exactly where we formulate the SMS message, find out how to extract header parameters that reflect the OS of the user, and the user’s current android app version. On top of that, maintain backward compatibility and most importantly not break the code of a neighbour domain.

Another challenge was how to store the app hash, that had to be fetched when formulating messages. Should it be a const in code? Should I use our media service? Maybe it is a system setting? either way, we needed an easy way to turn it on and off.

All of this was addressed and discussed with one of my colleagues at that domain service. I have created a PR, done some dry runs, and after a back and forth with the domain reviewers, and a hand from their side in developing a part in the solution which some of it was out of my scope of knowledge, we finally got an approval. The feature was ready to deploy, but here I needed to wear my hat as ‘product’ and communicate about this feature. With the help of one of my product colleagues, we also forwarded this feature to our Tech support team to set up proper monitoring, just in case we needed to revert.

Eventually the feature was ready, monitors were set, it was communicated upwards, and so we launched.

Later on that week, as more people @Gett were exposed to the feature as they updated to the latest supporting version, I started receiving praises. This ‘nice-to-have’ feature was really liked. It’s not a game changer, but it makes your sign-in process much nicer. Eventually, this feature was selected as the second most popular feature from our domain for that quarter, outvoting bigger and way more complicated features from my team. And most importantly, in terms of actual ROI, it was a great success.

Results.

Whilst praises are nice, in order to declare this journey a ‘success’, we needed numbers. For example, let’s take a look at a simple funnel:

1. Code Submitted — user enter a code he received via sms
2. Invalid Code Popup

If we compare July 2022 vs July 2023 (pre/post feature) we can see the improvement in this metric:

July 2022: 7.37% Invalid Code Popup

July 2023: 3.51% Invalid Code Popup

While there’s still a rate of invalid code popups after the auto SMS integration, we see almost a 4% improvement with the auto SMS feature enabled. Invalid code popups might be due to late SMS messages, messages that are sent to spam and are not intercepted by the retriever, timeout of the broadcast receiver and multiple scenarios of user receiving business logic error messages such as blocked due to numerous attempts, fraud protection, etc. To put it another way, that is 4% more users that were able to successfully login to the app and order a taxi.

We can also inspect other metrics in regard to the login flow, which showed a valuable improvement:

• Conversion to first login: 91.8% -> 93.11%
• Time to first login (seconds): 43 -> 35
• Time to fill valid code (seconds): 17 -> 6

So by introducing the auto SMS verification on android, we were able to not only provide a better user experience, but also improve key metrics with our onboarding process.

Conclusions and Reflections.

The entire experience with the auto SMS has changed my view about my role at @Gett. While it is true that my most day2day work is android development, I cannot stop thinking about new features to be developed, most not on the ‘product’ or ‘business’ radar. Now it might be ok from time to time (if we have some spare time naturally) to go ahead with a feature — and fully full stack it by myself. It might also be a good idea to involve more people in the process, or to just pitch and forget. From my experience — I will probably always go ahead with pushing forward ideas, most probably — also wearing a ‘product’ hat, and if needed — a small server dev sombrero. I will also venture into looking into the marketing side of features, of the world of KPI and ROI. And while I have no aspirations of becoming a ‘product’ guy, I will utilize lessons learned from this experience as its product.

If you’re a developer, I would advise that whatever direction you choose, try ‘fully full-stack’. It is an enriching experience, humbling, but above all — one that sheds some light on other aspects in our developers eco-system that we mostly consider from the side.