When data analytics uses simple formulas, much conjecture and an arbitrary methodology, it often fails in what it was designed to do —give accurate answers to pressing questions.
So, at Majesco, we pursue a proven data science methodology in an attempt to lower the risk of misapplying data and to improve predictive results. In Methods Matter, Part 1, we set the stage for explaining the Majesco Data Science Project Lifecycle. The goal is to give insurance organizations a picture of the methodology that goes into data science. We discussed CRISP-DM and the opening phase of the life cycle, project design.
In Part 2, we will be discussing the heart of the life cycle — the data itself. To do that, we’ll take an in-depth look at two central steps: building a data set, and exploratory data analysis. These two steps compose the phase that is extremely critical for project success, and they illustrate why data analytics is more complex than many insurers realize.
Building a Data Set
Building a data set, in one way, is no different than gathering evidence to solve a mystery or a criminal case. The best case will be built with verifiable evidence. The best evidence will be gathered by paying attention to the right clues.
There will also almost never be just one piece of evidence used to build a case, but a complete set of gathered evidence — a data set. It’s the data scientist’s job to ask, “Which data holds the best evidence to prove our case right or wrong?”
Data scientists will survey the client or internal resources for available in-house data, then discuss obtaining additional external data to complete the set. This search for external data is more prevalent now than previously. The growth of external data sources and their value to the analytics process has ballooned with an increase in mobile data, images, telematics and sensor availability.
A typical data set might include, for example, typical external sources such as credit file data from credit reporting agencies and internal policy and claims data. This type of information is commonly used by actuaries in pricing models and is contained in state filings with insurance regulators. Choosing what features go into the data set is the result of dozens of questions and some close inspection. The task is to find the elements or features of the data set that have real value in answering the questions the insurer needs to answer.
In-house data, for example, might include premiums, number of exposures, new and renewal policies and more. The external credit data may include information such as number of public records, number of mortgage accounts, number of accounts that are 30-plus days past due, among others. The goal at this point is to make sure that the data is as clean as possible. A target variable of interest might be something like frequency of claims, severity of claims or loss ratio. This step is many times performed by in-house resources, insurance data analysts familiar with the organization’s available data or external consultants.
At all points along the way, the data scientist is reviewing the data source’s suitability and integrity. An experienced analyst will often quickly discern the character and quality of the data by asking, “Does the number of policies look correct for the size of the book of business? Does the average number of exposures per policy look correct? Does the overall loss ratio seem correct? Does the number of new and renewal policies look correct? Are there an unusually high number of missing or unexpected values in the data fields? Is there an apparent reason for something to look out of order? If not, how can the data fields be corrected? If they can’t be corrected, are the data issues so important that these fields should be dropped from the data set? Even further, is the data so problematic that the whole data set should be redesigned or the whole analytics project should be scrapped?
It shouldn’t be overlooked that there is more value in identifying problematic issues early, than in a completed data science project where inaccurate or incomplete data was used. Scrapping data sets or even whole projects at this point will save wasted time and effort.
Once the data set has been built, it is time for an in-depth analysis that steps closer toward solution development.
Exploratory Data Analysis
Exploratory data analysis takes the newly minted data set and begins to do something with it — “poking it” with measurements and variables to see how it might stand up in actual use. The data scientist runs preliminary tests on the “evidence.” The data set is subjected to a deeper look at its collective value. If the percentage of missing values is too large, the feature is probably not a good predictor variable and should be excluded from future analysis. In this phase, it may make sense to create more features, including mathematical transformations for non-linear relationships between the features and the target variable.
For non-statisticians, marketing managers and non-analytical staff, the details of exploratory data analysis can be tedious and uninteresting. Yet they are the crux of the genius involved in data science project methodology. Exploratory data analysis is where data becomes useful, so it is a part of the process that can’t be left undone. No matter what one thinks of the mechanics of the process, the preliminary questions and findings can be absolutely fascinating.
See Also: The Science (and Art) of Data, Part 1
Questions such as these are common at this stage:
- Does frequency increase as the number of accounts that are 30-plus days past due increases? Is there a trend?
- Does severity decrease as the number of mortgage trades decreases? Do these trends make sense?
- Is the number of claims per policy greater for renewal policies than for new policies? Does this finding make sense? If not, is there an error in the way the data was prepared or in the source data itself?
- If younger drivers have lower loss ratios, should this be investigated as an error in the data or an anomaly in the business? Some trends will not make any sense, and perhaps these features should be dropped from analysis or the data set redesigned.
