Last month, we published a blog about DOTS Lead Validation, taking a deep dive into the services and core components that make up the building blocks of the service. This blog is designed to be a companion to that one – a Part 2 – taking a step back and looking at how those components fit together, as well as other important parts of the Lead Validation service.
Quick recap on Lead Validation’s components and scoring
In the previous blog, we focused on the core components of Lead Validation: Name, Address, Phone, Email, IP Address, and Business. Each component is analyzed independently using the tools and services previously described. The purpose of these tests is to determine how each given component looks unto itself. For example, if IP Address is being tested, we are looking at things like:
- What is the IP’s location?
- Is it a proxy?
- Is the proxy anonymously hiding the user’s information?
- Is it from a high risk country?
- Is it potentially a bot?
- Is it a mobile device?
After the components have been individually analyzed and scored, they are all cross-checked. Taking the same example of IP Address, we can look for things like this:
- Does the IP’s location seem to match the location of the phone and address?
- Are the IP and email linked?
- Can we connect the IP to a given business?
The final component’s score is based on whether it is valid and whether it matches other components. This means that a failing score for the IP Address component could be either because a major red flag about the IP itself was found, or because it was clearly not a match for the overall lead itself.
The purpose of Lead Validation is to grade leads as a whole, rather than how they are as individual components. There are a few ways to tell why the component was given a failing score, which will be described later in the “Messaging” section.
All components are given the same treatment described for IP Validation, and those component scores (each 0-100) are added together to get an overall score, which is Service Objects’ recommendation for that lead. A bit more detail on this will also be described in the “Test Types” section below.
There are over 200 tests occurring in each run of a lead in Lead Validation, each of which is set to either true or false. Lead scores rise or fall based on passing or failing tests.
Lead Validation’s Test Types
Test types are a critical part of each run through the Lead Validation service. A test type is essentially a set of instructions that tells Lead Validation how to process and score the lead. It tells the service which components to test, which tests to perform and how to weigh and score each component. Components are given influence (the percentage the component contributes to the overall score) and threshold scores for when they are considered Accept, Review or Reject.
Each test is linked to a component and has the possibility of contributing a positive score for a pass and a negative score for a fail. Not all tests have both a positive and negative possibility. For example, taking the test that compares the IP Address and the Business together, it gets a big positive score if we can match them together but does not get a negative score if we cannot. It is a very good sign if we can connect the dots between them, but is not necessarily bad because we cannot, so it does not make sense to penalize for a failed test there.
Test types exist because not all needs are the same. Test types cover most combinations of input data as well as how they should be handled. For example, one user might consistently have Name, Address, Phone but occasionally collect Email. They might want two test types, one to handle Name, Address and Phone and one to handle Name, Address, Phone and Email. In this case they do not want to harshly score a lead for not including Email since they consider it optional. Another user may collect these same fields but while they only occasionally get email, they may want the system to score users lower who do not submit it. So, they would use the test type that expects all four inputs.
There are sets of test types that tell the system to process the lead as a residential lead, penalizing when given business data. There are also sets that tell the system to strictly process the lead as a business, penalizing harshly for residential data. And there are test types that are primarily focused on businesses but allow for residential data, focusing more on success in matching than penalizing because a business lead was given a personal email. There are also test types designed to work better with students. They are a bit harder to score, but students would be potentially more mobile, meaning some of the comparisons testing should be less harsh for mismatches. New test types can easily be added to the system as well as custom test types that are tailored to a specific user’s needs. More on that next.
Customizations and custom test types
There is a wide range of test types available that fit most needs, but sometimes clients have very specific needs, and it may be best in these cases to make a custom test type. Custom test types allow us to tweak everything about the test type, from high level balancing of component influences down to specific test scoring. We analyze requests for specific rules and scoring options to determine if a current public test type is needed, or a new public test type makes sense to create, or if the request is so specific that it just makes the most sense to create a private custom test type for our client.
The types of requests we see are things like:
- I want to automatically fail the lead if any residential data shows up,
- I want to fail any lead that returns a free email (Hotmail, Yahoo, etc.),
- I want to fail any number that is a mobile phone regardless of its match to the lead.
Service Objects works with prospects and clients alike to tune and test specific test types to meet their needs.
In addition to custom test types, Lead Validation is highly customizable. When it makes sense, there is an available set of generic fields called InformationComponents that allows new outputs to be seamlessly added to the service without breaking current integrations. Clients interested in making use of available new InformationComponents can do so at their own pace. We could add something if a new data point becomes available that we cannot fit into the current output structure and is considered a good new fit for the service. Often we are also able to seamlessly add new features via Lead Validation’s Notes messaging system. More on that in the next section.
Messaging and other key data points
The latest and recommended operation of Lead Validation (ValidateLead_V3) contains a new improved messaging system that allows us to easily communicate key messages to our users. These are represented in the outputs by the following field categories: General Notes, Name Notes, Email Notes, IP Notes, Phone Notes and Address Notes.
General Notes contain information specific to the overall lead – primarily the results of various matchings between components. These notes give users a good idea of how well the components connected to each other (or didn’t). The other notes sections (Email, IP, etc.) have more detailed information on specific things we found out about the individual components (both good and bad) and give a good indication of why a high or low score was returned. A complete list of notes for all categories can be found here:
docs.serviceobjects.com/display/devguide/DOTS+Lead+Validation#DOTSLeadValidation-LeadEvaluation
Notes allow us to easily communicate important things we found out about the component. For example, going back to the IP Address component: IsPublicProxy identifies IP Addresses that have potentially been compromised and used fraudulently, IsBadSyntax identifies IP Addresses that do not follow the normal IP format, and IsHighRiskCountryIP identifies IP Addresses coming from countries known to conduct more fraudulent activities. In a soon to be released new build, IsBad and IsGood notes will be added to each component, giving a bird’s eye view of our best guess for the component. These are intended to help users determine if the components themselves are considered good or bad independently of how they fit in with the overall lead.
Other key fields that users can expect to see are:
- A standardized address based on the given address.
- The best fit phone contact we found.
- Locations for relevant components such as IP, address and phone.
- A Lead Type which uses name, email, phone and address to help determine if the given data was more likely tied to a residence, a business or a mix.
- A Lead Country that uses the various locations found by IP, address, phone and email to determine the best country fit for the lead.
- InformationComponents, which do not currently have any results but will in the future.
Conclusion
Hopefully this blog, in conjunction with the previous one, will give you a great overview to Lead Validation and what it can do. If you would like to learn more about Lead Validation, please visit our product page and developer guide.
