User centricity: the biggest challenge in digital analytics and marketing.

There is only one boss. The customer. And he can fire everybody in the company from the chairman on down, simply by spending his money somewhere else. Sam Walton.

The sentence is nothing but true. It's simple and responds to common sense above everything. It was pronounced by Sam Walton, founder of Walmart. This represents by itself a change of the paradigm of performance and operations optimization from store-centric (or website-centric) to customer-centric or, in a more general perspective, user-centric, understanding user as a customer or a potential. The folks from Wharton University in Pennsylvania are on the lead of customer-centricity and customer analytics research. Many applications come out from this kind of analytics: customer lifetime value, in-store analytics, etc.

One thing, however, is also clear: a customer, before becoming a customer, is just an user, flowing through different stages of its cycle (attention, awareness, etc.). This distinction between customer and not-yet-a-customer is specially important when it comes to a website or a native app. In other words, how does this shift of paradigm apply in a web-based environment? We have been observing the transformation from session-based to user-centric tracking and optimization.

Over the last months we have been witnesses of how the digital analytics tools have been shifting their main reports focusing on the user. Tools like Google Analytics report users before sessions, while some months ago it was doing it in the opposite way. For instance, look at the order in which Google Analytics reports: first users then sessions (for the App views).

Here we already face the first challenge: how to define a user. We will come with this in other posts. Before that, I want to recall a situation we faced some time ago while doing consultancy for a e-commerce site in the European market. We were requested to understand how the sessions were browsing in terms of multi-category behavior. Concretely, the website had a header looking like this:

The problem was to understand the share of sessions that were browsing through only one category, through two categories, through three categories, etc. over different periods of time. We had a split looking like:

Even more, we also showed how the carts were looking like in terms of cross-category items:

The management reacted very worried, and they immediately initiated actions towards incrementing the share of sessions that were browsing through more than one category, and to increase the number of distinct categories on each basket. If you agree with this course of action we must say you are doing it probably wrong. Indeed, all intents to increase the cross-category sessions and carts were unsuccessful.

What could have been a better approach? A good advise: put the user in the center and understand the intention of each one of its sessions. You can't simply pretend to have every user stepping at all your content on each session. Instead, you can get the most out of each session by understanding the intention of such session. If a user is visiting category A-related content on a given session, then make sure it performs a purchase over such category. The important is to prevent the user from spending its money somewhere else.

Is this everything we can take out of the user? On a session level, probably. But, what if we widen the time window? Instead of looking which category the user browses on a single session, we could check all the sessions that user performed over a week, month, quarter, etc. In the case we have being considering, the charts looked significantly different:

As we can see, the share of users that only browse over one category dropped from 60% to 40%, while the share of users that browse over 2 categories increased from 20% to 30%. And here is where we can induct some change. By incentivizing the user to reach other categories (again, over different sessions) we can improve the awareness of the user over such categories not browsed before. If the content is appealing enough, we might get a chance that the user will actually buy over it.

Another analysis that was interesting for this case was the one showing the distinct categories bought by every customer over a period of time, considering all the orders placed. We had a situation looking like:

which transformed into this:

after applying direct marketings action whose goals were precisely that: to increase the share of wallet of the user over different sessions and, probably, over different orders.

That is, be patient, and keep the user in your focus. Don't overwhelm it, and take advantage from each session... one at a time.

There is, however, a new variable that comes as an input in the equation of user-centricity, which applies specially to digital environments: the device used to reach the site. Identifying the user when it browses over different devices is a big challenge. Universal Analytics enables us to identify at least one important bunch of such users, and it can be applied for sites that somehow identify them via login, newsletters, etc. The reports look very promising:

This information is extremely useful to understand the intention of a given user (or a set of users) when reaching the site with the different available devices. For sure is not the same intention when a user reaches the site with a smartphone in the morning or with a tablet at the afternoon. Placing the user in the center is, at the very end, about understanding its intention on each one of the sessions at each seasonal moment (in-day, in-week, etc.), with each one of the different devices. To make it a bit more complicated, we can also introduce the fact that some of these users might be also visiting your traditional store (in case you have one, of course). Many sites (fashion industry, mainly) allow you to buy over the web of App and pick it in-store. Lots of research is currently ongoing, in order to track in-store behavior. For instance, Estimote is doing some efforts towards this goal.

