WholeLife

Strata Data Conference is where cutting-edge science and new business fundamentals intersect—and merge. It's a deep dive into emerging techniques and technologies. You'll dissect case studies, develop new skills through in-depth tutorials, share emerging best practices in data science, and imagine the future.

Formerly known as Strata + Hadoop World, the conference was created in 2012, when O'Reilly and Cloudera brought together their two successful big data conferences.

Program Chairs Doug Cutting (Chief Architect at Cloudera and founder of Apache Hadoop), Ben Lorica (Chief Data Scientist, O'Reilly), and entrepreneur Alistair Croll have created a program that covers the entire range of big data tools and technologies. Strata Data Conference covers current hot topics like AI and machine learning, and focuses on how to implement data strategies.

The data industry is growing fast, and Strata Data Conference has grown right along with it. We've added new sessions and tracks to reflect challenges that have emerged in the data field—including security, ubiquitous computing, collaboration, reproducibility, new interfaces, emerging architecture, building data teams, machine data—and much more.

Strata is the largest data conference series in the world, yet it’s kept the informal, collegial spirit that makes it one of the best places to connect and collaborate.

Experience Strata Data Conference

What people are saying

Ben Lorica is the chief data scientist at O'Reilly Media, Inc. He has applied business intelligence, data mining, machine learning and statistical analysis in a variety of settings including direct marketing, consumer and market research, targeted advertising, text mining, and financial engineering. His background includes stints with an investment management company, internet startups, and financial services.

Data-driven product development doesn’t have to be scary and it doesn’t have to be all-in. There are a lot of ways that using data to build and grow our product is going to add to the bottom and top line, all without having to hire a data science team.

If an organization isn’t using data to develop and grow its products, then its days are probably numbered.

But while everyone talks about data, rarely does anyone explain what to do with all of it. So companies wind up skipping a data-driven approach because there isn’t any time. Or they use data incorrectly and get a false sense of potential success. Or they go totally data-driven and leave the human element out.

Let’s fix that, because every new product, every new feature, every growth experiment, should be using data to make decisions.

Data Science Is Not Rocket Science

The science of data is made out to be far more intimidating than it really is. It’s also overhyped as a kind of nerd quest that will make selling tons of product as simple as punching a magic algorithm into a computer.

The truth is it’s easier than ever to collect, analyze, and react to data — from sales data to performance data to marketing data.

Get Started: It doesn’t matter where you get your data or how you track it

I’ve been building products with data since 1999 — before Google Analytics, before Hubspot, before anyone had an API. I’ve gotten it pretty much down to a science at this point, and I can get a decent data analysis out of a rock and some string like MacGyver.

Right now, as you’re reading this, I’m using data to build two completely different product lines. One uses a lot of data, the other uses just a little. I’m going to use each of these as examples in the hopes that you can find your happy data place somewhere in the middle.

In the first scenario, let’s call it the “Lite” scenario, all I’ve got is a collection of unrelated web pages that show me basic usage stats. But one of those stats is revenue, and when I have revenue, I have the one single truth. I can trace everything else back to dollars.

I’ve got no APIs, so what I have to do is check in regularly to get daily, weekly, and monthly stats, plus any reference points I want to track for any experiments I want to run. All of this goes into one massive spreadsheet with a dozen tabs.

It’s not automated. At all. But once I have the structure down, all it takes a few minutes to maintain it. Plus it’s fun. I geek on this shit.

In the second scenario, the “Heavy” scenario, I’ve got a software platform that cost millions of dollars to build and is constantly being developed, upgraded, and maintained by a team of excellent software engineers. Everything is in the cloud, it’s totally flexible, APIs everywhere, and it even has a replicated read-only database that I can hit with SQL in real time and not screw everything up.

In the Heavy scenario, all I need to do is fire up something like TablePlus or SQL Server Management Console and run stored SQL statements to generate reports.

Data Day!

In both scenarios, I have a weekly Data Day. That’s when I spend an hour or two aggregating all my data and running analysis on every bit of it — which I’ll describe over the rest of the post.

In the Lite scenario, I’m logging into various websites and copying the most recent numbers into the spreadsheet. I don’t get revenue until the end of the month, so I’m doing a lot of extrapolating as to what that dollar figure will be so I can grade performance continually in “real time.” Then I have a monthly Revenue Data Day when I get the revenue numbers.

In the Heavy scenario, I’m getting revenue in real time, so I get to spend much more time on analysis.

Sales Data: Getting more revenue

The first set of data I look at is sales. I total the entire revenue number first to get a sense if this was a good week or a bad week or an inconclusive week. This will color the rest of my analysis, dictating if I’m looking for problems or opportunities or both. If any number is way off, I’ll skip down to the end and do Forensics, then come back.

The next thing I want to understand is where those sales came from, so I trace the revenue back as far as I can by using the data to answer these questions:

Then I take all of the breakdown and use it to confirm or adjust my goals for the month, the quarter, and the year.

I get the results of all this analysis to discuss with the executive team. If we need initiatives to adjust our focus, we use this analysis as our guide.

Performance Data: Increasing revenue and margin at the same time

The next step is to compare productivity against revenue to get performance. I need to confirm where we’re strong, where we’re weak, and that we’re burning efficiently as we grow.

These are like long-term growth experiments, except I’m looking at things we’re already doing and customers we already have. I’m looking for patterns in their usage that give me hints as to which features and which customers we should be focusing on.

This analysis sets up a lot of the Growth Experiments I’ll be going over next.

For example: At Spiffy, my performance data analysis led me to discover that a good number of our customers were declining a suggested and needed upgrade during their service, but then they’d add the same upgrade the next time they booked their service. We were missing some of those upgrades, right? The ones who forgot about it. So that led to an experiment to prompt those customers to add the upgrade when they book their next service so they won’t forget.

Growth Experiments: Expanding market share by building a better product

The experiment I mentioned just now is one of the most basic I can run. The likelihood is very high that the experiment will succeed, but we’ll test it first anyway because you never know what you’ll find out.

On the other end of the spectrum, I’m also in the middle of testing a new product offering with a large corporate partner that has much broader implications and is a lot trickier. More reward, more risk, same analysis.

I can use the same set of sales and usage data for most of the growth experiments I want to run.

To run these experiments, I narrow down a customer segment, in this case by location. The size of the sample should be small enough to not be painful if we mess up, but large enough to matter. In fact, I’ve already had to add locations because the sample size wasn’t statistically significant. Then I run the experiment.

I usually check in on growth experiments daily or even a couple times a day in the beginning, to flesh out facts like my sample size is too small. Then I try to get to success or failure as quickly as possible.

Marketing Data: Creating new customers using the same value proposition

While all the previous data analysis is about increasing the size of our market, marketing data analysis is about increasing the size of our megaphone to the market.

For the Heavy scenario, we’ve got Hubspot and MailChimp and Google Analytics and all the social media accounts and everything is integrated and automated. In the Lite scenario, I’m just grabbing metrics from the ad server and from Google Analytics and throwing them in one of the spreadsheets. Google’s reports leave a lot to be desired, so I do it myself.

Marketing data analysis is actually just another review of the sales and performance data, but this time I go all the way back to first interaction, or where the customer first became aware of the product offering. I’m looking at impressions, email opens, click-throughs, and conversions, all compared to ad spend. I’m adding the cost of acquiring the customer to the cost of serving the customer.

The main difference with this analysis is that if marketing data is telling me to change something, that usually means changing either the marketing channel or the messaging or both. It’s only in rare cases that marketing data analysis leads to a product change, usually when my customers are confirming a hunch I already had from doing all the prior analysis.

With marketing data, I’m also running experiments, but these are growth hacking experiments, not growth experiments. They’re A/B testing offers, discounts, and messaging. They’re varying the channels, the audience, and the spend. But it all eventually ties back to sales and revenue.

Forensics: Chasing down problems and issues

Forensics is the special projects part of Data Day. When I start to see patterns I like or I don’t like, especially when I don’t like, I pull the corresponding data and comb through it to figure out what to do.

This usually means drilling down to and eventually combing through individual records— maybe single transactions, or customers, or product specs, or even code.

For example: In the Heavy scenario, we noticed anecdotally that chargebacks were becoming an issue. We didn’t have any idea where the spike came from, so I spent a couple hours at the end of a data day pulling transaction data that correlated to chargeback data and drilling down into the individual transactions themselves.

Turns out it was a combination of a single product, a single feature, and a couple customers exploiting a loophole. Rather than spend thousands of dollars on sophisticated software to sniff out bad actors with machine learning, we just closed the loophole. Problem solved.

When I think about saving thousands of dollars with a few hours of data analysis, it almost overshadows all the additional revenue these product changes generate without the days and weeks of guesswork trying to figure out how to grow.

חיים שלמים

O'Reilly Strata Data Conference 2019