The idea of obtaining conversions for features came up over the past two days over in the product manger community out on Twitter. The tweet was a mention, like a keyword. This article will explain the underlying approach to the idea that ever features if it is used converts and how this translates into actionable feedback for product managers, or developers. Decisions about features don't have to be opinion-based. These decisions can be made on the basis of hard data.
The Web
The web provides us with a familiar place to start thinking about conversions.
We enter a url into our browser. The url constitutes a request sent to a specific server. The server responds by serving us a web page. The server also writes an entry into its server log for every page it serves. Marketers use web analytics to analyze the click stream and optimize the web pages. This in turn optimizes the revenues generated by ecommerce sites or page views by content pages. The server log provides a basis for actionable feedback.
We can add the search engine components.
In this figure of web pages and their associated search engine and keyword components, I've numbered the feedback opportunities: 1) the web pages, 2) page rank, and 3) keyword research. Keyword research lets you figure out what labels to use for your controls. The keywords you research would originate from the terminology you use to describe and extend your underlying conceptualization. Keyword research reflects the terminology usage of the entire web, rather than your specific market segments. Conversion testing will enable you to validate those labels within the context of your particular market.
We will come back to the web later in this article.
Conversion
Conversion is a term that originates in marketing, more specifically, direct marketing. The web, when used for ecommerce, is a form of direct marketing.
Web developers deal with servers in terms of requests and responses. You request a web page, and the server responds by serving another web page.
Offline, you might get someone's business card. A business card usually has a tagline telling your what product or service is being offered. That offer is embedded in the text of the tagline. That tagline is conversion text. The business card also provides a list of contact channels and addresses. The action underlying a business card is making that contact. You won't see conversion text like "For more info, call John, the guy's whose business card this happens to be. The tagline relies on context to deliver an implied call to action. Other documents would be more explicit. So you dial that phone number, or send that email or SMS message. You took the implied action.
A response channel can be complex like middleware. It involves response devices like telephones and protocols as complex as those used on the web, or in an application.
The person answering the phone provides you with content. And, if they know what they are doing, they make another offer. "Hey, we have a sale on Wednesday. Why don't you come down to the store then?." Always be closing. But, the point is that every touchpoint, web page, or communications event should make an offer.--every last one.
When marketers describe this, they use the marketing terminology of
offer, action, response, and fulfillment. Conversion is the goal of the offer. When you take that action, you have been converted. Conversions move you towards the sales funnel, something sales expects marketing to be doing. This is irrespective of "lead generation." The goal is conversion.
An offer is not the text describing the offer. The offer is just the existence and availability of the good or service being offered. Each offer is embodied in some conversion text. That conversion text is the content making the offer. So the sequence really goes from conversion text to action to response to fulfillment. Different people would respond to different conversion text.
Each offer leads to a fulfillment. Offers are chained. These chains are called fulfillment chains. It is this chain of offers, conversion, and fulfillments that lead prospects through a qualifying process to the sales funnel. This the pre-sale fulfillment chain.
There is a post-sale fulfillment chain as well most of which embodying your user communications collection, and that single piece of marcom announcing the availability of your upgrade. You can also use your fulfillment chain to discover things about the enactors. You can use it to separate out your geeks from your economic buyers. Some of those documents in your fulfillment chain would be surveys. Get them started with a registration requiring only an email address and zip code. You might want to capture email permission. Then, in short surveys add info over time.
Documents
A fulfillment is a set of contexts and requirements for a "functional" document. This isn't about brand.
Now, putting this document in the context of a fulfillment, we add the response.
And, we add fulfillment.
Notice that a fulfillment is another document. And, that gives us a view of enactment chain.
Keep in mind that on a web page, the success of every conversion is critical to the success of the website. A visitor is trying to get something done. They are performing one or more tasks. Users of applications likewise, perform tasks. This parallelism is key.
The server log contains entries for each page used in the tasks performed by the users. Given that a population of users is being served in the same period of time, maintaining session is important. It is that session maintenance that lets you see each user's path through the website. A user task might be hierarchically composed of other tasks. Sending a letter involves writing a letter, creating a stamped envelope, putting the letter in the envelope, and posting it. Each of these are simpler tasks comprising the composite task.
In the C++ period, programmers didn't do a task analyses. If they got done at all, the technical writer or instructional designer or trainer did them. With Agile, user stories give you a task analysis. The writer wrote up the tasks as preconditions, steps, the result for each step, and the result for each task. The instructional designer builds examples with data of each of those tasks. Instruction and learning are exit barriers--customer loyalty through expertise development happens. Customer support likewise contributes here. This content is linked. Curriculums look like fulfillment chains.
Back to the Web
Here is the first figure in the previous section, Documents, which we will build on in this section.
Now, we will take this print document to the web.
Here we are looking at web-based functionality. If you are using html to create your user interface, controls occur within a form. Controls have one or more label associated with them. Grouping labels contextualize the labels of the controls contained in the group. The document could be a dialog or message box. The context of expectations doesn't show up on the interface, but is put there in the minds of the users. Use trains. Use tells. Use demonstrates results. Use gives rise to a user conceptual model. They don't read the documentation, particularly geeks. They use, troubleshoot, build their conceptual model, and their understanding anchors their expectations. You have to meet those expectations.
A form usually contains many controls. A web page can contain more than one form.
Now, we can go back to the web context and see what goes on.
Here I've labeled the web context with the model-view-controller pattern. The view and controller live on the client. The model lives on the backend servers that deliver the functionality. I've ignored any content servers in this figure. Notice that performing actions using controls constitute conversions. Those conversions end up in the server log where they can be analyzed. The UI can be modified on the basis of the feedback provided by the web analytics.
Since the users have an account, they would log in. The web analytics can help you tune your application to specific market segments once you get those populations to log in. There are other ways of tying specific users to sessions, but at some point registration would be required. They already do this to register the software relative to their licenses. The purchasing and administration of licenses is a good thing to move to SaaS just ahead of your entry into the late market. Users of desktop applications should be trained towards SaaS.
Next, I've added the fulfillment chain contexts to the figure.
Now, you can see that meeting the user's expectations becomes the offer. When those expectations are not met, users abandon the site. That abandonment would show up in the server log analysis.
Conclusion
The discussion here was based on HTML pages. The scheme would work for AJAX as well. It could be made to work in desktop application, but privacy issues would require user permission. SaaS applications traffic in the information, so there is no assumption of privacy beyond data value privacy, and this only if encryption part of the offer.
As for programmers using this feedback, you have to pay attention to the market segmentation. Keyword research is very general. So any labels would need to be tested on web pages where web analytics can tell you what works.
Direct and web marketers A/B test just about everything. They don't make assumptions about what works. They test. They test this page against a pool of slightly different pages. The one with the best scores win, scores based on web analytics. Programmers could A/B test. They might test their UI page, or they might test completely different implementations if they use an evolutionary approach where several teams work simultaneously on their version, and the best solution is selected to ship. Testing can happen on various scales. You don't have to accept assumptions, rules of thumb that may not be current, or get involved in power plays. Just boil it down to being data driven.
Shoppers give up. Shoppers get slowed down. Shoppers get lost. So do users. It's all right there in the server log. Web analytics can tell you what needs to be improved.
Leave a comment. Thanks.