B2C internet software
I recently opined that, especially for cutting-edge internet businesses, analytic applications were not a realistic option; rather, analytic application subsystems are the most you can currently expect. Erin Griffith further observed that the problem isn’t just confined to analytics:
“We didn’t need 90 percent of the stuff they were offering, and when we told them what we did need — integration with social, curation tools, individual boutiques and analytics — they had nothing”
… a suitable solution to merge his editorial staff’s output with his separate site for selling tickets to events and goods … was not available, so had to build his own hybrid publishing and commerce platform. Likewise, Birchbox had to build a custom backend so that it could include videos and editorial content alongside its e-commerce site.
… it’s DIY or die.
With that as background, let’s consider why building business-to-consumer internet software is so complicated.
I’d suggest that a consumer website starts with four major conceptual parts:
- Content serving.
- There are many, many kinds of content …
- … and numerous web and/or mobile ways of consuming them.
- Many businesses want to have a “Wow” factor, and this is where they look first for that differentiation.
- Performance also has to be great.
- Navigation/personalization engine(s).
- You need multiple styles of navigation, including recommendations and search.
- Recommendation is still a partly-unsolved AI problem.
- So is search.
- In particular, the Endeca/Mercado/Inquira generation of hybrid search/recommendation companies didn’t wind up thriving. (Mercado went down in an asset buy; Endeca and Inquira were absorbed by Oracle.)
- User/state tracking.
- On-site (or otherwise in-system) user interaction tracking needs to capture everything.
- You may rely on external information as well — the recommendation engine guzzles all the fuel it can.
- Transaction engine.
- Complications include payments, fraud, and general schema flexibility.
- This is the part that’s closest to being solved.
- Pricing on the payments part can be confiscatory.
Requirements may include great uptime, great response time, and rapid (re)development cycles, along with dynamic schemas for all four parts.
No one application — or “application” — vendor will ever meet these needs, across most or all segments of the market. Differences are too great in:
- The content-serving challenges (very different in different segments).
- The analytic challenges (ditto).
- The business’ IT capabilities (anywhere from “awesome” all the way down to “none whatsoever”).
So for starters I’d say:
- The market needs complete systems, suitable for small businesses, which allow and require no more customization than may be entrusted to a freelance web designer.
- Also needed will be building blocks from which sophisticated IT organizations can assemble groundbreaking consumer experiences, …
- … plus developer tools to provide the scaffolding for all that to be pulled together.
- Both those extremes will be offered in a variety of vertical flavors.
When I refer to “building blocks”, my thought is that we know a good part of the modularity model for the foreseeable future:
- Web pages link to other web pages.
- They have elements that can be assembled — and tested! — fairly independently of each other.
- Similar but simpler things happen on mobile devices with small screens.
Further modularity is suggested by the complexities of rendering or streaming different kinds of content.
And finally I note:
- These applications will in most cases wind up being hosted …
- … but will need to be portable among different hosting providers, for two reasons:
- Security blanket for companies betting their whole businesses on them.
- Mix-and-match of subsystems from different vendors.
And that’s where I’ll leave it for now. Truth be told, I haven’t yet figured out exactly which subcategories of “applications for B2C companies” I think will or won’t be big.
Related link
- The essence of an application (June, 2011)
Comments
Leave a Reply