SYSTEM FOR DETERMINATION OF POTENTIAL CUSTOMER STATUS

- Mariana

A system is described which accepts corporate and employee data from an interested company and a prospective company, and calculates a probability that the prospective company will form a successful relationship with the interested company and generate campaign data for companies for those prospective companies

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description

This application is a continuation of “A System for Determination of Potential Customer Status”, Application No. 62/502,706, Filed on May 7, 2017 and continuation in part of “A System for Semantic Determination of Job Titles”, application Ser. No. 15/968,751, filed on May 2, 2018.

FIELD OF THE INVENTION

The present invention generally relates to the analysis of corporate data to generate campaign data for a company based on whether or not a company is likely to have a successful relationship with another company.

Marketing systems send out requests to companies to try to form relationships based on very limited data; this could be based on being in a certain industry, a personal referral or just a guess.

In the prior art, companies may use rules based on expert analysis. For instance, a point-based system which add points if someone opens an email from the company, or based on headcount ratios such as manager to engineer ratio.

There is a lot of data available for public companies, but no reliable way to determine whether or not a relationship has a chance to succeed.

What is needed is a system for determining the probability of a successful relationship between companies, and to quantify that probability in such a way that a company can determine how much effort to put into such a relationship.

SUMMARY

A system is described which accepts corporate and employee data from an interested company and a prospective company, and calculates a probability that the prospective company will form a successful relationship with the interested company.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a workflow of how the system is trained.

FIG. 2 shows a workflow of how the system predicts whether a relationship could occur.

FIG. 3 shows one embodiment of the network used to train and predict the relationship.

FIG. 4 shows one or more embodiment of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

With regard to this invention, the term “business relationship” is an agreement between two business entities to cooperate with each other where one company would sell products and/or services to the other.

With regard to this invention, the term “interested company” is a business entity that is interested in forming a business relationship with another company.

With regard to this invention, the term “prospective company” is a second business entity that the interested company is interested in forming a relationship with.

With regard to this invention, the term “structured data” refers to information that is characterized based on predefined groups. Each of these predefined groups are associated with a string value unique to that type of structured data called a label. For instance, size of a company can be characterized as predefined groups of sizes, such as 201-500 employees. In one embodiment, the label might be “201-500 employees”. In another embodiment, the label might be “mid-sized company”.

With regard to this invention, the term “unstructured data” refers to information that is not characterized as an individual value. An example of this would be the text in a job description, where the analysis leverages the text and the sequence that the text occurs.

With regard to this invention, the term “one-hot encoded” refers to a coding of structured data as a group of all possible values in a pre-determined sequence that are either coded as 1 or 0, such that only the one correct value can be a 1. For example, if there were 5 possible size groups and the company was associated with the third group, the coding would be 00100.

With regard to this invention, the term “n-hot encoded” refers to a coding of structured data as a group of all possible values in a predetermined sequence that are coded as either 1 or 0, such that the entity can have zero or more values associated with it. For example, if you had to describe a value which can have multiple values, such as a set of technologies that the company uses on its' website. If there were a total of 5 possible technologies and the company used the first and fourth one, the coding would be 10010.

With regard to this invention, the term “employee profile” includes data about the employee. The data includes direct information, such as a resume. The data also includes indirect information, such as a job description associated with the employee's role in the company.

In one or more embodiments, the system comprises of a computer, the computer containing software configured to accept data about a prospective corporation. The software is also configured to accept a neural network model which can process the data about the relationship between the interested and prospective companies. The coefficients associated with the neural network model are configured by processing training data to define its parameters. The training data comprises data about one or more companies where the relationship between the interested and one or more prospective companies is known. The neural network comprises one or more stages, each subsequent stage accepting data from a prior stage. In one or more embodiments, the neural network model is configured to be a convolutional neural network (CNN). In other embodiments, the neural network model is configured as a Long Short Term Memory (LSTM) architecture.

One embodiment of the invention, as shown in FIG. 4, comprises a computer 402. The computer is configured with a Transfer API module 426, the Transfer API module configured to accept data from at least a UI module 404, a Data Crawl module 414, a Partner Dump module 418, and a Data API module 420. The Transfer API 426 accepts data from the Data Crawl Module 414, Partner Dump Module 418, and Data API module 420 and stores them in a Raw Data Store 422 and a Customer Data Store 412. In one or more embodiments, the Raw Data Store 422 is configured to accept raw structured and unstructured data, which is data which comes either from partners or from web scraping. In one or more embodiments, the Customer Data Store 412 is configured to accept data directly from interested companies, including data about prospective companies. In one or more embodiments, the data in the Customer Data Store 412 is partitioned, so that only information about the interested company is used to model for that interested company. The computer 402 is also configured with a training module 406, the training module 406 coupled to the computer and configured to accept data from the Raw Data Store 422 and the Customer Data Store 412 and generate prediction model parameters which are stored in the Prediction Data Store 408. The computer is also configured to store model data in a Model Data Store 410. The Model Data Store 410 contains the parameters of the model associated with an interested company.

