What specifies a web application as a Progressive Web App (PWA)

Progressive Web Apps’ (PWAs) biggest draw is in their ability to adapt and provide the best overall mobile web experience regardless of what screen they’re being viewed on or what browser they’re being run on. PWAs drive performance and load similar to a regular web page, but offer additional native device functionality such as working offline, serving notifications, launching a camera, etc. For more background and further explanation on what PWAs truly are, check out the previously published article, What’s all the hype with Progressive Web Apps (PWAs).  

This second installment in the PWA series will explore the browser technologies that make PWAs possible, including what specifies a web application as a PWA. 

PWA Capabilities and Specifications

PWAs themselves have various capabilities. This includes (but is not limited to) geolocation, sensor access (magnetometer, accelerometers, gyroscope), camera access, audio output, on-device payment, web-based notifications, background synchronization, and more. These APIsand services are exposed through the particular browser that are supported (more on that later).

It’s important to note that making use of the previously mentioned capabilities in a web app doesn’t immediately make it a PWA. Various automation tools will provide auditing capabilities for PWAs, which provides somewhat of a standardized expectation for what rules/practices PWAs should really adhere to. The metrics evaluated by these tools are set by a baseline of influencers in these technologies. Google’s development documentation describes the various technologies sought after in the industry to declare a web application as a PWA.

For PWA classification, a web application must:

• Originate from a Secure Origin. Served over TLS and green padlock displays (no active mixed content).
• Load while offline (even if only a custom offline page). By implication, this means that PWAs require Service Workers.Service Workers being the current technology of implementation as there is no current alternative to the approach.
• Reference a Web Application Manifest with at least the following properties: name short_name start_url display with a value of standalone or fullscreen An icon at least 144×144 large in png format.

In addition to the feature set PWA’s possess, there is also far greater simplicity in their distribution/consumption model. As PWAs are distributed as static files, they are easy to serve by means of a light-weight webserver which clients can download the necessary assets for through their browser. Another means of distribution is through a standard CMS/CDN- simply to host the built static assets required for the PWA. Therefore, having a PWA doesn’t necessarily mean the CMS you’re using is now obsolete, but it opens up opportunities to new capabilities that a CDN may provide such as content caching, security features, and more. 

When thinking about the means of distribution for PWAs, its ease doesn’t come to surface until the actual use cases are applied. From the ecommerce perspective, how many times have you ventured into a store outside your home country to be presented with an appealing banner to download an app to aid you with all your enhanced in-store shopping experience? You happily search for this app in your phone’s App Store, only to find out that it’s not available for download because you have an account dedicated to a country which doesn’t distribute this app. You’re left displeased, and you get the feeling that you’re now left out of this opportunity to try out a wonderful shopping experience simply because the content you want to download has been region locked by your platform. 

Now imagine if this application was available as a PWA. You’ll simply be able to open up your web browser on your mobile device, navigate to the store’s website, and be presented with the same rich experience that you would expect from the native application. You’re now able to continue that incredible shopping experience that you were hoping for from the start.
Browser FeaturesCertain browsers offer more support and capabilities for PWAs compared to others. This is most evident in the current mobile web application world between iOS Safari and Android Chrome mobile browsers.  iOS does not possess the richer capabilities of PWAs such as web-based push notifications, bluetooth access, background synchronization, geofencing, and more. 

However, as of the time of writing this article, Apple has released iOS 12.2 beta, which adds additional capabilities such as native support for gesture navigation, state management between apps, level 1 web share features, external link handling (useful for OAuth flows), and plenty more. This doesn’t put iOS on par with Android yet in term’s of PWA support. However, it does bring truth to the fact that PWAs are becoming the way of the future for web applications and are continuing further adoption to platforms.

As continued adoption of PWAs increase, we should see more native features of platform operating systems become exposed through web browser APIs. 

If curious on what capabilities a browser may have, it’s encouraged to visit https://whatwebcando.today/, and run a scan on a current browser in use. It may be surprising to see some features limited to native applications have made their way to the web.  

These modern practices encourage growth in the mobile industry and demonstrate how both consumer and developer requirements have shaped mobile application development practices into adoptable front-end models.

