Conversion and Acquisition

In the world of ecommerce, there are two terms - conversion¹ and acquisition² - that, in general, are bandied about with little regard for what they mean. Of course, part of the problem is that their meaning is partly contextual, but even so, words have meaning and when you're getting paid to think, part of that is thinking about what we mean and how we're communicating.

"Why", you may ask, "is this discussion important" - and here's the reason. The two terms have very different meanings and without understanding them you cannot be as successful as you would otherwise, because in most cases the two measures have an inverse relationship.

Wait...I sense a great disturbance. It's almost as if the universe cried out "that cannot be so".

When people are buying online - not shopping, but buying - interrupting them will negatively affect whether or not they complete the process, and there are times that even selling will interfere with a purchase. People who have been in the ecommerce game for a while should already recognize this³ but not all do, as is evidenced by the number of sites cross-sell or up-sell or that require a customer to create an account before (or during) paying for their purchase - sites that don't appear match the priorities of the business.

There are a number of reasons that you, as a merchant, may want a customer's information - most of them legitimate; for example, you will need billing information to complete payment and shipping information to fulfill the order (in most cases). Your general need for information, however, ends there - aside from perhaps slightly more information regarding the individual(s) purchasing and receiving the goods to verify that the transaction conforms to laws those which those individuals are subject.

I do not question whether or not it will be in the customer's best interest to create an account with you - you can store billing information as well as shipping information and purchase history - all of which is, clearly, a benefit to the customer. However, the data is clear - forcing a potential customer to create an account will lower your conversion rate - and if you are using a payment gateway⁴, if they force your customer to create an account - even if you do not - it will lower your conversion rate.

So, how do you 'fix' this problem - after all, you want satisfied, repeat customers - that's the greatest return on your marketing investment, right? The answer is really quite simple. Make the value proposition when the user is not distracted by purchasing. Ask for their email address during checkout by offering to keep them updated on the status of their purchase (if it's a purchase that needs to be fulfilled) or offering to check to make sure they're satisfied with their purchase. Of course the trick here is to actually follow up - not doing so will be counter-productive at best.

An email follow-up approach has the additional benefit of reduced cost. Consider this - if the customer does not want to give you their email address they likely do not anticipate being a return customer. Their intention clears you of securing and storing personal information as well as spending marketing funds to retain or re-engage customers who will not be bringing you repeat business.

The solution is simple and effective, allowing you to focus your energies toward making your customers satisfied rather than acquired accounts...and isn't that what really drives your business - satisfied customers?

Notes: links open in a new window

1. Conversion is the measure of those potential sales that become actual sales. For example, if you have 10 customers with items in their cart and 9 buy their items and one leaves without purchasing, your conversion rate is 90% (and your abandonment rate is 1%).
2. Acquisition addresses acquiring a customer, without regard to whether the acquisition is either temporary or permanent.
3. If you sell online and don't recognize this, there is a significant chance that either you have selected the wrong indexes as KPIs or you are not performing A/B testing and are not measuring the impact of activities assumed to be beneficial or at least benign.
4. A payment gateway is a service provider that authorizes payments, typically by acting as an intermediary between the merchant and a credit card issuer. Learn more about payment gateways at http://en.wikipedia.org/wiki/Payment_gateway.

Ambition

It's the middle of the year, so that means it's time for semi-annual reviews. Reviews are always a little difficult for me - in part because I was raised to believe that it was morally wrong to, as the saying goes, blow your own trumpet. This belief is so ingrained that in the past I've had difficulty with writing a CV or even effectively answering questions regarding my previous accomplishments during an interview for a position.

There's more here than just my ingrained beliefs, however; more that relates to ambition and how others perceive it. More that we in the corporate world refuse to discuss because we all know what the words and concepts mean. We are so convinced we know the meaning that we really need not think about the words or the concepts they convey. However, I wonder if perhaps it is that we don't really understand ambition, even though we think we know the definition.^[1]

As a case-in-point, I recently received a message from a former coworker - I'll call him Mr. Foo - that I'm going to paraphrase here, removing references that will identify who it was or which employer we shared in common. All edits will be enclosed in *[ and ]* to identify them.

