My Best Articles on Mobile Commerce Strategies 2015

In 2015, a master strategy for mobile commerce emerged.  Mobile apps need to be personalized, but that is not enough. Personalization without context, relevance, value to the customer and permission is just creepy and/or obnoxious.  We recognized a new kind of partnership is required between customers and trusted vendors.  One that requires a deeper level of earned trust, and one that provides mutual benefits through the sharing of data.  We call this relationship a MME Data Partnership.

Parts of MME Data Partnerships can be found within many existing loyalty and rewards programs.  Although the purpose is rarely understood.  These programs define how the collection and use of specific data will be used to provide mutual benefits.  It is an overt agreement by both parties to share and use data in return for defined rewards.  Within a MME Data Partnership we found three types of data, we call 3D-Me, are needed to optimize a mobile user experience:
  • Digital data - online and mobile activities and behaviors
  • Physical data - Sensor and IoT 
  • Personal data - MME Data Partnerships
For each of these categories purposeful strategies need to be developed and implemented to collect, analyze and utilize the data in order to provide the best experiences for customers.

Personalization, as we have learned, is not enough. Personalization needs to be combined with CROME Triggers (contextually relevant opportunities, moments and environments), which are bits of data that when collected and analyzed in real-time, identify the need for specific and relevant personalized content.

All of these strategies and more are discussed in "The Best of Mobile Commerce 2015" articles listed below:
  1. Strategies for Personalizing Mobile Apps
  2. Special Report: Cutting Through Chaos in the Age of "Mobile Me"
  3. Mobile Strategies for Combining IoT, CROME, 3D-Me and Artificial Intelligence
  4. Mobile Commerce Strategies and CROME Triggers
  5. What Does the Age of Mobile Me - Mean for Retailers?
  6. Mobile Commerce Strategies and Tactics
  7. Retail Evolution, Mobile Experiences and MME Strategies
  8. Mobile Commerce, Speed and Operational Tempos, Part 1
  9. Mobile Commerce, Speed and Operational Tempos, Part 2
  10. Mobile Commerce, Speed and Operational Tempos, Part 3
  11. Latest Research on Mobile Commerce Trends and Strategies
  12. The New Mobile Consumer - Latest Research
  13. Mobile Consumer Behaviors - The Questions to Ask
  14. Video: Age of Mobile Me
Download the full report, "Cutting Through Chaos in the Age of Mobile Me" here: http://www.cognizant.com/InsightsWhitepapers/Cutting-Through-Chaos-in-the-Age-of-Mobile-Me-codex1579.pdf.

************************************************************************
Kevin Benedict
Writer, Speaker, Analyst and World Traveler
View my profile on LinkedIn
Follow me on Twitter @krbenedict
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies

***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.

Instantly Personalizing Mobile Apps - Cutting Through Chaos

Unique Consumers and Unique Profiles
Smartphones, laptops, PCs and in-store visits have made path-to-purchase journeys very complex and confusing for online retailers to recognize and support.  Consumers can search and discover products and services using a smartphone on their way to work.  In the evening they can pull out a tablet and engage in immersive research while laying in bed.  They may decide to review some more on their desktop at work, then at lunch time stop at a brick and mortar store to look at the product in more detail.  That evening, they purchase the product online using a laptop.  How is a retailer or e-tailer going to cut through this chaos and recognize individual consumers and their needs along their path-to-purchase journey?

In our research at Cognizant's "Center for the Future of Work" we found online shoppers use different devices for different categories of products.  In fact, 56% of online shoppers use multiple devices on many online path-to-purchase journeys.  On the go search and discovery is often initiated on smartphones, immerse research on tablets, while completing transactions on laptops is a common pattern.

Some products consumers are comfortable purchasing on a smartphone, others not.  We found online shoppers of different ages exhibit markedly different shopping behaviors.  We found significantly different online shopping behaviors between those with different education levels, genders, ethnicity and technology preferences (laptop/desktop vs. mobile).

Our findings reveal these variables, all added up, equate to thousands, if not millions of different combinations of needs, preferences, unique activities and behaviors.  These unique set of variables we call Mobile Me Profiles (MME-Ps), require different personalized content, at different times and locations, for each consumer in order to provide an optimal experience.  In this age of "mobile me" where customers demand personalized and relevant user experiences, it is necessary to identify these differences, precisely and instantly.