In following posts we will talk about the shift of paradigm on the reporting strategy (not necessarily about tools but techniques and contents) whose center is on Customer Lifetime Value (CLV).

In any case, if you have more questions or issues with your omnichannel approach, don't hesitate to contact us here.

Read More

A truth behind the lead business: a comprehensive approach (or the onion approach).

We are obsessed with improving our conversion rates while keeping our traffic levels. But, is this the right approach? I would say yes and no, bust mostly no. Let's see why.

Lead business is a very complex one. And, as we said in our initial post, complexity matters!

Before jumping in to a discussion regarding leads, let me recall a situation we faced time ago when doing consultancy for an e-retailer (a very big one, by the way). They were having a wonderful situation: around 20 million monthly sessions with around 3% session-to-order conversion rate, very high average order value, and pretty good margins. We were able to close a meeting and we offered them the full artillery: UX enhancements, fine tuning of the tracking tool continuous A/B testing, heatmaps, and so on. They told us: no. Surprised by this answer we asked: Why not? We were offering them a very good deal: very low fix fee and a high variable based on success (we did that because the site was horrible: we already identified couple of opportunities that could improve the conversion rate). They replied: we don't have the enough logistics resources to handle the extra amount of orders that would come! Ok. Lesson learned.

Some years later we came with a similar case. The context: traditional insurances company (life, car, and home) starting developing a digital presence. They had a horrible website that was generating around 500 leads per week. As soon as we saw it we wanted to offer the same service we offered years ago: conversion rate optimization, UX enhancement, full deployment of Google Analytics, etc. That is, we used to see the situation as:

However, as a side note, a comment from one of our analysts came to the deck. "Wait!" he said. This might not be the right approach. "Let's recall the e-retailer situation we faced years ago!". Indeed, let's take a picture of the current situation. Concretely, let's take the first step towards a comprehensive picture:

- 500 leads per week generated through the website.

- 2% lead-to-policy conversion rate (which takes place offline, via a phone call). This means 10 policies per week (simple math).

- To make 500 phone calls a week, they needed 2 full-time resources.

- The cost for a full-time resource was equivalent to the revenue generated by 4.5 policies. In other words, the "actual margin" is around one policy.

Now our landscape is broader, much broader!

With some basic enhancements to the website, we could increase leads by, let's say, 50% (site was really ugly). With more simple maths we say that we could have 750 leads per week generated through the website. But now the key point is that the lead-to-policy ratio would not necessarily change! This means that they would just increase the total number of policies up to 15! We always say that we need to ask the right question. At this point the right question to ask is: how many full-time resources do we need to handle 750 phone calls per week? A simple cross-multiplication shows us that we would need 3. This extra resource would cost us another 4.5 policies. In other words, the total cost for the 3 full-time resources would be 13.5 policies, so the actual margin would be equivalent to 1.5 policies! Wow! We did a lot of work to improve the website just to raise our margins by half a policy! This at the end means that, with the current set-up, the business does not look scalable. Or, in other words, more does not necessarily mean better. Even worse, what would happen if a sudden pike (seasonal pike, or a pike due to a sudden reduction of the prices, or by a sudden increase on your competitors prices, or by a sudden increase on traffic due, for instance, by an important investment on marketing) occurs? It's simple: the 3 full-time resources will not be able to handle all phone calls on time. In the insurances universe, if you don't handle a call soon you have high chances to loose it.

How do we solve this? Here we will apply the "onion strategy". Imagine your processes as an onion, and each one of the sub-processes are a layer of the onion. The basic idea behind this approach is that you should start optimizing processes from the end of the journey to its beginning. In this way, as the user flows he will always step towards a process that we already tried to optimize. In the case of the insurance company, the first thing we offered them was to understand whether we can improve the lead-to-policy rate. Here a new world appeared in front of our eyes: we taught them not to follow all leads (we implemented very cool models to prioritize the incoming leads), we taught them to catch the necessary data to understand why a lead converted or not into a policy, etc. At the end we were able to improve the lead-to-policy conversion rate up to 15%!. At that moment we were able to improve the website in order to bring more leads. And after that we were able to optimize the traffic sources, the prices, and to understand the competition, in order to have under control the total amount of sessions reaching the website. We got then a much broader landscape for the situation:

Despite this is a very simple representation of the full process that ranges from the intention to an actual policy, the exercise behind it is very insightful. And this is not only about data but about business. The full exercise of depicting the concrete steps through which the user flows up to becoming a client can only come from a deep knowledge of the business. Then, and only then, data science and tools appear. As we always say, the key point is to formulate the right questions. Then you find the data to answer them.

As a summary always keep in mind:

- More does not necessarily mean better.

- Broad your landscape until you have all the steps that can be improved or optimized.

- Think about the consequences the optimization of a step have to the whole process.

- Follow the onion approach: improve the latest steps of the whole process first and then improve backwards.

Good optimization!

Read More

Using data effectively. I bet you don't!

Every company has data. Every company understands (or should understand) the value of data. But, are you using data in an effective way?

According to FORTUNE, in a post early this year only 27% of C-level executives think their company makes "highly effective" use of data. Now, the question is: is your company making "highly effective" use of data? Or even: is your company making "effective" use of data? Or even more: is your company using data?

Every company has data, and working with data is simple to start: just start collecting and processing some data. You will find very soon that making a (highly) effective use of data is much harder than desired. In any case, I can focus for the rest of the post in the case in which your company uses data.

The key (and very complex) exercise is to define what (highly) effective use of data mean. Let's do it in the opposite way: let's define what an ineffective use of data mean by pointing out some situations that we've found over the last years. Will you be able to pass these tests? And, please, be honest!

Test #1: Which three indicators you check every morning when sitting at your desk? If you can't answer this question with a clear set of KPIs or with a clear set of dashboards, then your company is making an ineffective use of data.

Test #2: Do you have any doubts about the data you retrieve? Is it reliable? Is it clean? Is it readable? If one single answer is "no", then your company is making an ineffective use of data.

Test #3: Does data take ages to be retrieved? Then your company is making an ineffective use of data.

Test #4: Can you retrieve joined data from different sources? If not, or if you need to manually join it, or some sources are not accessible, then your company is making an ineffective use of data.

Test #5: Can you read and relate large amounts of data? If Excel is not enough and you use no other tool to do so, then your company is making an ineffective use of data.

Test #6: Can you retrieve simple data by yourself? If you need permanently to ask for help (either because the systems are too complex, or because you simply don't want to do it by yourself), then your company is making an ineffective use of data.

Test #7: Are the insights properly communicated and understood (not necessarily agreed) by everybody? If data is misunderstood, or poorly communicated, then your company is making an ineffective use of data.

Test #8: Are you having tons of bureaucracy that keeps relevant information from reaching the decision makers who need to see it? Then your company is making an ineffective use of data.

Test #9: Do you figure out the specific question you need to answer, and then determine whether the right information exists and where it's located in the organization? If not, then your company is making an ineffective use of data.

Test #10: Do you take actions out of the data and insights? If not, then you only face nice-to-have data. Hence, your company is making an ineffective use of data.

Your company will achieve a truly data-driven culture if and only if none of these 10 situation take place. So, how do we solve them?

Solution for #1: Define KPIs, organize them, and conceptualize dashboards. Start with a napkin, then draw them in a piece of paper. Have somebody generating a pdf file with them and make sure they are in your inbox every morning. Then evolve with a BI tool.

Solution for #2: If data is not reliable then you must investigate if the source is shaky, the retrieval processes have flows, or the consolidation and calculation rules are buggy. The first case would probably require data-freezing processes and rules. The second and third cases would probably require new data manipulation rules.

Solution for #3: If data takes a long time to be retrieved, you must investigate the cause. It can be that the sources are slow to access and retrieve. It can also be that the transformation and manipulation processes are buggy. It can also be that the reporting tool is not optimized. Last but not least, it can also be that your BI department is flooded with requests.

Solution for #4: If you have many sources that need to be accessed and joined, then you must define ETL processes (Extract, Transform, Load). If the volume and number of sources is really big, then a data warehouse is a good solution.

Solution for #5: First you need to wonder whether you actually need such amount of data. Data pre-processing and calculation at the server side are good ideas as well. If not of these apply (despite I bet they do), then you must find a tool able to read such amount of data.

