0203 2877 049 hello@rebelhack.com

Businesses are now under a torrent of data, and companies of all sizes are not turning this into a strategic asset. The lack of a data strategy is something I see over and over again at businesses of all sizes, which I find amazing considering the advantages it can offer – regardless of whether the business is a big business trying to consolidate its position in the market or a startup trying to act quickly and find product market fit or just scale up. I speak to so many business leaders that are keen to ‘growth hack their way to success, fame and fortune but have not thought properly about how they are going to actually leverage the process and ensure data-driven decisions are made across the organisation.

data strategy vs data dashboard - swimming in data - rebel hack

This dude is literally swimming in data!

Businesses seem to be so keen to get on and growth hack before thinking about how they will supercharge that growth with real data-driven decision making.

“Of course we’re a data-driven business Logan – #NOT!”

I hear business say this all the time, but then they go on to say that key elements of their data strategy have been pushed down the priority list a few times. I get it, plugging together the data pipes is not sexy, certainly in comparison to the models and dashboards they can produce but it has to become a priority. Even Sean Ellis and Morgan Brown in their recent book Hacking Growth talk about how instrumenting the product before you begin anything is paramount. This is the responsibility of all the executives in any business, not just the CDO. It has to be given executive weight as this will not happen on its own, but will offer so much value.

In this post, I want to highlight the key components that exist within a data strategy and provide a few frameworks and tools that you might want to leverage for building a lightweight data strategy.

But before we begin, I want to explain why a dashboard is not a data strategy. A dashboard is just a tool that acts as a window into the data strategy. It’s merely something to use to do the real data work. So don’t think that once you have a dashboard you have a data strategy. A lot of the time dashboards are set up in a way that does not really offer any real value – instead they are merely reporting tools rather than anything that helps to make decisions that would not have been made without the data strategy (i.e. to run a particular experiment, or to double down into one specific user segment).

So many businesses are eager to build a shiny new dashboard but they lack the understanding as to what is (or should be) under the hood. It’s kind of like saying that a car’s chassis is responsible for getting you from A to B. However, this is just what makes you look good as you do it, it’s the engine that actually does the hard work. Don’t underestimate how important being a plumber (aka data engineer) really is.

data strategy vs data dashboard - the mediocre performance data strategy - rebel hack

A data strategy is about high performance, not just reporting on mediocre performance. Click To Tweet

Ok, so what the hell is a data strategy?

A data strategy is a plan to better manage the acquisition, storage, access, querying, accuracy and reuse of data. It is about growing the data assets of a business to make sure all data projects are aligned and working in unison.

As data sources have blown up in recent years, such as application, cloud products, operational and marketing data products no one person can have domain specific knowledge of them all. Knowledge should not be left to move around the organisation simply by word of mouth, but instead, should be codified into a more formal data strategy.

Data Strategy Frameworks

Ok, so these are not that easy to put together, but there are some really interesting frameworks to consider. Here are a few of my favourites, but I encourage you to do research as there are many approaches.

HBR has proposed an interesting approach to looking at the fundamentals behind a data strategy as being on a spectrum. They suggest that a business’s requirements for its data strategy lie somewhere between defensive and offensive.

A defensive data strategy is one where control is more important than flexibility and is about limiting downside risk. These businesses are more likely to be thinking about adhering to regulations, such as building alerts for fraud and reducing theft. An example here might be a hospital holding personal health records, or a credit card company trying to identify if a card has been stolen. This is more likely to be built on what is known as a Single Source Of Truth (SSOT), which is a single repository and access for the entire business. This offers a lot of control but lacks the flexibility to move fast and find insights that are specific to discrete business functions.

An offensive data strategy is the opposite, less about control and more about flexibility, enabling the individual business units to quickly find insight to increase profitability/performance locally and increase its market share and competitive positioning. They are more ‘real time’ and will be about local insight analysis and modelling (ie at business unit level). They are about bringing data from a range of sources onto interactive dashboards helping business unit management make decisions more quickly. I will be discussing a hybrid below, as I have more experience of these – it’s one of the things we do here at Rebel Hack.

Remember, this is a spectrum and so a company can be in multiple places at any one time. An example would be Uber, where it has to be defensive to discover taxi drivers who are trying to ‘school’ the system and get prices to rise before picking people up, to aggressively entering a new market and seeking local customer insights – fast! Where a company sits on the spectrum will be largely driven by the industry in which it resides, and it’s the role of the Chief Data Officer to finely balance the resources for both offensive and defensive work.