If you are going to compete and win in mobile commerce today, you must target markets of one.  It is no longer an effective strategy to treat your customers as one homogeneous market of unknown consumers.  In today's world of mobile commerce, where devices are intimate extensions of unique individuals, knowing those individuals, as individuals is key.

Read more on how to deliver these strategies in my new report, "Cutting Through Chaos in the Age of Mobile Me."

Download the report here http://www.cognizant.com/InsightsWhitepapers/Cutting-Through-Chaos-in-the-Age-of-Mobile-Me-codex1579.pdf.

************************************************************************
Kevin Benedict
Writer, Speaker, Analyst and World Traveler
View my profile on LinkedIn
Follow me on Twitter @krbenedict
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies

***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.

Mobile Technologies Revealed: Web and Native App Development Strategies

Our resident Cognizant mobile and digital technology guru, Peter Rogers, shares his insights into web and native app development strategies in this guest post:  Enjoy!
********
Peter Rogers
I often meet customers who want to transition web developers into mobile application developers. Apple has clearly tried to address this market using Swift but that does not offer a cross platform solution. Developers who have come through this transition will traditionally wrap the latest and greatest web framework (like Angular 2 or React) using Adobe Cordova through initiatives like Ionic. However great the latest web frameworks are though they can never compete with pure native mobile user interfaces powered by dedicated hardware acceleration. It may be a simple solution but the net result is never going to be present the best possible user experience and there will always be problems with Apple App Store submission and changes to WebView technologies designed to gently nudge developers towards pure native Apps.

Appcelerator Titanium has long since offered an excellent solution in this space but the only downside is the lack of a combined desktop and mobile solution.

Recently three new exciting initiatives arrived to offer new Titanium-like solutions in this space:

1.       React Native (http://www.reactnative.com/)
2.       Angular 2 Native Apps (https://www.youtube.com/watch?v=4SbiiyRSIwo)
3.       NativeScript (https://www.nativescript.org/)

The benefit of the first two is that the technology can be shared across both mobile and desktop effectively. There is no learning a new framework. For the web developers who are trained in Angular 2 or React then this is a very attractive solution for transition to mobile development without having to go anywhere near Cordova. In fact in most cases all you have to do is to swap out the final Cordova Wrapping process for a dedicated Web Native Development phase, which means you don’t have to throw anything away.

How does this magic work? Well advanced web developers have already started to mix Angular and React: using the big framework quality of Angular and the high speed rendering of React. This architecture is made even simpler with Angular 2 in which there is platform-agnostic template parsing and platform-specific rendering. This makes it possible to plug in React Native or NativeScript as the underlying rendering engine. This offers a future in which Angular 2 can create cross-platform desktop or cross-platform mobile applications, allowing you to choose your programming language (ECMAScript 5.1, ECMAScript 2015, TypeScript, Dart or CoffeeScript) and choose your platform-specific rendering engine (React Native, NativeScript, Angular 1, Angular 2 or React). For those who wrote off Angular 2 due to radical design changes then suddenly that decision is looking incredible hasty, for it is nothing short of genius.

If you watch the Angular 2 Native App video then you will see the focus around NativeScript. The question is why not consider Titanium or React Native? Whilst that is perfectly possible using the plug and play nature of the new Angular 2 rendering engine there is a clear advantage offered by NativeScript. To understand this advantage we need to take a slight diversion into Hybrid App world. As you may recall there are three main models for Hybrid Apps: wrapped web; runtime interpreters; and cross-compilers. If we start with cross-compilers then we will find Xamarin ruling the roost but I would not call this a Rapid Application Development approach. You trade performance for a slightly longer development time and a more difficult programming language. The interesting thing with Xamarin is the 100% API coverage available within a few days. There are also a few HTML 5 canvas cross-compilers like those found in Intel XDK but these are specific to Canvas technology which works better for the specific use case of widgets and games. We all know the most popular wrapped web solution is Cordova, with another notable entry being IBM Worklight.

Runtime Interpreter solutions do not quite offer the performance of a cross-compiler but they do offer support for rapid application development through JavaScript. Appcelerator Titanium is the most popular Runtime Interpreter solution and has teased a cross-compiler solution called HyperLoop for a long time but it is offered in a restricted capacity. I am a huge fan of Titanium and have used it a lot for various customers. I was really looking forward to HyperLoop but looking at the software repository then it seems to have slowed down to a halt. The only downside of Titanium is the lack of 100% API coverage but this is a shared limitation with most other portable native solutions with Xamarin and NativeScript being the notable alternatives. Now in the case of Xamarin the API wiring has to be performed by hand however in NativeScript then it is automatic.

So what is the magic of the Runtime Interpreter solution powering Titanium, Kony, React Native and NativeScript? Well Telerik (who created NativeScript) provide the best explanation that I have quite possibly ever read before online (http://developer.telerik.com/featured/nativescript-works/). In a nutshell the two core JavaScript engines that power iOS (JavaScript Core) and Android (V8) both expose a very advanced set of APIs that power the JavaScript bridge (http://izs.me/v8-docs/namespacev8.html).

·         Inject new objects into the global namespace
·         JavaScript function callbacks
·         JNI to talk with the C layer on Android

NativeScript offers the following explanation of how it uses these APIs in order to build the JavaScript bridge:

1)      Metadata is injected into the global namespace at build-time
2)      The V8/JavaScript Core function callback runs.
3)      The NativeScript runtime uses its metadata to know that the JavaScript function calls means it needs to instantiate an Android/iOS native object
4)      The NativeScript runtime uses the JNI to instantiate an Android object and keeps a reference to it (iOS can talk directly to the C layer)
5)      The NativeScript runtime returns a JavaScript object that proxies the Android/iOS object.
6)      Control returns to JavaScript where the proxy object gets stored as a local variable.