The computer is also configured with a Prediction Module 428, the prediction module configured to accept the prediction model parameters from the model data store for an interested company and generating an output for each new prospective company in the prediction data store 408. The prediction data store 408 is then used by the Campaign API Module 424 to generate the proper messages to such marketing tools as Twitter, Google Ads, Facebook Ads.

In one or more embodiments, the UI Module 404 is coupled to the computer, configured to request and accept data from one or more sources using one or more implementation of a REST API. Information from these REST API calls are saved to the Customer Data Store 412.

In one or more embodiments, the Partner Dump Module 418 is coupled to the computer, configured to accept data from various partners in formats not limited to but including comma-separated variable (CSV), JavaScript Object Notation (JSON), or text files. The data is then extracted from the files and saved to the Raw Data Store 422.

In one or more embodiments, the Data Crawl Module 414 is coupled to the computer, configured to accept html data from one or more specified web sites. Information from the html data is then extracted and output to the Customer Data Store 412.

In one or more embodiments, the Data API Module 420 is configured to request and accept data from one or more sources via an API. In one or more embodiments, this includes but is not limited to the ZoomInfo API (http://www.zoominfo.com/business/zoominfo-new-api-documentation as seen on May 6, 2017).

In one or more embodiments, the Semantic Indexing module 416, coupled to the computer, is configured to store company and people information in such a way that a request for specific company or people data can be executed by searching the embedding data or the vector. The company information is stored as the output of the concatenation step in the training module 326. As the embedding is semantic, this type of query will identify similar companies and people. In one or more embodiments, the Semantic Indexing Module 416 accepts requests to find other companies similar to the prospective company being analyzed. In one or more embodiments, the Semantic Indexing Module 416 accepts requests to compare two prospective companies to find differences in their index values. For instance, this can be used if two similar companies give very different results in their predictions of successful relationships.

The Training Module 406, coupled to the computer, is configured to accept the model data in the Model Data Store associated with prospective companies which already have known relationships with an interested company. The Training Module 406 generates a neural network model which is initialized as a new model would be initialized, usually with randomized weights. Further, the neural network associated with the training module 406 includes back propagation of the weights to improve the model with each input. The model parameters of the model created by the Training Module 406 is stored in the Model Data Store 410. These model parameters are used by the Prediction Module 428, which does not change the weights using back propagation.

In one or more embodiment, the Campaign API 424, coupled to the computer, is configured to accept Prediction Data and generate a campaign strategy which outputs via one or more APIs, including but not limited to Twitter Ads API, Google Ads API, Facebook Ads API, and Marketo API.

FIG. 3 shows how the parameters associated with a company are processed. There are four types of input associated with each company. Industry group 302, company size 304, employee profiles 306, technology used by the company 308, news associated with the company 336, and Intent Data 344.

A company is defined as part of this model to be part of a single industry group 302, from a pre-defined list of industries. The result is a one-hot encoded value 310. In one or more embodiments, this value is pre-determined by an expert. In other embodiments, a reference guide can be used. In other embodiments, the Industry group 302 is implicit in the model based on the output of the concatenate state 326, and is not directly input into the model.

A company can be described by its' size 304. In one or more embodiments, a company's size can be based on a measure of the number of employees. In one or more embodiments, a company's size can also be measured by revenue. Company size is structured data because the data is bucketized; so rather than storing the actual number of employees or dollars of revenue, the value is one-hot encoded 312 to be one of several categories (i.e., 100-200, 201-500 employees). In one or more embodiments, the category values are pre-determined based on provided corporate data.

In one or more embodiments, hiring practices include a measure of executive churn, and number of employees hired over a given period of time. In one embodiment, the measure is based on executive turnover ratio. In one or more embodiments this ratio can be categorized by rank. For instance 1/1 CEOs replaced, 0/1 CFOs replaced, 2/10 C-suite executives replaced. In other embodiments, skills and title vectors could be calculated based on recently departed employees above a certain rank. In other embodiments, more weight could be given in the calculation to higher ranked employees as well as weighing more recent departures vs earlier departures.

In one or more embodiments, use of social media is characterized by frequency of use of one or more corporate accounts. In one or more embodiments, corporate accounts could be an aggregation of official company accounts and those owned by “C” level managers, such as a CEO or CTO. In one or more embodiments, the data is run through an LSTM process, where one word from a post would represent a single data point, where the output of that seeks to understand each post in succession as part of the total social media stream. In another embodiment, doc2vec or a similar piece of software is used to characterize the social media posts.

In one or more embodiments, intent data 344 is “data about business users web content consumption” (bombora.com, Apr. 5, 2017). In one or more embodiments, the intent data 344 is aggregated based on a categorization of the type of interaction with employees of a prospective company. This measure includes, but not limited to, requests for literature or watching a webinar. In other embodiments, it is characterized by the number and frequency of corporate IP addresses which go to a particular website. In one or more embodiments, intent data is run through an LSTM process. In other embodiments, a skills vector approach can be used. For example, creating data around each different event which may happen as intent data, such as open mail, click a link or downloading a marketing asset. Each of these are fed successively through an LSTM process, then the output of that goes into another LSTM which understands the successions of actions and summarizes it. Finally the output of that process is fed in as an actions vector for concatenation.

In one or more embodiments, the intent data 344 is stored in such a way to provide a measurement of the relationship between the person or persons who initiated it and what was initiated, and when. In other embodiments, the intent data could be stored to provide a measurement of the relationship between the particular roles at that company and the intent data.

In one or more embodiments, the interested company provides detailed information about its' people through resumes and job descriptions. This profile information about companies 306 can be found through publicly available repositories such as LinkedIn, or by the response of people to emails, applications to attend webinars or conferences, and so forth. In one or more embodiments, the information about each person is stored in sets of words. In other embodiments, the information about each person can be stored in a term frequency-inverse document frequency (tf-idf) form 318, to reflect how important each word is to a document or a corpus of documents (see https://en.wikipedia.org/wiki/Tf-idf). The results are then normalized to unit length and put through an autoencoder 322 prior to adding it into the concatenate layer 326. In one or more embodiments, this means that the vector is scaled so that it has an L-2 norm of 1. So that [2,0,0] would become [1,0,0] and [0.1, 0.2, 0.3] would become approximately [0.267, 0.534, 0.802]. such that the resultant vector has a length of 1.

The titles associated with employees profiles 306 will vary from company to company, but have some relationship to each other. For instance, a VP of Marketing and Marketing Director would have roughly the same kind of job, even though their titles are different. In one or more embodiments, job title data are input through a single layer LSTM model prior to concatenation. In other embodiments, they are fed through a two-layer LSTM model prior to concatenation.

In one or more embodiments, the skills associated with employee profiles 306 are aggregated and stored as n-hot encoded values of skills 314. That is an aggregation of all of the skills of all of the employees. In one or more embodiments, the analysis of the employee profiles to get the skills information is done using Doc2Vec, which is “unsupervised learning of continuous representations for larger blocks of text, such as sentences, paragraphs, or entire documents” (see https://rare-technologies.com/doc2vec-tutorial/ as seen on Apr. 6, 2017).

In one or more embodiments, how a company uses technology 308 is characterized by what web technologies they use. In one embodiment, this information is gathered by a service which analyzes websites and automatically characterizes technologies used. In one or more embodiments, the technologies used are coded using n-hot encoding 316, each value associated with a different technology like AngularJS, javascript, NodeJS, etc. This is then output as a binary vector of ones and zeros 320, and put through autoencoding 324 prior to concatenating this with the other values 326.

In one or more embodiments, data about what technologies are used 308 in the company, tech installed base, are gathered using a service such as HG Discovery, as described at https://www.hgdata.com/products/ on Apr. 5, 2017. This data can be used to find what technologies are used by a company. This can then be characterized as n-hot encoded values in addition to the n-hot encoded values for the web technologies 316.

News articles 336 about the company are gathered as well. The news articles are characterized by timestamp and a collection of terms. In one or more embodiment, the news article terms are characterized using a tool such as Doc2Vec (see https://rare-technologies.com/doc2vec-tutorial/ as seen on Apr. 6, 2017) 340. The results of this can either be run through an autoencoder 342 or run through an LSTM network after which they are joined to the rest of the inputs through the concatenate layer 326.

An autoencoder is the process of taking a long vector then used to train a dense layer into something much smaller. The network then has a larger network the size of the original vector to predict the original input from this smaller layer (See https://en.wikipedia.org/wiki/Autoencoder as seen on Apr. 17, 2017).

In one or more embodiments, the probability of successful relationship between companies based on the above data can be found using a deep learning network. A deep learning network is an apparatus which enables one to find data patterns in data where none was seen.

In one or more embodiments, the concatenate layer 326 is a wide network layer which accepts all of the inputs from the prior layers associated with each input. In one or more embodiments, this is a single CNN layer.

The layers following the concatenate layer are dense layers with pooling 328, such that the number of nodes in each layer is may be decreasing, stay the same, or increasing in successive layers. This continues until all nodes are attached to the final layer. The final layer is a one-wide dense layer 330, which goes to an activation layer 332. In one or more embodiments, the activation layer is a sigmoid, in others a RELU node. The output of the activation layer is a prediction of whether or not a relationship will work as a probability value between 0.0 and 1.0.

FIG. 1 shows the workflow necessary to train the system using the Training Module 406. The system would accept structured data 102 and unstructured data 104 to characterize both the interested and prospective companies. The system would also accept the known relationship data between the interested and prospective companies 106. The data is fed into the model 108 and the model is trained. The resultant model parameters or weights associated with each node 110 are stored for later use.

FIG. 2 shows the workflow necessary to evaluate the relationship between an interested company and prospective company after the model was trained on companies with known relationships with the interested company using the Prediction Module 428. Structured data is collected associated with the prospective company as described previously 202. Unstructured data is collected associated with the prospective company as described previously 204. The model parameters are set as determined by the trained model for the interested company in FIG. 1 208. The input data is fed into the trained model 206 in the Training Module 406. The input data is then processed in the trained model 210, and the prediction as to whether or not a relationship would work is output from the model 212.

Claims

1) A system for generating a marketing campaign based on relationship data between an interested company and a prospective company, the system comprising:

a computer,
a UI module, coupled to the computer, configured to accept and request data from one or more external data sources,
a Raw Data Store module, coupled to the computer and the UI module, configured to accept structured or unstructured data in various standard data formats such as Comma Separated Variable and JSON and save the data,
a Customer Data Store module, coupled to the computer, configured to accept data from interested companies including data about prospective companies,
a Transfer API module, coupled to the computer and the UI module, configured to accept data from the UI module and store the information in the Raw Data Store module,
a training module, coupled to the computer, configured to describe a neural network, configured to accept corporate data and relationship data, calculate a set of coefficients for the neural network from the company and relationship data, and store the coefficients into the storage module,
a Semantic indexing module, coupled to the computer, configured to accept company information from the training module, configured to accept requests to compare two prospective companies,
a Prediction module, coupled to the computer, configured to accept prediction parameters from the storage module and generate an output for each prospective company in the storage module, and
a Campaign API module, coupled to the computer, configured to accept output for each prospective company and outputs to marketing tools such as Twitter, Google Ads and Facebook Ads.

2) The system in claim 1, further comprising a Data Crawl Module, the Data Crawl Module coupled to the computer, the Data Crawl Module configured to accept html data from one or more web sites, to extract information from those web sites and store the information in the Customer Data Store.

3) The system in claim 1, further comprising a Data API Module, the Data API Module coupled to the computer, the Data API module configured to accept data from one or more sources via an internet API such as the ZoomInfo API.

4) The system in claim 1, further comprising a Partner Dump Module, the Partner Dump Module coupled to the computer, the Partner Dump module configured to accept data from various partners and store said data in the Raw Data Store.