data strategy vs data dashboard - spectrum of data frameworks - rebel hack

When thinking about data architecture (the way a company approaches collection, naming, storage, access and transition) many companies have tried to build centrally orchestrated approaches making things less flexible, and not particularly great for ongoing data strategies. Remember, our intention here is to make getting access to data (or more accurately: information) easier across the organisation and various business units. This approach is known as the Single Source of Truth (SSOT) approach. However, what we really want to work toward is a Multiple Versions of Truth (MVOT) setup, enabling quick and easy access for local business function management. But again, as a smaller business we have to think rationally and seeing as you’re very likely sat next to the other departments we can work within an SSOT framework at first, and aim to build into an MVOT model using an array of 3rd party services. For a smaller business, the main thing is to have SSOT for customer and event data, and I would recommend this is seen as the main ‘anchor’ for the data strategy at this early stage.

data strategy vs data dashboard - the spaghetti bowl single source of truth - rebel hackWhen we start to build into MVOT we have one SSOT, but each discrete use of that data to provide information across a business can be different and contextual – so long as the underlying data is the same. The way these MVOTs should be updated is by using production grade, purpose built schedulers such as Oozie and data handlers, perhaps something like Segment. The only thing to note is that these updates of MVOT must be tightly controlled, otherwise, we end up with a bowl of data spaghetti – and no wants a bowl of cheese covered data!

So, to summarise this section, where you sit on the defensive vs offensive spectrum will be tightly aligned with your business strategy, business lifecycle stage and industry. And you cannot move to MVOT without a solid SSOT.

But for younger businesses that want to be really aggressive and push for market share and growth, I think there is a hybrid. Seeing as we’re interested in, and specialise in growth marketing, we will look at how to build an SSOT model, whilst offering discrete business functions the ability to get access to what they want for management purposes. This is where data engineering and building a robust marketing technology stack comes in.

Components of a data strategy

Before we get stuck into how to build this lightweight data strategy, we need to understand the components of a utopian enterprise level data strategy. Although we’re not interested in building this level of detail into our lightweight offensive growth data strategy we should know the components so we can pick and choose what we want and develop our lightweight version into something more valuable and robust over time.

The 5 components of a data strategy can be looked at under the following headings:

Identify the meaning of your data points

This is all about ensuring a business user can identify data’s meaning regardless of source, origin and location. In layman’s terms what we’re saying here is that everyone attempting to use the data must have context and understand what data they are working with. There is no point in building an ‘all singing, all dancing’ data strategy if we don’t know what we’re working with. Here are some main points to consider:

  • Event Taxonomy/Schema
    • In order to easily classify events, you will want to agree on a framework that you can build into an events schema, helping you to give data context. We use an updated version of Dave McClure’s PIRATE Metrics (AARRR):
      • Awareness – SEO
      • Awareness – Social Media
      • Awareness – Paid
      • Pre-User Activation
      • Lead Acquisition
      • Lead Nurture
      • User Acquisition
      • Post-User Activation
      • Retention
      • Referral
      • Revenue
  • Consistent data element naming conventions
    • Below is an example as to how you go about naming using an object-oriented framework:
      • all lower case — account created
      • snake_case — account_created
      • Proper Case — Account Created
      • camelCase — accountCreated
      • Title case — Account created
  • Consolidation of business terminology into a business data glossary
    • This is easy, but so often overlooked resulting in a lot of confusion. You need to make sure you all know and agree what event names actually mean, and what they represent. We create a massive detailed events schema that acts like a reference card for all events. (If anyone is interested to see a template as to what we use please just let me know in the comments and I will create a basic template and share with you).
  • Metadata organisation (e.g. data card catalogue)
    • Think of this like a map to the gold. If you don’t know where to find the data you want, you ain’t going to find it quickly.
    • You want to think about the following metadata for your data definition; origin, location, domain values, etc.

Data Storage

When most people think about a data strategy, for some reason this seems to be what people think about. Perhaps this is a legacy from IT when data was collected, used once, and then stored. Never to be looked at again, getting covered in virtual dust! Although not the only component of a data strategy, it is obviously really important. Storing data needs to be done in a manner that supports easy access, sharing and processing. Paying for computation can get really expensive if you have an inefficient way to store your data, trust us, we know. We have a tonne of ML running in the background and we’re always working to make our storage more efficient for computational purposes. Here are some key things you should be mindful of when thinking about data storage.

  • Share and move data between systems
    • The way you store data has to make sharing data easy between systems and across business functions
  • Provide access to all data without the requirement to copy data into multiple locations
    • As we’ve said there should always be an SSOT, that can feed MVOT. Do not store data in multiple silos. This is just not cool.