This is probably quite similar for most of the other vendors but the additional step that NativeScript adds is the ability to dynamically build the API set at build time using Reflection (introspection). Because generating this data is non-trivial from a performance perspective, NativeScript does it ahead of time, and embeds the pre-generated metadata during the Android/iOS build step. This is why NativeScript can offer 100% API coverage immediately because it does not involve the manual step required in Xamarin. To be accurate it is unlikely that NativeScript can offer 100% API but instead it will offer all of the APIs that can be discovered through reflection – there is a subtle difference here as those who have use reflection programmatically will pick up on.

NativeScript offers two different modes of operation:

1)      Use the low level iOS and Android objects directly
2)      Use high level abstraction APIs

The high level abstraction APIs are provided as RequireJS modules and allow you to work at a higher level of abstraction. If you were wiring this into Angular 2 then you would probably have an Angular component which either calls a Browser Object or an NS Module, which itself talks to either an iOS proxy object or an Android proxy object through NativeScript. Of course there is nothing to stop you having an Angular component that calls out to React Native and that option is being explored as well.

This is not to say that NativeScript is better than React Native, Titanium or Xamarin. In fact I can see the main use case of NativeScript as being used inside of Angular 2 as its platform specific rendering solution. I can actually see more people using React Native as a standalone solution even though it is in a much earlier state. I can also see Titanium carrying on as one of the most popular mobile solutions on the market today. I can however see native mobile web applications becoming a hot new topic and a great place to transition web developers towards.

Download the latest mobile strategies research paper, "Cutting Through Chaos in the Age of Mobile Me," here http://www.cognizant.com/InsightsWhitepapers/Cutting-Through-Chaos-in-the-Age-of-Mobile-Me-codex1579.pdf
************************************************************************
Kevin Benedict
Writer, Speaker, Analyst and World Traveler
View my profile on LinkedIn
Follow me on Twitter @krbenedict
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies

***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.

Latest Research on Mobile Consumer Behaviors and Mobile App Requirements

I just finished a major research paper titled, "Cutting Through Chaos in the Age of Mobile Me."  Our findings reveal current mobile consumer behaviors, the challenges in creating mobile apps for them, and specific recommendations and business strategies for winning in an age of "Mobile Me."  Download the full report here http://www.cognizant.com/InsightsWhitepapers/Cutting-Through-Chaos-in-the-Age-of-Mobile-Me-codex1579.pdf.

Video Link: https://youtu.be/IqN6NbY_Q0A
************************************************************************
Kevin Benedict
Writer, Speaker, Analyst and World Traveler
View my profile on LinkedIn
Follow me on Twitter @krbenedict
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies

***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.

Beacon Essentials You Must Quickly Learn