The post What specifies a web application as a Progressive Web App (PWA) appeared first on Get Elastic Ecommerce Blog.

from
https://www.getelastic.com/what-specifies-a-web-application-as-a-progressive-web-app-pwa

Pop-up Shop-up with Mare Weiss

Security & Android apps: why automated testing matters

Closing the mobile conversion gap with PWAs

According to Mobify’s 2018 Q4 Mobile Commerce Insights Report, mobile overall, showed continued growth with purchases made between Black Friday and Christmas. Somewhat surprising from Mobify’s findings was that the most frequent traffic source for mobile was email. According to Forbes, “retailers sent 3.5 billion emails on Black Friday, and another 4.1 billion on Cyber Monday – significant increases over the 3 billion and 3.3 billion, respectively, sent in 2017.” 

Closing the gap

Although mobile is edging out other devices in terms of traffic and use, it is still possessing a challenge for retailers in terms of lower conversion rates when compared to desktop. As Mobify reports, before an ecommerce retailer can fully close the conversion rate gap, businesses need to investigate this compound metric further by looking at traffic AND transactions.

Even though transactions are increasing, if they are not increasing as quickly as traffic, the conversion rate goes down. [Transactions / Traffic = Conversion] This can be a bit misleading in terms of mobile commerce success. For this reason, Mobify notes that “the conversion rate on its own is not a good metric to evaluate your overall performance. Because it’s a compound metric, interpreting conversion rate requires taking the extra step of understanding the movement of the variables (traffic and transactions) that comprise it.”

A step towards fully closing this gap means looking at the customer-facing experience offered and the potential to improve. With the adoption of Progressive Web Apps (PWA), retailers can offer better, if not the best way to deliver improved, faster customer experiences. PWAs load similar to a regular web page, but offer additional native device functionality such as working offline, serving notifications, launching a camera, etc. The number one benefit of PWAs vs. non-PWA sites (like on desktop), is speed – as they significantly reduce the time it takes for a consumer to complete crucial tasks such as finding an item or completing the path to purchase. The faster a shopper is able to complete a purchase, the more likely they are to buy. Google research found that as page load time increases from one second to ten, the probability of bouncing increases 123%. PWAs offer an expedited experience over native apps, while offering all the same features. 

Debenhams, a British department store ventured into the world of PWAs and saw double-digit percentage point growth in mobile conversions. And, their “commuter browsing” turned into “commuter shopping.” 

Mobify notes the three approaches to delivering commerce PWAs: commerce-led, experience-led and API-led. However, when looking to implement a customer-first strategy, an API-led approach is really the way to go. 

The API-driven approach to PWAs 

To define the API-driven approach to delivering commerce PWAs, these are in fact when ecommerce features/services are exposed through APIs and consumed through a front-end which has the ability to invoke those APIs to retrieve and interact with whatever data is required for the ecommerce flows exposed by that API. 

There are many benefits to implementing this methodology. Control of the ecommerce back-end through an API creates a number of services that are no longer limited by the front-end consuming them. The same API which drives a front-end touchpoint for a PWA storefront can be used for additional touchpoints such as IoT touchpoints, POS machines and customer interactive chatbots. This additionally becomes a great benefit to the PWA storefront as this PWA may live independently of the ecommerce back-end services and be built around consuming these back-end services without any concerns of impacting behavior as additional APIs are exposed. It becomes the sole decision of the front-end PWA implementation to consume additional services which have been exposed by the API in the future case, and thus simplifies adoption of those services. 

Best practices to accomplishing this may vary by organization and business case. Some general cases include usages of REST or Graph QL APIs to expose ecommerce business logic in a meaningful representation, while some continue to make use of legacy technologies such as SOAP.

The post Closing the mobile conversion gap with PWAs appeared first on Get Elastic Ecommerce Blog.

from
https://www.getelastic.com/closing-the-mobile-conversion-gap-with-progressive-web-apps

Is Artificial Intelligence (AI) enough for ecommerce fraud management?

Fighting fraud isn’t easy. It’s time-consuming, it’s challenging, and it’s expensive. Taking an artificial intelligence (AI) approach seems like a better strategy.