Solution for #6: Empowerment is a must-have in any data-driven company. Start by saying no to silly data requests. Train your people. Make it simple: implement a reporting tool and teach people how to use it! You can start with fact tables that can't be modified. Then (much sooner than you think) users will start asking for the edition capabilities!

Solution for #7: Check where the bottlenecks are. Make sure your analysts develop soft skills such as communication techniques. Apply Barbara Minto's Pyramidal Principle to your communication techniques. Avoid presentations with 1000 slides. Focus, focus, and focus.

Solution for #8: Again, check where the bottlenecks are. Make sure decision makers can read data (and make sure they use it!). Improve transparency at the BI or Analysts department, and make sure to have proper feedback loops.

Solution for #9: Please avoid the Diogenes Syndrome for data. Don't store ALL data waiting for a miracle to occur and insights appear out of them. Know your business and identify the pain points. Then, and only then, figure out which data is needed. If the data is there, use it. If not, start recording it now!

Solution for #10: Avoid having too many operations and strategical dashboards. Kill the non-essential indicators. A good hint here is the Three Layers of So What test. Ask every indicator or analysis or insight the question "so what" three times. Each question provides an answer that in return raises another question (a "so what" again). If at the third "so what" you don't get a recommendation for an action you should take, then you have the wrong information. Kill it.

In any case, if this sounds complicated or unachievable, reach us: info@ducks-in-a-row.es.

As a summary, data is devoted to actionability. For this to happen it must be accessed, relied, and properly communicated. Then and only then your company will be making a highly effective use of data.

Read More

Bed & Breakfast Analytics Foundation #1: Burn the silos!

We are surrounded by skilled people. We are also surrounded by unskilled people. How do we manage such diversity? How can we be sure that our Data setup is the one you need? Discover my thoughts throughout this post, being the first one of a series of posts explaining the foundations of this blog. Want to read it? Avant!

Already as an experienced worker, in my first job as a BI and Analysis "manager" (at that moment I had no clue what a manager was because I never had good managers), I was first required to make an evaluation of their set up on the Data and Analysis department, although they felt very proud of their Business Intelligence efforts. The first question I asked, ironically, was: "Ah, do we have such department"? I was presented a Data Scientist, a Campaign Manager, a guy that was creating some dashboards in Excel, and a self-denominated UX expert. That was the marvellous team. After talking individually with them for a couple of days I came back to my Manager and said to him: "Sorry, you have no team. You have a set of skills but no cohesion between them. You built your Data strategy based on silos!". "What's your recommendation?", he said. The answer was the easiest one I've given in my life: "Burn the silos!".

Is my Data and Analysis setup the right one? Sorry, I would say: NO. I can bet my next month's salary that there are important flaws in the way you've organized your Data, BI, and/or Analysis team.
Before starting, let's make very clear what is probably the most important topic when building your Data team: there is no unique and/or magical solution. Every Data team should be built according to the Business needs, the company culture, the skills available at that moment, the available budget, and a long etc. I'm going to give you the classical consultant answer to the question of how to organize the Data team: "Depends". If you came here wanting to seek a magical solution, this is definitively not your place. Further more, this is not your best job. Building up the best team possible is a tough task, and, for sure, not an easy one. It will require a lot of trial and error and a lot of adjustments.
The basic outcome: what do you expect from your Data team?

I was told many times that the Data and Analysis team should give added value to the company. If you think that a Data or Analysis team should bring knowledge then I must say you're partially wrong. Knowledge is the path, not the mean. The ultimate end of tracking, analyzing, extracting knowledge, etc., is to create action! A feature in the website should not be tracked or analzyed if these actions bring no action to the business. The team should be able to trigger a change in the business when delivering knowledge based on an analysis. If there is no action out of these efforts, then the whole Data strategy is totally worthless.
Simplifying the lifecycle of a Data team, we could say that there are four main steps in an analysis strategy:

