Product Management : Feature Prioritization Steps as simple flow chart

Prioritizing features is one of the challenging task of a product manager. I have tried to capture the steps as a flow chart. Happy to discuss more through comments.

 

What's new in GCM 3.0 (Android M)

   Google understands the power of messaging and brought significant changes in their GCM platform.   I will try to write one more article with more usecases on each feature, until then hope this would be helpful.

i) Extending the support beyond Android and Chrome: Yes :) now you can send push messages to iOS platform as well using GCM 3.0. You still need to get the APNS token from Apple and it depends upon Apple to deliver the message, when App is in background. Google have mapped the commonly used Apple payload parameters. Integration of Google's sdks on our iOS app is required for this support.

Whats the major Advantage: 

a) Upstream messaging : Apple doesn't currently support that. Though with help of silent push we can manage delivery receipts, this facility makes job much simpler though. 

b) Topics subscription 

c)  Diagnostics Tools access 

ii)  Topics: 

       This is a wonderful and welcome change. This helps us to create topics,subscribe/unsubscribe users to topic and publish update. Just send the message to created topic alone and all the devices subscribed to that topic would receive it. This is similar to our preference center (Please read this if you have missed it ) and we all appreciate why preference center is important for better UX. 

       Our app might have multiple areas of interest and I might be willing to receive only about a particular topic/area of interest rather than receiving every alert. (for e.g..,  on a shopping App, I might be interested to receive alerts only about Baby products and Deals of the day). Currently we might have been managing this with a Preference center and handling all the database flags around subscriptions. But after this topics change, we don't need to do this heavy lifting and Google itself has now provided tools through this for cleaner way of implementing preference center.

       This is supported for iOS as well by GCM 3.0.

iii) OS level notifications on Chrome:

     Same push notifications, but wherever (Windows, Linux,Mac (not iOS), Android) Chrome is installed.  My understanding based on the demo, is when we send a push notification on a Android device for Chrome webpage, it would come in notifications tray (including lock screen) where other notifications are listed. This is a feature which I have been longing on Android/iOS devices and wish iOS also provides this support in future. This is good thing because currently on lot of articles where they have debated about html vs native apps, they would have called out, push notifications are not possible in html/ webapp, this feature overcomes that and providing the same UX as native app by dropping the message on Notifications tray. 

     I assume this along with Google Now can do lot in future.

iv) Diagnostics Tools for developers:

    An option provided in Playstore console to see the status of message sent. This definitely helps if we know the registration token of the user or message-id (an id GCM returns to us when we send a message).  

    It would be great if Google expands on this idea and provide facilities to App publishers to understand overall acceptance of each push campaigns, as, of now App publishers are unable to attribute the reason for low push opens, easily. Even if its just a console with status percentages for every campaign that would greatly help. This can also be extended by Topics as well. 

v) Device Group Messaging: [This is similar to the "User Notifications" & "UpStream messaging" topic discussed in 2014 I/O]

    This is also a powerful feature, where we can group registration ids together and form a group and send one message to group by which it reaches to all persons in the group. 

    A typical use case would be to group all devices belonging to a user and when user opens the message on a particular device, we can send a upstream message from that device to server and send a message to other devices to dismiss the notification on other devices. This can also be implemented with help of delivery_receipts_requested key in GCM, which automatically provides you the delivery receipts. 

vi) Permissions:

     Permissions is a platform wide change, so the permission will be prompted upon GCM usage. We need to wait and see how this looks. It would be great if the permission message is customizable as we can explain the benefit, they gain by accepting push notification rather than just prompting "App would send notification.." which generally leads to low opt-ins. You might see lot of Apps in iOS displaying a custom alert before displaying the actual OS notification, as iOS is not permitting to change the OS alert copy.  [Ref Permissions 101]

   

vii) Introduction of Instance Id:

           Which they define in three words: Identity for Robots.

 It contains two parts one instance of an App (It is the app which we have installed) and a security token (used to send message to GCM). This can be viewed synonymous to existing registration token of GCM. 

  I am also aligning to think whether we can use this as an identifier for devices, as we don't have one. We were using UDID on iOS which Apple banned using and we don't have a neat way of defining id for Apps which doesn't require a login. More to come on this topic. 

  Important Note: GCM register() has been deprecated, and it is recommended to use InstanceID to perform general GCM registration management.

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.