Product growth: Data analytics, client upgrades & server based client configurations [004.4]

Server based client configurations

Server based client configuraitonWhenever you deliver a SaaS based service to a user via a client application on a mobile device, it is paramount to have control over the various client configurations from the server platform. I cannot emphasize enough because when you have 15M+ users using your service and you have to deliver new client build, it could take months to get users to download the new version. Till that time your users are stuck with whatever issues you have identified simply because you do not have any control over client configurations from the server infrastructure. Our team identified this issue very early on and literally implemented most of the client configuration controls in the server. Some of the key features that were controlled from the server included:

  • Kill switch to disable/enable the client app
  • Switch the notification protocols from SMS to GCM to 3rd party SMS provider such as Clickatel, etc.
  • Deliver new price plans
  • Auto provisioning / deprovisioning of service and price plans
  • Underlying password exchange mechanism
  • Enable / disable user account
  • Enable / disable Ad support
  • Enable / disable Avatars
  • Auto / manual upgrades

If you do not have server controls for client app configurations then it has a huge potential to become a customer care and PR nightmare for your company.

Client app upgrades

UpgradesAuto upgrade of client application is an option in app stores but not necessarily users will check this box for your application. Therefore, nudging the user when new client build is available is important for adoption of your upgrades. Having in-app client upgrade capability is mandatory. In addition, you need to be able to mark every new upgrade build as either Optional or Mandatory. If a build is marked Mandatory then user should be prompted to upgrade every time user executes your application. If the user declines to upgrade X times then application will force the user to upgrade before allowing to execute the application. I know this is not recommended and we should not force the user ever. Therefore, Mandatory flag should be used seldom and only when extremely critical and should clearly inform the user why this upgrade is Mandatory. Being transparent with your user base is a very important part of building relationship between your app and the user. Users need to always be in full control.

The second part of the upgrade process is to deliver upgrades to millions of users. Typical app size now-a-days is in 10MB+ and to deliver this payload to 15M+ users at the same time is an operational nightmare. Therefore, have the auto upgrade capability enabled randomly over 30 days for your user base so that the app delivery process is staggered over a month to avoid failures in delivery the upgrade package to the device. We used CDNs to deliver upgrades to avoid delivery failures.

If you deliver value to your user based in every upgrade then chances are your users will look forward to your app upgrades and will accept them quickly. Therefore, it is important to view the upgrade from your user’s point of view and less from company benefit perspective.

Data Analytics

As you can imagine, with 10-15M voicemails per day, we were inundated with the amount of data we were collecting in our data warehouse from our servers and from the client application. The data warehouse had all structured data and the reporting provided lot of invaluable information for managing growth to 15M+ users and “what next” analysis such as:

  • Introduce 3-months and 6-months price plans for voicemail to text premium service
  • Introduce credit/debit card payments
  • Offer free trials after 6 months
  • Nudge users with client app upgrade notifications
  • Deliver premium service price increase impact analysis
  • Track daily premium service opt-in / opt-out rate by device models
  • Track daily Ad support opt-in / opt-out rate by device models
  • Track daily trial opt-out rate

To manage unstructured data such as tons of Web Logs and Voicemail Audio files, we had designed a big data architecture using hadoop clusters that would stand besides our existing data warehouse but even though the team was ready we never managed to launch it due to lack of funding for the project.

Nevertheless, the architecture looked like below as suggested by Tamara Dull in the article titled “The 5W’s: When should we use big data vs. data warehousing technologies?

We had an existing data warehouse and plan was to add hadoop clusters for processing Web Logs and Voicemail Audio files alongside the data warehouse. The Web Logs provided invaluable real-time operational information to DevOps in resolving user issues promptly.

Next up… increase adoption with new opt-in, UxD, and price plans.

Previous blog in product growth series: Product growth: Launch premium service with rev share biz model [004.3].

Leave a Comment