After all, AI can quickly analyze extensive amounts of customer data to identify emerging fraud patterns. By incorporating this insight into fraud risk scoring algorithms in near real-time, businesses can lower their risk of falling victim to fraud.

AI Advantages 

Where AI excels is its ability to quickly review incoming transactions. The algorithms can calculate fraud risk scores far faster than manual reviewers ever could, which means for businesses that must deal with a high volume of incoming orders, AI can be the difference between speedy approvals and disgruntled customers.

There’s a cost aspect to this as well. Because this initial review of incoming orders can be automated, businesses don’t need to spend valuable (read: expensive) man-hours reviewing each individual order. This can tremendously cut down operating costs, and it enables organizations to focus their analysts’ attention only on those specific orders that require further investigation.

And finally, AI can be very helpful at spotting obscure patterns in fraud that might not be readily apparent to the average reviewer. This is particularly true if businesses have a good amount of high-quality, validated information on past orders.

However, for all the benefits AI-based fraud solutions can offer, the technology does have some limitations when it comes to evaluating credit card transactions.

AI-Based Shortcomings 

That said, there are several circumstances where AI alone will not be sufficient to manage ecommerce fraud and may even prevent businesses from maximizing sales.

1. Auto-Declining Orders

AI does a great job of auto-approving good orders and flagging potentially fraudulent orders. But AI should never be trusted on its own to auto-decline orders. Statistics show false declines – that is, accidentally declining orders that are actually legitimate – is a very high, very real risk for ecommerce merchants.

By all means, AI should be used to flag orders that might be fraudulent; but they always need an additional review before declining them. False declines cost businesses 13 times more than credit card fraud. Organziaitons need to validate every decline decision, to be confident they’re not inadvertently ruining a relationship with a perfectly good customer simply because they’re trying to ship a gift to a different address (which is a common reason for false declines).

2. Lack of High-Quality Data

AI is only as good as the data it receives. If product is brand new or highly unique, AI-based fraud solution may not have the data it needs to make accurate approval decisions. In these cases, an AI solution may end up declining orders that are good – and the AI algorithm may inadvertently become more conservative as time goes one and decline more and more future orders.

For these types of products, flexibility will be key to ensuring merchants are maximizing sales without also increasing chargebacks. This may require turning off (or loosening the standards) for the AI solution while they closely monitor actual sales and fraud trends. Businesses should study their potential risk, and modify their fraud strategy based on their learnings.

3. Troubles with Fraud Filters

At the core of many AI solutions lies the ubiquitous fraud filter. Fraud filters use rules to evaluate incoming transactions; if a transaction meets certain criteria, the transaction will be either flagged for review or auto-declined.

The problem, therefore, is whether the fraud filters are set up properly. It’s tempting to think that if one fraud filter catches some fraud, more fraud filters will catch even more fraud. Unfortunately, this isn’t always the case. Layering filters incorrectly can result in some rules canceling others out, leaving you as vulnerable as if you had no fraud protection.

Moreover, smart fraudsters know how to “play” the fraud filter game. For example, it’s not terribly difficult for a fraudster to test a system with a series of orders and eventually learn that orders under $1,000 are typically approved, whereas orders over $1,000 are typically reviewed. Once they learn this, they’ll flood the system with batches of orders of $999 that enable them to fly under the fraud filters’ radar, completely undetected.

A Winning Approach = AI + Human

Perhaps the smartest approach is to combine the best of both worlds: Businesses should implement a comprehensive fraud management solution that combines AI technology with expert fraud analysis.

This multilayered approach enables organziations to harness all the efficiency benefits of AI, so they don’t have to slow down the order approval process – and it also safeguards businesses against the risk of accidentally auto-declining orders from their best customers. In this type of approach, AI might be used to auto-approve good orders and flag orders that are suspicious, while a human analyst that understands the nuances of fraud can manually review and either validate the order or confirm the decline decision.

The post Is Artificial Intelligence (AI) enough for ecommerce fraud management? appeared first on Get Elastic Ecommerce Blog.

from
https://www.getelastic.com/is-artificial-intelligence-ai-enough-for-ecommerce-fraud-management

Behind the scenes: a look at the upcoming Get Elastic video interview with Carnival Corporation

How to stop wasting resources to improve the customer experience