Barton Poulson, PhD

Remember that your clients and/or stakeholders care primarily about the actionable insights you can deliver -- what they should start doing, stop doing, or continue doing -- from your analysis. They are less concerned about the intermediate steps, regardless of how much work it took you to get there. (I've done some of my best coding ever in data prep, but it's irrelevant to the client.) And actionable insights are easiest to communicate with the simplest graphs possible: bar charts and line charts. I use them extensively because they're clear and easy to interpret, even for non-data specialists. Put your actionable insights on the same slide as the graph that supports it, and point to the part of the graph that matters. Guide the eyes.

The methods and manner of your exploration will depend in part on whether your goals is to (a) provide actionable insights to human decision makers; or (b) develop a data product that will run (semi-) autonomously. For the first kind, with human decision makers, you will need to explore the data more extensively to see how well it meets the assumptions of your methods, as that will influence the interpretability of your project. For the second kind, a data product, you can use more complicated, even opaque, methods that are able to adapt to quirks in the data but are not readily interpretable, such as random forests or neural networks. As always, you will need to make sure that your data is correctly labeled, but fewer checks are required.

One of the best ways to avoid getting overwhelmed is to have a clear idea of what you're trying to accomplish. Talk with your stakeholders and/or clients to see (If possible) exactly who is going to use the results of your work to do what (and when). That is, what kind of actionable insights are they looking for? Ideally, that will let you focus the question enough that you can write it on a small sticky note and put it on the edge of your computer screen. Once you've done that, only spend time on things that will advance you towards that clear goal of actionable insights.

The data mining world is not static, and new methods will make different kinds of data potentially useful in your products. Even more importantly, data mining is typically performed in commercial settings where competitive advantage is critical. That means that once a method becomes common, it no longer provides the same competitive advantage that it did previously, and newer methods will likely need to be implemented. It's difficult, because there is an element of diminishing returns, but that's why it's important to keep learning. If possible, it helps to keep a journal of things that you've learned (with dates!) so that you can more easily identify code that you wrote before those eureka moments and revisit your work.

One of the great perks of data mining is that you will typically have very large, diverse datasets. The size of those datasets makes it easy to split the data into train-validation-test sets (or, depending on your source, train-test-validation), along with k-fold cross-validation in the training set. While more common in machine learning classification models, this multiple-subset approach is also useful in data mining, as it allows you to check the generalizability of any patterns you may find when data mining. With a large enough dataset, even patterns that exist for only relatively small subgroups in the data should show up reliably with this multiple split approach.

Fundamentally, this is impossible. There is no such thing as an "accurate interpretation" of a dataset, just as there is no such thing as an "accurate interpretation" of a book or a ballet or a landscape. Interpretation is an act of judgment that depends on a million personal and social factors. That said, it's important to avoid bone-headed mistakes, like confusing the mean and the median, positive and negative correlations, and statistical versus practical significance. But those are, at best, necessary but not sufficient conditions for a useful interpretation of the data.