Gamification in Healthcare using mobile Apps

   It has been hectic months so far. I wrote this article 3 months back and now only had time to publish it. Interestingly I didn't see much change in concepts so its still relevant. 

     Everyone wants to lead a healthy life, what is stopping them from that, in my point of view its two things i) Their daily busy schedule ii) Lack of awareness.  Though point i) is one of the cause, there are persons like Arnold who has proven to world that shouldn't stop them (I heard, he used to do his exercise inside a military tank so he doesn't skip his routine). So, lets conclude busy schedule with lack of motivation.  

  Before coming to the motivation part lets try to understand one more element which is absentmindedness. Forget, taking a stroll every one hour we even forget to take our medicines on time.  So our challenge here is first to make user start practicing wellness activities then making it a regular activity and realisation, such that they don't require any reminders to perform the activity. 

How does an App helps achieving all this? 

   There are some capabilities of mobile device which we can leverage. Lets start with first part, making user to start an activity and be a regular. 

    I have been writing numerous articles in this blog about push notifications, so lets start with that (Advt;)). Our first step would be an attempt to understand what is users current health state and what he requires. Is it that, they want to reduce weight or as simple as pill reminder. Based on his need our App would create a plan (eg., take a short walk every one hour, drink water every half an hour etc.,) we would remind user to do this with notifications. The catch here is the App must be intelligent enough on when to remind and when not to. For eg., I don't want a reminder to take a short walk when I am inside a train.  Also we must not ask user to enter how many steps he walked, the App must automatically do that. As much as possible minimum data entries would be ideal.

Intelligent reminders alone enough?

     Seems no. Here is where gamification and social media helps.  First lets create a game plan which is more relevant to user's need. As every game has a hero (of-course, users are the hero) and villain. Lets define to users what helps them increase their power to defeat bad guys (As spinach powers Popeye :)). An example would be drinking 8L of water everyday would help you to achieve special powers to cross some levels and in turn if you smoke you would lose some powers. Again this would be based on user's need.

   Now game plan is defined, intelligent notifications are build around it. What more is required. A Team. As even if App didn't motivate the users, making sure their team never fails would motivate them more. We are all in social media platforms we can leverage that to form a team. 

   Our health game plans must be simple, non-lengthy and achievable. We need to make sure our goals shouldn't de-motivate.  As and when Team completes a small task it will elevate the team’s status and bring in more challenges. After every game a Performer badge could be provided to a master performer in a team and best team could be awarded as well and rankings in leadership board, which would be viewed by everyone. We need to bring in capabilities where a team member can poke other team member to do his tasks. 

  We need to define the leaderboard very carefully such that it should be motivating by displaying how many points/position a team is below his next Team so that it might motivate him to do things timely to beat that nearest team rather than showing the team with >100k points alone which would be de-motivating.  Awareness can be built inside the game with related videos and articles which would help them to win the game.

  Remember we need to also be careful about what we share in social, as not many users would be willing to share their weight loss/any personal health goal to all their friends.   

 I hope these are the first steps and furthermore would be data mining and targeted notifications, lets discuss about that in next blog. 

What is Push Feedback Service and how to implement it effectively

A feedback service would help us identify whether a device is still opted in to receive push notification from our app. This is one of the ways to measure whether our push campaign is successful or not. The feedback service is not instant, that is Apple would not immediately know when user turns off push at device level for a given App. Apple would add that device to its do-not-send push- list [a name for discussion’s sake] only when there is a failure in delivering the push.

Say you send a marketing campaign push and user receives it and for some reason turns-off the push notification permission for our app. When you execute the feedback service, that user’s device wouldn’t be in Apple’s do-not-send-push-list. But when you send your next push and as it fails for that user’s device, then the user’s device would be in Apple’s do-not-send-push list. Note push notifications that expire before being delivered are not considered a failed delivery and don’t impact the feedback service. The feedback service’s list is cleared after you read it.

 Assume there is a marketing push campaign, and we want to measure success. Do we need to send one more user facing push to identify how many users have opted out of push after the campaign?? No, there is a way, which is using silent push (available from ioS 7 and above). Silent push is nothing but setting content-available key as part of payload. When that key is present in payload, iOS would treat that as silent push, which means user would never know a push was sent to their device.

 Typical Silent push payload in iOS:

{

aps = {

"content-available" = 1;

sound = "";

};

}

         So the steps to identify how many users have turned off push notification after a push campaign, would be to send a silent push and execute the feedback service. 

        These steps can be used on a small set of population to measure the engagement, before we send the actual push campaign.

         Now the question would be is there a silent push equivalent in Android. Well, there is Send-to-Sync messages which can be used. These Send-to-Sync messages update app data using push notifications. But I haven’t used it before. The advantage in Android is whenever a push reaches a device, it is not immediately displayed in notification manager, it signals our app and our App can decide whether we can display it or hide it. Leveraging this we can have a key in payload to help our app decide to hide the push and mimic this as a silent push and then ping GCM to check for NotRegistered error message.
         
     Just in, in android latest version, as part of the payload we can specify delivery_receipt_request value to true, on setting that GCM would indicate whether the message is delivered and we can use upstream messaging using XMPP to indicate to our server whether user have read the message. 
    

Differences between iPhone and Android Push Notifications: [APNS Vs GCM]

The documentation on how push works are clearly explained here on the following links:

iOS, Android,Windows

The above references should help you to understand how push notification works. I felt it would be repetition to explain the content again here. Felt writing an article that explains the differences and some nuances between various push mechanisms: [Note: Please feel free to correct me, if any of the below information is incorrect.]

	iOS	Android
Permissions	Methods are available to identify the user’s opt in status	No methods are available
Feedback Service	Yes, along with silent push it’s a great way to measure success	Yes, but lots of tweak is required.
What happens when push reaches the device	iOS automatically puts the message into notification center	Android informs the app that there is a message, and app can decide whether to display it or hide it.
Store and Forward [What happens if users device is offline, when push is attempted to be delivered]	It stores only one unsent message that too recent.	It can store multiple based on collapse keys.
Message Expiry	Apple didn’t reveal.	It can be user set value with time-to-live parameter [0-4 weeks max]
Localization	Yes using loc-key,loc-args	Not directly but we can use same iOS approach
Two way messaging	No	Yes using XMPP
Multi-device Messaging	No	Yes
Receiving messages from Multiple senders	No	Yes
Misc	Silent push,ioS8’s category support	Sync to send, Priority flag support.

For Push 101 and other engagement techniques read Push 101
For updates on Android GCM 3.0 refer GCM 3.0 Push
New Blog on Apps & Bots : Why Bots wont replace Apps

Push retargeting on iOS and preference center

     This article explains the guidelines to be followed when we miss the first chance to opt the customers in for push notifications. [You may need to read this to understand the benefits of opting the user in first time alert itself]

      Once we miss the first chance, the possible approach would be to apprise the end users on how our notifications are going to help them and ask their permission for optin. Before we do this, we need to identify the possible touch points that would strongly motivate the user to optin for notifications. An example would be to show the permission alert when an item in their shopping list have a coupon, “Hey would you want us to send an push alert when you have a coupon for the item in your shopping cart”,after they have added an item in the shopping list.

     After identifying the touch points we may not be able to just display the OS alert and opt them in (in iOS alone), and the reason is explained in the previous article which is basically user needs to manually change the device level optin settings. Hence, now we need to display an additional alert for iOS alone, which instructs the user on how to achieve that.

     An example of that instruction alert would be like what Facebook messenger does. [Try turning off push notification at OS level and open facebook messenger app]. So the retargeting steps would be to display an optin alert at right time and followed by an instruction alert on how to turn on at OS level. This instruction alert is required only in iOS.

      Now we understood how difficult it is to retarget when user says no to initial alert or turn off notification at device level. At the same time,we need to provide a facility for the user to turn off push notification in a simpler way,inside our app, so that it would be easier for us to opt them back when required. That's where preference center comes into picture.

      Its basically a toggle/set of toggles that helps the user to optin/opt out of push notification(s). In iOS, this works perfectly after user has given their consent to OS alert, if not display an instruction page on preference center on how to turn on push at OS level. If the user wants to opt out of push notification encourage them to do so using the toggle which we have provided here,rather than user turning it off at OS level. Another advantage in providing the toggle is we can measure how many users have opted in/ opted-out so that we can appropriately use other channels like SMS/email for engagement. The preference center is recommended in Android as well.

       The recommended apps to check out preference center would be Bank of America and Facebook.