When I was at *[our common employer]*, I was full of ambition and could not for the life of me figure out why you didn't put a ton of effort into sharing your *[tools]* with the *[rest of the employees there]* in a more formal fashion than just have them 755^[2] in your home dir.
... 

*[It]* might sound kind of weird, but in this weird way that chosen inaction on your part really stuck with me and I've always respected and always will respect you as an awesome developer and wise person in general...and time to time I think "well, Robert had this awesome stuff and didn't really share it or align himself with movement x y or z". There's wisdom in your actions, I think, and its taken me a while to come around to understanding that.

Now, I might have shared this message because this person referred to me as "an awesome developer" (and yes, I appreciate "awesome developer" more than "wise person" - it's better geek cred) and it's not really blowing my own trumpet because Mr. Foo has done it for me - that sort of ego stroking always feels good, but that's really not why I share it.

My thought today is this - most of us - and by most I mean nearly all, have become convinced that ambition and self-promotion are inseparable. They are not. Few of us have difficulty with people who are ambitious - at least to a small degree; however, more than a few have difficulty with those eager for self-promotion - people who, as they say in the western US are "all hat and no cattle"^[3]. While ambition is a necessary condition for self-promotion, it is not a sufficient condition.

My experience of the cycle of self-promotion rampant in corporate culture has been one that has shown it to be one of the most emotionally damaging issues confronting humanity. It is a vampiric greed that drains the soul of a person, because just as for the gun-fighter of the old west, there is always someone faster or willing to cheat just a little, and in the end you're just as dead.

In honesty, I created the tools Mr Foo references to make work easier - for me, sure, but for anyone who used them. I promoted the tools (not myself as author) on several occasions as something that could help resolve a problem but if others didn't use them I wasn't offended - I decided to not be bothered by the action of others.

That is not to say there aren't consequences for avoiding self-promotion. There are. It would be nice if the world - or our little part of it - were the meritocracy we teach our children it is - one where management paid less attention to self-promotion than work. Unfortunately, life is not nice - nor is the corporate world. If you're going to avoid self-promotion - the grasping greed of blind ambition - be prepared to get punched in the face, hard. People around you will not understand, and will likely criticize, your lack of ambition. Of course what they really mean is that you don't share their goals, but that will not be how it is put forward - this isn't a cooperative game with a win-win outcome, this is a bare-knuckle fist fight because people don't like what they don't understand, and people don't understand others who refuse to engage in self-promotion.

The good news, however, is that while self-promotion may not keep you from getting punched in the face, without it you're more likely to keep your soul in the exchange.

To Mr. Foo, if you're reading this and recognize your words, thanks for everything.

Notes:

1. Ambition: (a) an ardent desire for rank, fame, or power; (b) desire to achieve a particular end
2. 755 is the numeric representation of permissions for a file that indicates it is readable and executable by users on the network but only modifiable by the owner
3. Full of big talk, but no action; pretentious

What I learned from writing payment interfaces (Part V)

[Note: Each post in this series will have a sidebar with questions intended to encourage you to think.]

In Part I and Part II we looked at elements, both foundational and code-related, that affect speed. In Part III we started our exploration of velocity by looking at mitigating risk and in Part IV we looked at expanding our app to other locales. In this entry, we'll look at non-specific cognitive overhead.

Cognitive Overhead

• What can you do that is not checking out while checking out?
• Which of the following affect reaction time?
  • Time spent waiting
  • Day of the week
  • Chronological age of the user
  • Time of day
  • Month of the year
  • Complexity of the interaction
• Which is likely to affect conversion more?
  • Adding a message that notifies you to add your address to a prepaid card
  • Using a tabbed design that separates card types
  • Having concise text labels
  • Forced acquisition

Cognitive overhead is the number of logical connections or 'jumps' your brain has to make in order to understand or contextualize the thing you’re looking at, or to put it another way, it’s what your brain has to go through to assign meaning and purpose to what you see - is a significant risk in developing a risk-aware, global app, and is especially significant for a payment interface.

Paying for something can be a very complex – and therefore slow^[1] – interaction, especially for young or older users^[2]. Non-member users often have to ask themselves "do I apply for credit", "which card should I use", "should I use my bank account", "how do I ship this purchase to my sister for her birthday", and "should I create an account". Member users have even more questions than non-members, questions like "why can’t I just make all this information the default so it doesn’t take as long next time".

There are a number of things that can increase cognitive overhead, like handling risk and globalization, especially when those topics are not fully developed or integrated well. On the other hand, there are things we can do to reduce cognitive overhead – things that a payment interface naturally does, like reducing automation and increasing user input by putting the user in the middle of the process, and things that a payment interface may not naturally do, like giving the user real-time feedback – such as a message to let you know you need to add your address to the card profile when using a prepaid card.

To some, suggesting that reducing automation and increasing user input as a way to maintain or increase velocity may sound counter-intuitive; however, for a number of users, especially those who are unfamiliar with your app - the group with the lowest original velocity, the time it takes to make choices is lessened when clear, concise information is present and the users are allowed to make their choices.

Consider, if you will, the case in which automation routes a user to a feature they didn't intend to use - in that case the user must then backtrack to a point where they understand the context before they move forward. This situation becomes even more vexing if automation repeatedly moves them forward in the same direction. In a payment interface, this type of behavior is typically seen in forced acquisition^[3] - a situation in which the user's frustration becomes palpable and is reflected in lower conversion.

Of course it's not only impossible to remove all automation, it's not advisable either. We must determine how to reduce cognitive overhead through other means. One of the simplest ways to reduce cognitive overhead is to simplify not only the process but the design as well. As da Vinci said, "simplicity is the ultimate sophistication".

How we may simplify the design is often relatively clear. Simplifying the process, on the other hand, is seldom clear. How can you easily accomplish this? Think of your process in terms of a story. Is your story simple, with a single plot-line like The Very Hungry Caterpillar, or is it complex, with multiple plots and sub-plots like Game of Thrones? If users see your process as not only simple but with a clear path, they’ll complete it faster and it will feel more convenient. Another  advantage to this approach is that with a simplified process returning guests are more likely to have greater velocity on each iteration.

Of course there are other benefits to reducing cognitive overhead - benefits the engineers and support personnel will enjoy. Benefits we gain because we know that it is always easier to destroy a complex system than to selectively alter it and that complex systems fail in complex ways. The less complex a system is, the better habitable (form) it is for the engineers who have to modify it and support it, the better we are able to ensure its function, and the better its fitness is likely to be.

Notes:

1. Hick’s Law - an individual's reaction time increases by a constant amount as a function of available choices
2. Age affects the processing speed of the brain (Salthouse, T. A. (2000). "Aging and measures of processing speed". Biological Psychology 54 (1–3): 35–54.
3. Acquisition occurs when a guest user becomes a member - your app has 'acquired' a member. Forced acquisition, then, is when the user is forced to upgrade from a guest to a member account.

What I learned from writing payment interfaces (Part IV)

[Note: Each post in this series will have a sidebar with questions intended to encourage you to think.]

In Part I and Part II we looked at elements, both foundational and code-related, that affect speed. In Part III we started our exploration of velocity by looking at mitigating risk. In this entry, we'll look at expanding our app to other locales.

Globalization

• Where do we have to tell users that Flash cookies and browser fingerprinting are used?^[1]
• In comparison to the US, is page load time less than, greater than, or the same in LATAM? APAC?^[2]
• Which credit card does not use the Luhn algorithm?^[3]

It may seem somewhat counter-intuitive, however, the job of mitigating risk becomes even more difficult when we talk about business on a global scale. One of the greatest problems we face when building a product for a global market, however, is not risk, but rather that we are used to thinking only in terms of our own country, and our app appears to be something like a tourist when it’s used outside of its home country.

It’s relatively simple to develop an easy-to-use app for your own country because we know all kinds of things about our country – like you cannot require someone to give their ZIP code for a cash purchase in the US, or that privacy laws for the EU require disclosure about how information – like a Flash cookie or browser fingerprint – is collected and used, or even more simple things like how to collect addresses and phone numbers or what funding methods (e.g. lastschrift or credit cards) are typically used.

Beyond the technical "how" of code development and reuse, issues such as legal restrictions regarding what information can be collected, when it may be collected, and how it may be used as well as cultural issues such as which item a user is likely to select from a list in a given situation affect payment interfaces used globally, but they affect other apps used globally as well.

In developing a global product, we have to consider not only the nuanced issues - like the selection rate of lastschrift versus credit cards in a payment interface - but other, simple things as well. We have to consider something as simple as what we know, or can know, about information like addresses and phone numbers for other countries.

You can easily target a single country and do the necessary research; however, we must either accept the impact of increased complexity that comes with a highly localized product or determine how to generalize the interfaces by answering a host of questions – for example, can we validate phone numbers or postal codes, what are the common elements in an address, what can we determine about different funding instruments, and how do we design for linguistic issues, such as text direction or significant variance in word length, and how does cross-border trade affect any or all of these issues?

Of course one of the greatest dangers in the globalization of our product, is like the danger associated with risk - it can easily impact velocity. Further, the more subtle part of the danger to velocity lies in the way data collection intended to mitigate risk or make a more global-friendly product contributes to cognitive overhead.

Notes:

1. The EU
2. Page load time is greater in LATAM than in the US (AR and BR have load times approximately 2x the US times); however, there is wide variance in APAC (load time in CN is about the same as US, but load time in JP is less than US times, with mobile nearly .5 the US times, and most other countries in APAC are significantly slower than US times). http://analytics.blogspot.com/2012/04/global-site-speed-overview-how-fast-are.html
3. China Union Pay

What I learned from writing payment interfaces (Part III)

[Note: Each post in this series will have a sidebar with questions intended to encourage you to think.]

In Part I and Part II we looked at elements, both foundational and code-related, that affect speed. In Part III we'll start our exploration of velocity^[1].

Risk Mitigation

• What do we know about the product that might affect the transaction?
• What do we know about the customer that might affect the transaction?
• What can we learn about the customer while they’re making their payment?

As anyone who has written apps for any length of time can point out, there is more than just raw speed that we must consider. In another post, I've referred to this something similar as completion time, likening it to load time and render time; however, in this series I'll use the term velocity to refer to how quickly the user moves through a process.

One of the major factors affecting velocity in a payment interface is risk. Processor declines, charge backs, and disputes can easily derail an otherwise profitable business; however, the rules defining risk, such as "selling jewelry is riskier than selling shoes" or "new customers are riskier than existing customers" typically exist outside of the payment interface^[2]. Of course there is risk associated with all sorts of transactions, such as legal ramifications brought about by not attending to country-specific restrictions. Ideally, there is a secondary process (hopefully isolated) that tells us whether the customer we think we have is really the customer we have.

In a payment interface, and in an app, we don’t generally need to be concerned at a high level that our risk rules fail to block the right transaction (e.g. a shipment of alcohol to a restricted locale) or alternatively, exclude otherwise valid transactions (e.g. a person preparing for a trip by purchasing electronics such as digital cameras along with prepaid phone cards). In our app our task is to collect enough of the right information in order to make reasonable decisions regarding not only how much risk is associated with a specific transaction but also about how much risk we are willing to allow.

More importantly, of course, we have to be cognizant of whether or not while we are collecting the right information we are negatively impacting velocity. One typical bottleneck we've seen is in the collection of an address. Of course this is in part due to the difficulty of gathering addresses in a global setting (which we'll touch on in Part IV) but also due to difficulties with regard to validation of an address^[3]. Not only is there a significant chance that we will affect user velocity with our risk rules, there is a significant chance our risk rules themselves prove to be a problem. That does not mean we should eliminate the risk rules, simply that those rules should be integrated into app code with the utmost care, and, of course, testing.

Notes:

1. Velocity, unlike speed, is a vector measurement - it's related to movement in a direction.
2. There are risk factors that are especially applicable in developing payment interfaces - things like product type (e.g. prepaid cards, jewelry, electronics) and the country of the buyer and seller; however, there are also more general risk factors we can attend to, such as a mismatch between the originating location of the request and the user-reported location or a user accessing an account that has a negative history (how 'negative history' is defined is less meaningful - it could mean anything from a poor reputation score to chargebacks).
3. For further information, you may want to read my post regarding Address validation.

What I learned from writing payment interfaces (Part II)

[Note: Each post in this series will have a sidebar with questions intended to encourage you to think.]

In Part I the focus was on the foundational elements of a web app, and how those foundational elements aren't generally within the domain of the UI engineer, even though they are of significant importance. In this entry, I'd like to consider the aspects of code speed that are generally within the domain of the UI engineer.

Code speed

• Which is faster - Value equivalence (==) or Type/Value equivalence (===)?
• Which is faster – a native JS for loop to iterate through a NodeList or the jQuery "each"?
• Which is faster – an if..else statement or a switch statement?

One of the practices I’ve seen in my years as a UI Engineer is a constant, steady, relentless increase in the amount of code associated with an app. We, as a group, know the importance of keeping page weight low; however, somehow we end up with 86MB pages that win design awards^[1].

Even though such monster pages are rare, common code that I've seen typically includes a little bit of everything from poorly-written HTML that either uses tables for layout or is rampant with div-itis^[2] to bloated and/or low-performance CSS and low-performance JavaScript. All of these have an impact beyond page weight alone.

I have no desire to jump on the JavaScript is bad bandwagon. I firmly believe that HTML and CSS should be subject to many of the same rules as we have for JavaScript and be as simple as possible; however, there is often little we can do to HTML and CSS to increase the speed with which the most basic page renders. We ought to hold fast to the principles of both progressive enhancement and semantic markup, but we ought not stop there. We are no longer - at least in my experience - being paid by the KLOC^[3], so take up the practice of delivering the least amount of code possible. I can promise that this practice will benefit you in a number of ways in the future^[4].

Further, as UIEs, we must take the same ruthless approach with JavaScript. The first question we must ask is "is it necessary" because, based on my observation, we seldom consider the effect seemingly simple things, like DOM manipulation, have on speed. It’s all too easy to look at a block of code and think “it runs in less than 10ms, so it’s fine” without considering how that block of code is actually used - a practice we must abandon. We have to ask ourselves how the code is being used. For example, does the code trigger a repaint? Is the block of code wrapped in a setTimeout or setInterval that may cause a race condition that impacts the interface? Does the block of code do something that impacts user interaction, like disabling a field or repopulating a drop-down list?

Beyond the overarching questions, however, we must get into a practice where every line, every block of code is ruthless written to perform. For example, it is fairly commonly to see a value equivalence check used even though a faster type/value check would return the same result, and I see many more if/else statements than faster switch statements. We must implement design patterns that give speed advantages whenever possible. This simple practice will become increasingly important as we develop more apps that run on mobile devices and we begin to focus on framerate and how our code affects animation.

We must change our thinking. As I said before, speed cannot be considered in isolation but it also must not be an afterthought. We must get out of the mindset that development is about function – the app does the job – or form – the app is habitable, not only for users but for engineers as well – and into the mindset that development must be a balance of function, form, and fitness – the software performs – and that we must develop from the outset for fitness.

Notes:

1. This time it's Oakley's page for the Airbrake MX, which I have every reason to believe is a wonderful product. Details about the Site of the Day award from awwwards, and some discussion about it can be found on the awwwards award page. Documentation about the site can be seen at Oakley's monster page of baubles.
2. Div-itis is the tendency to wrap portions of code inside a div tag, and preferably add an ID attribute in case there will be some DOM manipulation in the future.
3. LOC is "line(s) of code", so KLOC is 1000 lines of code, which was an early measure of productivity for programmers
4. Many of us have heard it said, and can attest to the truth of the matter, that complex systems fail in complex ways. Simple code not only carries a lower risk of failure, but a greater chance of resolution and repair when failure occurs.

What I learned writing payment interfaces (Part I)

[Note: Each post in this series will have a sidebar with questions intended to encourage you to think.]

When I think about what I've learned writing payment interfaces, I might have started our quest with a discussion of industry terms and how they’re used, or how we need to use A/B testing to measure user response to changes and monitoring the shift in conversion^[1] in basis points^[2], or the impact that acquisition^[3] has on payment - these are important topics, especially to people who write payment interfaces - however, the most important topic we need to understand is the payment business, and the most important things we need to understand about the payment business is that speed matters and velocity matters. To understand speed, we’ll start our questioning at the beginning.

Foundational Questions

• What’s the average worldwide DNS lookup time? Which is faster IPv4 or IPv6?
• What load balancing device is used for external load balancing?
• Who are NACHA and OFAC?

These questions, at first glance, don’t really appear to be questions User Interface Engineers consider. That first question – DNS lookup time – a UI engineer doesn't control that. It's the same with the load balancing device. Don’t those belong to “operations”? NACHA and OFAC? Those are business groups, right? Why are these important?

As I've already stated, speed is important – in fact, it’s one of the most important considerations during checkout. However, not all site speed issues are directly related to things UIEs have under their control. The reality is that speed cannot be considered in isolation, however, speed cannot be an afterthought either. We must be aware of just how the factors outside of our control affect speed, in part to take steps – like minimizing DNS lookups – lookups that take 400ms on average^[4] – to increase speed, and in part to know what actions will have greater, or more immediate impact. For example, would it be better to keep an IPv4 address or use an IPv6^[5] and change the load balancing algorithm? What impact would a change to from a consortium bring forward, for example, what if the rules OFAC uses to restrict payments changed or if NACHA changed constraints regarding required information? Are any changes to the foundational elements large enough to affect overall speed?

It is without question that these foundational elements affect speed. It is also without question that is largely a balancing act of almost innumerable variables where we're hopefully reducing the cost of some of the variables so that we might offset increases in the cost of others. To maintain this balancing act, we must learn to step outside of our typical domains to understand, and at times to help others understand, the foundation upon which our app is built and specifically how it relates to speed.

Notes:

1. Conversion is the percentage of users who actually pay once the transaction has been started. Think of it as a queue of people waiting to pay - those that actually do "convert" and those who decide they're too busy or have forgotten their wallet "abandon" their transaction, and the rate is abandonment.
2. A basis point is one one-hundredth of one percent (.01%), or one more paying customer out of a queue of 10,000 people.
3. Acquisition is converting a guest user to a member user. Data clearly demonstrates that forced acquisition - forcing a customer to create a username and password to complete a purchase - lowers conversion significantly (which is not to say that the cost incurred by the reduction in conversion would not be offset by benefits of acquiring new members).
4. The 300-400ms speed reported by Google is considerably faster than the 400-800ms speed reported at Velocity 2010, however, it's still significant. For further reading, I'd recommend A Dismal Guide to DNS and the Performance Benefits portion of the Public DNS discussion on Google Developers. If you'd like to run a simple test to see how long a DNS lookup might take for one of your users for your domain, you can check http://www.dnswatch.info/dns/dnslookup?la=en&host=insert-your-host-name-here&type=A&submit=Resolve - just replace the insert-your-host-name-here with the host name you want to check (e.g. cathmhaol.com).
5. You can see Cisco's data regarding IPv4 vs IPv6 at http://www.cisco.com/web/strategy/docs/gov/IPv6perf_wp1f.pdf, of course you'll also want to take a look at An Engineer's Guide to Bandwidth to help make sense of the information presented by Cisco.

Vision without action is a dream, action without vision is a nightmare (Robert's Rule #5)

[Tweeted 2011-04-29]

We'll start off a short post with the rule today. A vision without action is just a dream; action without a vision is a nightmare (Robert's Rule #5).

One of the things that I have consistently argued against in every organization I've worked for is what I call "Getting Shit Done Syndrome", or GSD. (Feel free to think of it, or call it, "Getting Stuff Done Syndrome" if you'd like.)

There's a simple argument behind this that goes something like this...

• If you're in "information technology" then you're in a knowledge economy
• If you're in a knowledge economy then your product is knowledge and information
• If the product is knowledge and information, that requires thinking more than doing
• Therefore, you're paid to think, and then do, not just do

I cannot even begin to name the times I've seen my fifth rule in action; the number of examples I could give are countless. So, rather than pull out one experience from hundreds, I'll just say that if you don't consider this rule valid prima facie then our experiences are so different we may not be able to find any common ground.