11436 SSO

Field Notes: E-tail, Data, and the “Smoosh”

Mar 07, 2014

[[{"type":"media","view_mode":"media_original","fid":"19736","attributes":{"alt":"","class":"media-image","height":"200","style":"width: 300px; height: 200px; margin: 11px 10px; float: left;","typeof":"foaf:Image","width":"300"}}]]Apigee counts many retail and ecommerce companies as customers, so we have a great vantage point for keeping tabs on “e-tail”—the continued “smoosh” of retail and ecommerce. Technology constantly revolutionizes this space, and companies are working hard to use it in pioneering ways.

I’ve learned a lot about these advances during my visits with our retail customers; these insights are imperative for Apigee, because they help ensure ongoing thought leadership and aid us in building and offering the most relevant products and services possible.

The new technologies employed by e-tailers are starting to have very real impact on anyone who buys anything at all. It’s worth understanding in some detail, and it’s particularly important to have a sense of the scope of and the important role that a variety of data plays in creating the kinds of experiences that retail customers have grown to expect.

The "smoosh"

First, let’s talk about that “smoosh.” Great companies make sure they thoroughly think through the “outside-in” customer experience. The experience they’re all trying to get to right now in e-tail is something called multi-channel, which we can define as the various avenues to interact with each customer, with harmonious switching across these channels.

One such channel could be a retail store experience, so the scenario might run something like this: A customer starts shopping on a home computer, using an open login standard such as OpenID, then switches to a mobile phone while heading into a small-footprint retail site. The business knows it’s the same customer all the way along, whether he or she is on the web or using mobile en route or mobile in the store, and is formulating highly-targeted relevant offers. These could include special discounts and complementary merchandise based on previous purchases and items in a shopping cart, and where the customer is physically.

There are all kinds of possible embellishments to this story: detection and identification of the customer on premises, based on mobile device; push notification of special  offers to that device via a Bluetooth “beacon” (think of beacons more or less as cell towers, but using a short-distance communication protocol); back-end aggregated analytics; flashmob-style orchestrated group actions; likely purchasing preferences based on insights derived from social media; displays of garments that will fit in the wardrobe based on knowledge of past purchases; inter-company alliance partnerships; and lead sharing.

The fluidity of e-tail

The basic concept is just the fluidity and continuity of user experience across many devices, with modern, specific identity relevance from the business backend, and from the cloud—that is, the Internet, which is more and more a federation of private, semi-private, and public clouds. Businesses are excited because the knowledge of the user, and the multiple ways to connect with that user, brings up all kinds of opportunities for enriching the relationship with the customer, and creating satisfaction in all kinds of ways, including economic (bargains), intellectual (facts and information), and emotional (new branding opportunities; community, and the thrill of a good deal).

One could argue whether this is e-commerce or retail, but the fact is both forms of commerce are converging, and “e-tail” is arguably the best appellation  for this.

The flow of data

Name and quality of user experience aside, the most important aspect of all this is that it implies a host of critical requirements for data accessibility and immediacy. If we look at some of the data structures implied in the general use case, they might include:

User identity and context

  • Single sign-on identity (e.g. OpenID authentication results)
  • Enterprise-scoped identity attributes (e.g. customer’s cell phone number, voluntarily stored previously)
  • Attributes fed from identity federation service
  • Beacon-determined location
  • Social media feeds, scrapes, and abstractions (#tan Burberry coat; #browsing 70 inchers; insights and abstractions from communities and social sites, for example)
  • Photos (it may be creepy but it’s technically and economically feasible now for a store security camera to automatically recognize you)

Transactional data

  • Catalog items and metadata
  • Shopping cart (portable across devices)

Inventory and historic data

  • Stock availability
  • Targeted offers (usually a result of predictive analytics based on personalization and business context. Something like: ”As far as we know Jack hasn’t bought a TV in 5 years, but rents movies at our kiosk a lot, and we have an overstock of 50 sets, and we gotta move them color TVs”)

Obviously, there are many different types of possible data. These data requirements in turn mean APIs, and this is why we see all our commerce-sector customers pushing API programs as fast as they possibly can. They need APIs, and not merely as a means of getting ahead, for advantage. In many cases, it’s a matter of survival.

But why APIs? They need APIs so as to shape, control, normalize, and transform the data. The chances of all the above data types being in a uniform format, or even in a single repository, are near zero, so there must be sofware control over the marshaling of it, to ensure a consistent programming model to access to ensure freshness, among other reasons. For more reading on how apps and APIs are the new channels for retailers, check out the free Apigee eBook "Are You Where Your Customers Are? Retail 3.0: Digital Transformation."

In the next post in this series, we’ll look at the API architectures that typically implement APIs in the retail world.


Scaling Microservices