Our resident Cognizant digital/mobile expert, Peter Rogers, asked me to recommend a digital strategies topic to share, and I suggested Beacons for this week.  I confess to reading about them daily without knowing much about them, so I want to thank Peter for this article!  Enjoy!
********
Digital & Mobile Expert
Peter Rogers

Let's start with a Basic Beacons 101 class:

  1. Beacons do not push out notifications. They broadcast an advertisement of themselves (traditionally their UUID, major and minor values) and can be detected by Bluetooth Low Energy (BLE) devices.
  2. The proximity from a number of Beacons can be measured using typical triangulation techniques in order to get a (very) rough idea of (typically) indoor location.
  3. The Beacon UUID, major and minor version values are typically used for identification and used to map to either a message, service, media content, website, application or location inside the Native App.
  4. Beacons can have their UUID, major and minor versions (and indeed power level) modified statically before deployment or dynamically using WiFi connectivity. A Beacon Management App is often provided by a Beacon Platform Vendor to allow you to manage these values dynamically.
  5. Updating the Beacon major and minor values can be used to update the identity of the Beacons and subsequently change what they map to inside the Native App. This does mean there is a security risk of somebody remotely hacking your Beacons and changing their values to take down or corrupt your service.
  6. iBeacon is Apple’s proprietary BLE profile but their patents seem to cover more than just the profile aspect. There were Beacons before iBeacons. Apple did not invent the Beacon. What they did is an incredibly good job of integrating Beacon support into iOS. iBeacon is not a piece of hardware. It is a BLE profile that is loaded onto a piece of hardware. This profile makes the Beacon an iBeacon.
  7. There are many Beacon vendors who offer various capabilities such as: BlueCats; BlueSense; Gelo; Kontakt.io; Glimworm; Sensorberg; Sonic Notify; beaconstac; mibeacon (Mubaloo); estimote; Gimbal (Qualcomm); Apple; and Google, etc. 

Beacon vendors offer various difference offerings such as:

  • hardware
  • proprietary BLE Beacon profiles
  • support for popular profiles
  • remote Beacon management
  • analytics
  • associated content management
  • marketing campaigns
  • software version management
  • profile switching
  • client side SDKs
  • professional support services