5) A method for generating a marketing campaign between an interested company and a prospective company, the method using:

a computer,
a UI module, coupled to the computer, configured to accept and request data from one or more external data sources,
a Raw Data Store module, coupled to the computer and the UI module, configured to accept structured or unstructured data in various standard data formats such as Comma Separated Variable and JSON and save the data,
a Customer Data Store module, coupled to the computer, configured to accept data from interested companies including data about prospective companies,
a Transfer API module, coupled to the computer and the UI module, configured to accept data from the UI module and store the information in the Raw Data Store module,
a training module, coupled to the computer, configured to describe a neural network, configured to accept corporate data and relationship data, calculate a set of coefficients for the neural network from the company and relationship data, and store the coefficients into the storage module,
a Semantic indexing module, coupled to the computer, configured to accept company information from the training module, configured to accept requests to compare two prospective companies,
a Prediction module, coupled to the computer, configured to accept prediction parameters from the storage module and generate an output for each prospective company in the storage module, and
a Campaign API module, coupled to the computer, configured to accept output for each prospective company and outputs to marketing tools such as Twitter, Google Ads and Facebook Ads,
the method comprising:
accepting structured and unstructured data from external data sources about interested and prospective companies,
training a neural network based on structured and unstructured data using companies with known relationships with the interested company and generating sets of coefficients,
comparing prospective companies with the interested companies based on the neural network coefficients, and
generating campaign data for those prospective companies.
Patent History
Publication number: 20180322537
Type: Application
Filed: May 3, 2018
Publication Date: Nov 8, 2018
Applicant: Mariana (San Mateo, CA)
Inventors: Justin Driemeyer (San Carlos, CA), Soumyadeb Mitra (San Jose, CA), Abishek Kashyap (San Jose, CA), Arunim Samat (San Francisco, CA), Venkat Nagaswamy (San Francisco, CA), Solomon Fung (San Francisco, CA)
Application Number: 15/969,781
Classifications
International Classification: G06Q 30/02 (20060101); G06N 3/08 (20060101); G06Q 10/06 (20060101); G06F 17/30 (20060101);