Tech Notes:

1. In iOS you have option to read status of each notifications option (like status of Alert Style etc.,).
2. In Android prior to Jelly Bean, you never had option at OS level to opt-out of push. After Jelly Bean you do have an option but there is no method to read the toggle status.

Push Notifications Basics - 101 [Permissions handling]

   As the recent WWDC also came up with new updates on push notifications, I felt it is right time to revise the basics of good push messaging experience. I will start with basics and will cover till advance topics like silent push. 

 Let us start with push permissions:

iOS:
 

  Seeking permissions for sending push notifications is actually an OS driven alert. The caveat here is, this OS driven alert can be displayed only once, so we need to be very cautious in using this. If user opts for "Dont allow" on the OS alert, then it would be difficult for us to opt them back, as they need to manually opt-in through device's settings.


 Here are some guidelines which if we follow would have maximum conversions:

i) Never ask for permissions until you have decided to send push notifications on the same app release. I have seen lot of apps doing this mistake and in fact when I am new to push notifications, I felt by default when we install app this alert would be shown :).

ii) Once you decide to send push notifications ensure that before initiating/displaying the OS level permission request/alert, display a custom page and apprise the users about the benefit they gain by accepting for push notification.

Try to be more specific, as the prevailing users have a general idea on push notifications. Once user accepts, then display the OS alert because without which you cannot opt-in the user for APNS/ push notification service. It would be wise to have an option like “Not now” on the custom alert page and retarget the user on later stage.

   The advantage of this approach is 

a) We have apprised the user about the benefits and have helped them to make a decision.          

b) We are using the one time OS push permission request very carefully and use it only when the chances of conversion are very high. (ie., in our case displaying when user says “Enable” and not showing when they choose “Not now”) 


iii) Decide carefully on where to display this custom alert. I see lot of apps that displays this screen when the app is installed and launched, which might go well if we have a custom page. But a better option would be when the chances of conversion are very high. An example is to ask permission for push notification when user completes a checkout

            "We will send you a push, when the order is shipped" etc.,

  On my next blog I would explain better ways for re-targeting in case if we miss the first opportunity to make them accept for push notifications.

Android:

 
 In Android GCM notifications, we do not have permissions concept as the permissions for push are sought in Playstore itself, when user is installing the app.

 Note: Prior to Jelly Bean user never had an option to opt-out for push and after Jelly Bean Android came up with an option against each app at device settings level.

Windows:
 As far as I know I didn’t see any option for optin for Live/Raw notifications. 
       

    Now before we wind off let me show you a small technique to test this permissions on iOS and here you go:

• Delete your app from the device.
• Turn the device off completely and turn it back on.
• Go to Settings > General > Date & Time and set the date ahead a day or more.
• Turn the device off completely again and turn it back on.

  Once you do this you might be able to see the iOS permissions alert again even though you have seen before.

Guidelines for the first release of Mobile App

    

   There are many articles which explains whether we need to have mobile optimised site or app, but not much what you need to do when you decide to create an app. I am writing this article to understand the essential features we need to incorporate in the first release or first version of the mobile app. 
    I am not going to discuss much on business features like shopping cart or how to leverage device capabilities like GPS and have feature like Store locator etc., as I presume you would have analyzed those.  These are more in terms of app’s scalability and good user experiences to gain end-user’s trust.

i) Forceful and Optional App upgrade capability: [Assuming background refresh is off,as there is a general mindset among users that it drains battery]