data strategy vs data dashboard - data confusion - rebel hack

Figure: A diagram to show what not to do, by Sas.com

Formatted provision of data

Data needs to be in a format that means it can be easily shared and most importantly reused, offering guidelines for how to use and access data across the organisation. Basically, there is no point in having data in a highly sharable format if it is unusable by the end user, say the data analyst.

When data is shared in packages, it cannot be in a format defined by development but instead, it has to be for the end user of the data
Don’t think of sharing data as a one-off. This is something that is ongoing and constant. It is instead a requirement for leveraging ROI from the data assets held. It has become a production business need.

Integration of system components

Ok, so this is a really important element, especially for a lightweight data strategy (well, obviously for a larger enterprise level data strategy too). Data needs to be moved from system to system, whilst providing a unified, consistent data view. Make sure that any amends made on 3rd party system update the SSOT. In order to achieve this level of data uniformity, you need to ensure you scope out and fully understand all the integrations as these are where you data strategy (if anywhere) will break down.

This is not just about ETL (extract, transfer, load), but instead about moving structured and unstructured data across disparate business systems – both operational and analytical.
Logic that has been learned and built in one area of business (/or product) should be shared with the wider team so as to reduce time spent on integration (i.e. identifying and matching records across platforms). This is less likely to be important in our approach to a lightweight data strategy, but something to bear in mind as you scale up and grow up as a data-driven organisation.

Data policies and governance

Ok, so this is ‘almost’ the boring bit – but it is really important to understand. Your business should have a range of policies around access to data usage and should be shared and explained.

Here’s a rule of thumb for you…

The more people you have accessing data the more you need data governance in place. Click To Tweet
  • A range of policies to manage data usage and manipulation.
  • Normally this would start as tactical requirements such as accuracy, but as the requirement to share and gain access to data grows ensuring a uniform approach here is paramount.
  • Security, data correction etc are all components of governance
  • This should not be decided at the developer level, but instead at an operational level, and should have high-level leadership to ensure it’s done properly and assimilated into the business.

data strategy vs data dashboard - reaction to data governance - rebel hack Ok, so that sounds pretty heavyweight, right? Yea, it almost made my brain melt too. So, let’s get onto how we can make this into a more lightweight framework for implementation.

How to build a lightweight data strategy to turn startups into scale-ups.

Identify your data strategy objectives up front

Identify a range of things you want to know. They can be super granular, or more broad brush, but make a list. This is going to form the basis of your roadmap.

Examples might include:

  1. I want to see what channels are responsible for driving app downloads
  2. I want to see what my CAC per channel is
  3. I want to understand how my onboarding testing has affected ongoing user behaviour over time
  4. I want to know how many leads I am getting

Ok, so these are obvious examples, and they range from easy to complex. At Rebel Hack we would then score these in order of complexity using a tee shirt size (S,M,L,XL,XXL,XXXL) with the larger the tee shirt the harder the project to unearth them.

We would then make a decision as to immediate value vs complexity. Our final decision might look something like this.data strategy vs data dashboard - the t shirt data framework - rebel hackBOOM! Now we have what looks like a roadmap.

Then you want to break down the requirements of each of these key milestones, thinking about them in terms of the following:

Optimise and build out your data analytics capabilities

What do we have to do with our analytics setup in order to get this data point? Now, if we’re aiming to get something up and running fast, we will want to leverage 3rd party platforms with tight integrations rather than building our own. Make sure the platforms you choose to work with integrate with one another and can actually do the job. There is nothing worse than getting mid-build to find out some key integration or component does not work with another.

I cannot stress enough here than planning and research here will save you days! Literally. I once made a mistake with an integration where I failed to ask what the app was made with and ended up instructing the wrong SDK to be pushed into production. This was a while ago, and that was a painful learning experience but one I will not repeat again!

A really useful for assisting with integrations and data transfer is Zapier.

Data Visualisation

Ok, this is the pretty bit in most cases, and kind of comes back to the title of the blog. Here we’re talking about dashboards (and reports). As you can see, they are NOT a data strategy, merely a component of one.

I would always recommend you think about only what you need. As my mum always reminds me

“Keep it simple stupid!”.

Don’t get carried away, just focus on what you really want to see/know. Then find a way to display that. You can get carried away here, but I like to keep things ‘crazy’ simple. A lot of the time I go for numbers and changes in conversion rates only! That is all that I need a lot of the time. For me, it’s about spotting trends.