In first place we have the business needs. The team should be able to gather them, understand them, and forecast what they could look like, in order to deliver Actions proactively. This implies clear and crystal communication skills with the business owners. Once the need is clear, we proceed to evaluate the availability of the necessary data for the potential analysis (in a separate post I'll come back to this point). Then we analyze, out of which we obtain knowledge. Afterwards we come out with actions: we need to make sure that every single analysis done, every single report delivered, any single data extracted is actionable, in the sense of provoking some change, some further thinking on the management level, or, in the last-but-not-least case, a change of operations and/or strategical decisions. If an outcome is not actionable then, simply, should not take a single minute of the team's time. This is where many companies and set ups fail, and actually creates the sensation that there should be no further investments on the Data and Analysis team. As well, I'll come with further insights in following posts.

Now that, in a high-level point of view, we understand how the lifecycle of Data works it's time to understand that this process, as it's exposed right now, it's based on silos. Each step is traditionally done in independent ways: the web analyst specifies and validates tracking, the data scientist probably determines that a regression analysis is the most suitable to mine the data, the campaign manager states that some campaigns should be stopped, the reporting manager tries to gather-and-show all this information (after it's being generated), etc. All this process, again, has been built over a silo basis. With the process implemented this way is virtually impossible to extract real action out of it.

Here and now is where the Manager needs to step in, in order to wrap up these processes into a single one. Then, and only then, we could start talking about having a successful set up of our Data and Analysis team. When doing this for the first time, is very common to fall into one of the two following mistakes:

Excessive focus on Tracking+Analysis:

This is the most common mistake. Everything needs to be tracked and stored, said the CEO. There's not enough budget for that, said the CFO. There are not enough resources, said IT. There are not enough skills, said the analyst. There's not need for all that, should be saying the BI Manager. If you decide to track, store, and analyze absolutely everything, then I must say you have the data-version of the Diogenes Syndrome. You gather a lot of knowledge. You gather a lot data (which generates a cost that should not be underestimated). However, if there is no clear connection with the Business, we'll never be able to derive action out of this massive amount of knowledge. In other words, all this data and knowledge is totally unorganized and unstructured. The Manager should be able to gather concrete business needs, or, even better, identify clear business opportunities, and then (and only then) make sure the data is available and that a proper analysis is conducted. Actions will appear automatically after this process is properly followed.

Disconnection form the Business:

This is a very dangerous mistake. This set up is what I call the corpses set up. Deriving actions out of a massive tracking and analyze phase is like walking around by killing everybody you find in your path. If there is no connection with the Business (the motivation, the core of Data existence), the proposed actions will result in a worthless effort. Usually this set up ends with a generalized burnout of the Data and Analysis team. If the team (or its Manager) doesn't understand why are we tracking and analyzing, then the actions that we'll derive out of it will not answer any question. Let me depict this with a concrete example. As an analyst in a flash-sales online vendor I was asked by the COO: "For how long we should be running Promotional Sales campaigns? Please, tell me a number and I'll make sure that we'll implement such length". Indeed, was a very simple request, and it took me less than one day to come with an answer (actually, it was 4 days). As promised, the COO implemented by force such number, although nobody understood where that number came from. Even more, at the Data and Analysis team we ignored at all why we were running such campaigns. That is, we did not understand the essence of the request. In other words, the COO was assuming that we should have such campaigns "in order to generate unique buyers". A simple analysis afterwards revealed that such campaigns weren't generating more unique buyers, or that such buyers were spending more after a given time. At the end, by understanding what was the Business need (are Promotional campaigns worthwhile?) we were able to collect the necessary data and to conduct specific analysis to come with a clear action: kill Promotional campaigns. This was only possible by means of wrapping up all four silos in a unique and crystal process: from the Business need to the action.

A new way to understand the wrap-up.

The previous example showed that, indeed, we should consider all four stages as part of a single process. However, there is a way to further pressure the process: instead of considering it a linear process, consider it a cycle:

This is nothing more than having a proper follow-up of the implementation of the proposed actions. Ideally, such implementations will lead on more business needs, that, at the same time, will need more data and analysis in order to be optimal. Part of the Manager's skills we should count for proper feedback loops, implementation follow-ups, etc. This implies that very strong communication skills and technical and architecture knowledge are a must-have.

This cycle will automatically derive in chasing new business opportunities. In other words, when the team, and its manager, perform the proper follow-ups, and closes the cycle, then they will start to do analysis by themselves. Why? Because they will understand the business and check whether the implementation were a success or not.

Now this needs to come to an end. You can have the best business analysts, web analysts, campaign managers, data scientists, etc. etc. etc. But you will only succeed if their manager is able to wrap-up these silos, from the business needs to the implementations and assessment of the proposed solutions. It well worths a try. Guaranteed!

Read More