Upgrade and crash are inevitable with every app. We start with basic functionalities on the first version, and also we never try to bundle too many features on the first release. Once it starts gaining attention we try to bundle more features and have subsequent app releases. We definitely need to build a capability to ensure, existing consumers never miss the critical future updates.  

             It might be an optional upgrade or forceful upgrade capability ,we definitely need to incorporate it as part of the app. One possible implementation is having a service which would check every time when the app is launched to see if user is having the required version else display an modal alert. You can also have a cancel option on this alert to make this upgrade optional or just an upgrade option to make it a mandate. 

ii) Identify Opportunities to expose any feature API:

While designing the app identify if there are any features which can be bundled separately and can be used by other apps. For eg., Assume you have a photo print store and building an app for that, you can expose your app’s checkout process as an API for other photo apps  to send print order to your stores. This would be a good revenue building opportunity.

iii) Plan your permissions:

As a first version app publisher, we must try all possible ways to gain user’s trust. It is not advisable to ask for permissions until we require it. I have seen lot of apps asking permission to send push notifications but never send one. In case if you decide to use device features and require permission, never ask for permissions just using the OS alerts alone, but before displaying the OS alerts, display a custom alert apprising the user your intent. 

Provide excess caution with Android app as user will be listed with all access details when user is trying to installing the app and they may decide not to install.

iv) Deep Link Capabilities:

Provide deep link capabilities for all the features inside the app, which would help you for marketing and support purpose. 

v) Registration and Login:

This is quite important, lot of people try apps just by word of mouth. On first launch, when they are immediately shown a registration screen, they might be wary to proceed. This includes open id login approaches as well. The better approach would be like what “Polar” app does. You define the UX in such a way to allow the user start using the app and make them realize why registration is helpful in due course of time.

Also, have an ability inside the app to migrate and attach the essential user data when he decides to register. 

In case, if app definitely requires a registration, apprise him the benefits of registration and then request for that. 

vi) Temporarily shutting down a feature:

You might have more than one important feature inside the app and chances are,due to any reason a feature might not work properly. We must provide facility for our user to use other features while preventing access  to the corrupted feature alone by gracefully displaying an alert. This can also be used when we decide to temporarily prevent the users from using a particular feature.  

For this, we can also build a service as explained in forceful and optional app upgrade capability.

vii) Analytics and Crash log:

This is quite important to understand which feature is more popular and study user’s behavior. In addition to analytics, we need to provide ability to send crash logs from app, which would help us to analyze which feature has buggy implementation and try to fix in our next release. For analytics we have Omniture,Floodlight or Google tags. For crash logs we have Hockey,APIGEE kind of tools.

Android apps has ability for SEO tagging which can be leveraged as well. 

viii) Security:

Ensure that you don’t have any access key stored inside the app and fetch it through service when required. At the minimum, just open the ipa file in editor and check if there are any credentials stored without encryption and try to fix.

ix) Engagement Statergy:

I have noticed lot of apps when they release their first version, they are very successful, but in due course of time without proper engagement statergy they lose customer’s engagement with app and thereby revenue. I will write an another blog on these techniques but definitely plan one before releasing the app.

x) Multilingual support:

Though for the first version you might release it in only one language but design it in such a way it supports multilingual in later releases.

xi) Terms and condition, privacy policy pages:

These pages are tend to change and never implement these pages as part of native implementation,as later if we need to change we would require an app release and it is recommended to have these pages in HTML,so update becomes easier.

xii) User Feedback:

Always have ways for the user to give feedback. Identify the touch points and provide option whenever possible. It can be like when user completes a shopping. Never take the user directly to app store for rating, provide an interface where he can reach out to you for comments/feedback and then if it is positive (like he gives 4 star rating on your UI), request them to give ratings in app store. 

Bare minimum have your contact information for the user to reach you, which would build trust.

xiii) Welcome screen and Help:

Though this is essential, never crowd all information about how to use your app in its entirety here. Start with basics,keep apprising them with information as and when needed. This is very essential to get user’s attention, because the user will tend to skip this help screen.

Provide a web link where user can view all these information. So, whenever they need support they can refer to that.

 xiv) Sharing:

People always like to share good things. Provide an ability inside the app for enabling the users to share a link for downloading our app.