Here is a quick snapshot from part of our proprietary setup to give you an example. Nothing fancy, but it makes information of data. You can quickly see sales are increasing, but CAC is also growing. The next thing we we might want to know is the change in conversion rate between the funnel phases to help us identify the health and performance of the product funnel.

Data Transformation

To quote Technopedia

“Data transformation is the process of converting data or information from one format to another, usually from the format of a source system into the required format of a new destination system. “

Basically, if you have to convert data from one source into your company-wide data format/language this is where you have to think about it. It’s about enabling the data to be used internally. You will need a data engineer here, and will likely occur when you’re leveraging multiple APIs (well that is when we encounter this internally anyway).

Data Enrichment

This is a cool bit, and something we use a lot. It’s about taking data you already have and adding more data to it to it, giving you more information. Now, this can come in several ways. You can either use data points to perform calculations, thus enriching your data with new data points that can themselves feed more calculations.
Alternatively, you can use something like Clearbit which is a really powerful product that basically scrapes the web to find out more information about your business leads. We use this ourselves, and for many other partners as it ‘freakin’ AWESOME!

freaking awesome data enrichment - rebel hack

So, once you have thought about all of this, and identified a range of activities that are required to answer your objectives in a priority order you have the foundations of a project plan.

You can then build this out, bring on the team, allocate responsibility and crack on.

Building the project plan for a data strategy

Ok, so I won’t bore with project management and planning but here are a few tips.

  1. Get your entire data and analytics team into a room and go through the plan in detail to make sure everyone is on the same page. They should be as you will not have built this in a silo (well you should not have!!).
  2. Run the project like an agile development or agile growth marketing project.
  3. Be willing to change priorities, and therefore project prioritisation as you learn more from your data.
  4. Check, check, check and check again. Make sure you test your data acquisition from the ground up. What I mean by this is that you need to ensure thorough analytics quality control (and regular auditing) because you can have the best data strategy in the world, but if you name an event wrong or collect the wrong data point you are going to be way off!
  5. Start small, demonstrate value and build consensus across the organisation that a data strategy adds real value to the business. Then push the scope of the project and extend its runway.

So, there you go. That’s it. Easy right!?!?

Data modelling and analysis formats

Ok, so once you have your data strategy in place, with data in the right place and the right formats etc you can do some pretty cool stuff. The implementation of a data strategy enables a business to run a range of really exciting analysis and statistical techniques through the data to discover insights, helping businesses to make decisions they would not have previously made.

The question you want to ask yourself is ‘what do you want to know?’. Once you know that, you need to understand what models and analysis formats you are going to have to leverage in order to get the answers you want. The type of analysis can range from the simple, to the super complex. Most small businesses will not have access to the examples below, but larger scale ups and businesses could seriously think about these or alternatively ask us to build them out.

The examples below are pretty technical but can be really powerful, I hope you get the point as to what you can achieve from the implementation of a robust data strategy!

  • Profiling – Choose a range of customer demographic and behavioural variables to determine what lapsed customers indexed highly against most commonly within the dataset. This would do much to inform content and targeting for both core customer segments and lapsed customers and help understand if lapsed customers are overrepresented in certain demographics.
  • Data Modelling – Produce a mathematical model to predict a customer’s likelihood to be activated and retained using a range of the most populated variables within the dataset.
  • Experiment Design and Analysis – Track app downloads as function of time based on ad changes at a set frequency via switchback experiments in order to optimise in-location acquisition channels (test effect vs control effect as a function of time).
  • Geospatial Cluster Analysis – Clustering shoppers to identify hot-spots, hot times, and traffic patterns. Potentially combining that with demographic information presenting opportunities for hyper-specific targeting.
  • Churn Modelling – Gain insight into app engagement and expected life-cycle of a user and slice with demographic information to find opportunities to identify and address drop-offs for high-value segments.
  • Model Targeting – Conduct cluster analysis to attempt to identify high-value segments consistent in a feature space (e.g. age, monthly spend) to then leverage Facebook, Twitter and Google lookalike algorithms to scale the audience. If there is a high-value core customer we can identify abstract mathematical spaces beyond the reach of demographics.

Pretty cool huh!?!?!

If you are thinking that you need more visibility in your business, but don’t know where to start or don’t have the internal resources feel free to get in touch. We would love to hear from you, and find out if we can help you shine a light on the insights hidden in your business data. Just contact us and let us know more about your requirements and current problems and we’ll get in touch.

Can’t wait to hear from you.