Most do not offer the whole solution, and so it was interesting to see Apple and then Google throw their hat into the ring. Most people are still really excited about Apple’s iBeacons, but they look like they will become a closed eco-system which could possibly even include being able to be physically undetectable to non-Apple hardware.  Today Beacon vendors are just not allowed to provide library based support for iBeacons on Android hardware (http://beekn.net/2014/07/ibeacon-for-android/).

At the start of 2015 Google created a new form of Beacon called UriBeacon (http://uribeacon.io/) which was able to actually advertise a URL pointing to a website or a URL that could be processed locally. This was in stark contrast to all the previous forms of Beacon which could only advertise their identity (UUID, minor, major). UriBeacons also promised to be cheaper and easier to configure, which was largely down to their more limited use case of just being used to advertise a URL/URI. The killer concept, however, was that of The Physical Web. The Physical Web is an approach to unleash the core superpower of the web: interaction on demand. People should be able to walk up to any smart device and not have to download an app first. A small pre-installed App (like the Web Browser or something Operating System level) on the phone scans for URLs that are nearby. Google previously used the UriBeacon format to find nearby URLs without requiring any centralized registrar.

This was a major breakthrough because having to download an App for each Beacon vendor completely breaks the organic, intelligent, evolutionary Smart City model. Notice that I used the words ‘without having to download an App’. You still need an App to process the UriBeacons, however, this can be built into the Web Browser (Chrome offers this for iOS) or the Operating System (Android M offers this). The following vendors offer UriBeacons: Blesh; BKON; iBliO; KST; and twocanoes, etc.  

Recently Google updated their single-case UriBeacon specification to that of Eddystone. Eddystone is an open-source cross-platform beacon solution that supports broadcasting of UUID, URL, EIDs and Telemetry data. Previously Beacons had only supported UUID until UriBeacons offered the single option of URL advertisement. Eddystone offers an additional two frame types: Ephemeral ID is an ID which changes frequently and is only available to an authorised app; Telemetry is data about the beacon or attached sensors: e.g. battery life, temperature, humidity. Unlike iBeacons, which must be approved by Apple, anyone can make an Eddystone-compatible beacon. Current beacon manufacturers include: Estimote; Kontakt; and Radius Networks, etc.

The Eddystone-URL frame broadcasts a URL using a compressed encoding format in order to fit more within the limited advertisement packet. Once decoded, the URL can be used by any client with access to the internet. For example, if an Eddystone-URL beacon were to broadcast A URL then any client that received this packet and with an Internet connection could choose to visit that URL (probably over WiFi). You can use an App to manage that experience and either take you directly to the URL or process a URI internally to perform some other function without network connectivity. Better still The Physical Web initiative has moved away from UriBeacon to the open initiative of Eddystone.

Now one thing to realise is that Eddystone may support iOS but that obviously does not include integration with CoreLocation as per iBeacons. Eddystone beacons only interact with iOS devices via CoreBluetooth which means you have more work to do. Likewise, on Android M there are a whole bunch of new APIs and those will not be available on iOS.

  • The Nearby API makes it easy for apps to find and communicate with beacons to get specific information and context. Apparently it uses a combination of Bluetooth, Wi-Fi, and inaudible sound.
  • Nearby provides a proximity API called Nearby Messages in which iOS devices, Android devices and Beacons can discover, communicate and share data/content with each other.
  • The Proximity Beacon API helps developers to manage data and content associated with Beacons. Once Beacons are registered with Google's Proximity Beacon API then we can map data and content that can be pulled from the Cloud using a REST interface. This makes Content Management Solutions much easier and gives us the ability to dynamically map content available to Beacons. This functionality will most probably be supported in the Physical Web through Web Browsers clients that support this API through JavaScript.  
  • Place Picker is an extension of Places API that can show Beacons in your immediate vicinity. The Places API is also able to read and write Beacon positioning information (GPS coordinates, indoor floor level, etc.) from/to the Google Places database using a unique Place ID based around the Beacon UUID and then have the Beacons navigable though Google Maps. This would provide a much better retail solution where customers could literally Google “Hair Shampoo” inside a Boots store and be taken directly to the product using indoor positioning.

I am sure you have many questions such as, can a Beacon run iBeacon and Eddystone simultaneously. At the moment the Beacon vendors offer the ability to support both profiles but not simultaneously. This is apparently due to battery usage. Most vendors do seem to support simultaneous broadcast of UUID, URL and Telemetrics within Eddystone though. For any other questions then here is a fantastic Q&A on Eddystone from Kontakt.io (http://kontakt.io/blog/eddystone-faq/).

The Physical Web has now moved away from UriBeacon and onto Eddystone-URL frames. A few months ago, Chrome for iOS added a Today widget. The new Chrome for iOS integrates the Physical Web into the Chrome Today widget, enabling users to access an on-demand list of web content that is relevant to their surroundings. The Physical Web displays content that is broadcasted using Eddystone-URL format. You can add your content to the Physical Web by simply configuring a beacon that supports Eddystone-URL to transmit your URL of choice. When users who have enabled the Physical Web open the Today view, the Chrome widget scans for broadcasted URLs and displays these results, using estimated proximity of the beacons to rank the content.

The Physical Web also support finding URLs through Wifi using mDNS (and uPnP). The multicast Domain Name System (mDNS) resolves host names to IP addresses within small networks that do not include a local name server. It is a zero-configuration service, using essentially the same programming interfaces, packet formats and operating semantics as DNS. While designed by Stuart Cheshire to be stand-alone capable, it can work in concert with DNS servers. The mDNS protocol is implemented by the Apple Bonjour and by Linux nss-mdns services. In other words rather than waiting for your client to discover a Beacon advertising a UUID or URL then you could actually start searching for local services hosted on Beacons using a multicast form of DNS. Beacons are actually more powerful than most people realise and can often run micro-services on them. In fact if we think about it then Beacon based services are the ultimate form of a micro-service architecture. Brillo is an upcoming Android-based operating system for IoT devices and this lightweight OS could theoretically run on a Beacon which would enable a portable way of deploying a Beacon based micro-service architecture.

When you woke up this morning did you honestly think that Beacons were that powerful?

************************************************************************
Kevin Benedict
Writer, Speaker, Analyst and World Traveler
View my profile on LinkedIn
Follow me on Twitter @krbenedict
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies

***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.

Featured Post

Leadership Advice from a Futurist - A Reading

Leadership is hard.  So for all the leaders and want-to-be leaders out there, here is some advice that I hope you will find useful. ***...