Patent ID: 12205138

DETAILED DESCRIPTION

Embodiments of the invention will now be described with reference to the accompanying figures, wherein like numerals refer to like elements throughout. The terminology used in the description presented herein is not intended to be interpreted in any limited or restrictive manner, simply because it is being utilized in conjunction with a detailed description of certain specific embodiments of the invention. Furthermore, embodiments of the invention may include several novel features, no single one of which is solely responsible for its desirable attributes or which is essential to practicing the invention herein described.

I. Overview

The present disclosure relates to test environment for planning strategies for direct marketing campaigns. As used herein, a “strategy” refers to a set of selection criteria, also known as selection rules that may be used to form a query for execution on a database of records regarding prospective recipients of a direct marketing offer. The strategy may thus identify one or more attributes associated with the records that may be combined, often in a very complex query, to identify a desired subset of the records in the database.

One example of a database that may be suitable for identifying prospective recipients of a direct marketing offer can be one or more databases of consumer information available from a credit bureau. Such credit bureau databases may comprise both credit-related and non-credit related data, such as demographic data, data from public records, and the like. In addition to credit bureaus, other business entities may provide access to suitable databases of consumer information, that may comprise credit-related and/or non-credit related data.

One example of a direct marketing campaign offer is a firm offer of credit, for which campaign offer recipients may be identified using both credit-related and non-credit related data about consumers. Another example of a direct marketing campaign offer is an offer that is not a firm offer of credit, known as an “Invitation to Apply” (ITA) offer, which may be based on non-credit-related data alone. The systems and methods described herein are contemplated as also being useful for identifying recipients of other types of direct marketing offers that may be based on any of a variety of other types of data. Although, for ease of description, the systems and methods disclosed herein are frequently described as being performed on a credit bureau database and as providing a database environment in which clients can use credit-related data for planning direct marketing campaigns, it is to be understood that, in various embodiments, the campaigns may be planned using either credit-related data, non-credit-related data, or both. Furthermore, the environment may be provided by a credit bureau or other entity providing access to consumer data.

Previous test environments for planning direct marketing campaigns using credit bureau data frequently included a full custom-built copy, known as a “full snapshot” or “100% snapshot,” of the credit database from which consumer names for the final direct marketing campaign are selected. Tasks performed in the 100% snapshot may include some or all of: analysis and campaign development, campaign set-up, audit and reporting on campaign logic, receiving client approval to proceed, and execution of the full direct marketing campaign. Since a credit bureau database may include records for hundreds of millions of consumers, building such a full copy of the database typically involves a significant lag time between initiation of the database snapshot building process and availability of the snapshot of use in testing. Thus, freshness of the data used may be compromised by the time testing begins. This lack of data freshness may be exacerbated when the data in the source database is itself lacking in freshness, due, for example, to infrequent updates.

The lack of data freshness is yet further exacerbated when a direct marketing campaign developer, desiring to test and refine campaign strategies, must submit every new refinement of the campaign selection criteria to a credit bureau representative for running on the credit bureau database and must wait for a credit bureau representative to report on the results. The interjection of a third party into a campaign developer's refinement of a campaign strategy frequently makes the process inordinately cumbersome and time-consuming.

Furthermore, lenders frequently desire to include proprietary data of their own and proprietary attribute definitions for use with the credit bureau data in campaign testing, refining, and finally, execution. The desire to include multiple data sources, including proprietary data for those who can afford the investment, frequently leads to building a proprietary test database for the lender's private use. A proprietary database or snapshot is not only an extremely expensive and time-consuming proposition, both to build initially and to update, but also typically yields a database with data that is out-of-date by the time the database is used for testing and finally executing the campaign strategy.

On the other hand, using a snapshot of a database that is updated very frequently and that cannot be used and stored for re-use during the development of a campaign lessens a campaign developer's confidence that differences in campaign test results obtained from various test runs are the result of changes in the campaign's selection strategies and are not simply, in part or in total, the result of changes between the various snapshots.

Systems and methods are disclosed herein for providing a direct marketing campaign planning environment, such as for marketing campaigns directed to consumers identified using a credit-related database system. Frequently, business entities carrying out a direct marketing campaign first identify a desired set of recipients for one or more marketing offers associated with the campaign, and contact the identified recipients, such as via mail, telephone, email, or the like, with the marketing offer.

For purposes of the present disclosure, a “testing” phase is described in which the business entities may repeatedly test and refine a set of selection criteria for identifying consumers expected to be good prospects for a marketing campaign using a sample database that is a copy of a portion of a large database of consumer records. Once a satisfactory set of selection criteria is obtained, an “execution” phase includes using the selection criteria on the large database of consumer records to identify consumers to be recipients of the direct marketing offer. In some embodiments, contact information for the identified consumers may also be provided. In some embodiments, execution may further comprise using the contact information to contact the identified consumers with the direct marketing offer, and may further include tracking consumer response to the direct marketing campaign.

II. Architecture

FIG.1Aillustrates one embodiment of a system for planning and executing a direct marketing campaign. As depicted inFIG.1A, the system100may comprise a consumer data warehouse110, which is communication with a credit-related database102, and a sample database140. In preferred embodiments, the system100comprises one or more server systems (typically comprising multiple physical computers/machines) and associated content that are accessible to a plurality of client computing devices101via a network103. The system100can be implemented using physical computer servers that are geographically co-located or that are geographically remote from one another. The system100may in some embodiments, include content that spans one or multiple internet domains.

The credit-related database102may be configured to receive, update, and store vast amounts of data. For example, in one embodiment, a credit bureau uses the credit-related database102for storing data received from a variety of sources for approximately three hundred million consumers. Such data may include, for example, demographic information, credit-related information, and information available from public records. Some or all of the data may be used, among other purposes, to calculate credit scores for the consumers.

The consumer data warehouse110may be configured to store a copy or near-copy of the data in the credit-related database102. In various embodiments, a copy of data from the credit-related database102is periodically extracted and reconfigured for updating the consumer data warehouse110. For example, data from the credit-related database102may be processed by a set of ETL (Extract, Transform Load) servers before being transmitted to the consumer data warehouse110.

After the data has been transformed by the ETL servers, the data may be loaded to the consumer data warehouse110, such as by way of a high speed server interconnect switch that handles incoming and outgoing communications with the consumer data warehouse110. As one example, the high speed interconnect switch may be an IBM SP2 switch. In other embodiments, Gig Ethernet, Infiniband, and other high speed interconnects may be used.

Embodiments of an architecture for the consumer data warehouse110may be implemented using a Massively Parallel Processing (MPP) hardware infrastructure. In one embodiment, IBM AIX pSeries servers (8-way p655) may act as the MPP building blocks of the consumer data warehouse110. In other embodiments, other types of servers may act as the MPP building blocks of the system, for example, Linux servers, other types of UNIX servers, and/or Windows Servers. A similar architecture could also be implemented using Symmetric Multi-Processing (SMP) servers, such as IBM P690 32-way server or HP Superdome servers.

In preferred embodiments, a relational database management system (RDBMS), such as a DB2 EEE8.1 system, manages the data in the consumer data warehouse110.

The system100can also include a sample database140that stores a temporary copy of a portion of the data in the consumer data warehouse110, as will be described in greater detail below. The sample database140can serve as an environment in which one or more clients may test, refine, and/or validate a proposed marketing campaign before executing the campaign on the full consumer data warehouse110.

FIG.1Afurther illustrates typical client components for accessing the system, in accordance with some embodiments of the invention. As depicted in this drawing, one or more clients can use a general purpose computer or computing device101with access to a network103to access the system100.

For example, one or more of the computing devices101may be a personal computer that is IBM, Macintosh, or Linux/Unix compatible. In one embodiment, the client computing device101includes a central processing unit (CPU), which may include a conventional microprocessor. The computing device101further includes a memory, such as random access memory (RAM) for temporary storage of information and a read only memory (ROM) for permanent storage of information, and a mass storage device, such as a hard drive, diskette, or optical media storage device.

The client computing device101may include one or more commonly available input/output (I/O) devices and interfaces, such as a keyboard, mouse, touchpad, and printer. In one embodiment, the I/O devices and interfaces include one or more display device, such as a monitor, that allows the visual presentation of data to a user. More particularly, a display device provides for the presentation of GUIs, application software data, and multimedia presentations, for example. The client computing device101may also include one or more multimedia devices, such as speakers, video cards, graphics accelerators, and microphones, for example.

The network103may comprise one or more of a LAN, WAN, or the Internet, for example, via a wired, wireless, or combination of wired and wireless, communication link that may be configured to be secured or unsecured.

As further illustrated inFIG.1A, the computer101of the client can run a campaign management tool125and business intelligence tool126. The campaign management tool125and business intelligence tool126can be configured to perform research and analysis functions associated with testing and refining the proposed direct marketing campaign.

Although the credit-related database102and the client computing devices101have been depicted inFIG.1Aas being external to the system100, in other embodiments, one or more of the credit-related database102and/or the client computing devices101may be provided as part of the system100, in which cases, communications may take place using one or more internal communications systems. Additionally or alternatively, rather than being a copy of the credit-related database102, the consumer data warehouse110may receive update data, including, but not limited to demographic information, credit-related information, and/or information available from public records, directly from other sources.

In some embodiments, clients120may access the consumer data warehouse110and/or may run campaigns directly rather than via the project manager130.

FIGS.1B1,1B2, and1B3are high level block diagrams depicting embodiments of a campaign testing and executing system100that improve campaign testing and refining capabilities.FIG.1Bshows howFIGS.1B1,1B2, and1B3can be combined to form a single high level block diagram depicting one embodiment of the campaign testing and executing system100. The campaign testing and executing system100may be used, at least in part, by lenders, other providers of credit services or other business entities, and/or marketers working on their behalf (referred to, for purposes of this disclosure, as “clients”120) who wish to use data available from one or more credit bureaus or other provider of consumer data to help identify consumers who may be interested in the services of the clients.

In various embodiments, the campaign testing and executing system100may be implemented using a variety of computer hardware and software resources. For example, computer servers, such as web servers, database servers, campaign management tool servers, and business intelligence tool servers, as well as direct access storage device (DASD) capacity accessible by one or more of the above-described types of servers are used in various embodiments. Furthermore, associated software, such as cluster multi-processing software, campaign management software, business intelligence software, network communications software, and database management software (such as DB2, Oracle, or Sybase, for example) can also be used.

In the embodiments depicted inFIGS.1B1,1B2, and1B3, a consumer data warehouse110includes data about millions of consumers. In particular, data in the consumer data warehouse110may be a copy or near-copy of data from the database of credit-related data102, which is used for calculating consumer credit ratings, among other uses, and which is updated daily or more frequently. The data in the consumer data warehouse110may be organized so as to make batch processing of the data more expedient and may be updated from the database of credit-related data102that is used for calculating consumer credit ratings on a regular, preferably frequent, basis, so that data in the consumer data warehouse110includes up-to-date changes in the consumers' records. In a preferred embodiment, the consumer data warehouse110is updated twice weekly.

In the consumer data warehouse110, the data may be organized generally as records of data for each consumer. Each record may be divided conceptually into attributes associated with each consumer. Examples of demographic, credit, or custom attributes that may be useful to clients120wishing to identify potential customers may include, but are not limited to: number of credit cards held by the consumer, total available credit, total current balance, number of late payments within the last year, number of late payments within the last three years, no tradelines, and the like. In addition, some attributed may be derived from other attributes, such as but not limited to derived attributes that are aggregations of other attributes or that are calculated from other attributes. In many embodiments, the consumer data warehouse110may include hundreds of attributes for each consumer. Some attributes, and especially attributes useful to a wide variety of clients using the system100, may be pre-calculated for the consumer records and may be generally available to the clients as a generic attribute view111from the consumer data warehouse110. Clients120may also wish to define custom attributes for their own use to help identify consumers of interest. Instructions for calculating these proprietary attributes may be input to the consumer data warehouse110by a custom attribute coder160on behalf of individual clients120for use by the individual clients. The custom attributes may be stored in a plurality of client views112, which allow each client120to access only their own proprietary attributes.

In some embodiments, in addition to the attributes in views111,112, clients may provide other data113that may be used together with the data in the consumer data warehouse110to identify potentially good prospects for a direct marketing campaign. For example, clients120may wish to include historical information identifying consumers who have previously been contacted in one or more direct marketing campaigns, response history information about consumers who have been contacted, information identifying consumers who have requested not to be contacted, and/or the like. Other non-campaign related data may also be included with the other data113.

Generally, when a client120wishes to run a direct marketing campaign, a campaign flowchart121is generated to describe a plan for identifying desired consumers from the records in the consumer data warehouse110. The campaign flowchart121is typically a complex plan for using a large number of attributes from the generic attribute view111and the client view112, along with other client data113, to categorize the consumers and to select consumers whose attributes place them in one or more desired categories. The campaign flowchart121is provided to a project manager130who, among other tasks, accepts the campaign flowchart121for extracting the desired information, often in the form of consumer names and contact information, from the consumer data warehouse110.

In order to help the client120design a campaign flowchart121that successfully identifies consumers appropriate for a given direct marketing campaign, the campaign testing and executing system100advantageously includes a sample database140that serves as a temporarily available environment in which a client may test, refine, and validate a proposed campaign flowchart121. The sample database140preferably includes data from a random or semi-random sampling of the records in the consumer data warehouse110so that results obtained from test campaigns run on the sample database140will be statistically meaningful indicators of the results that would be obtained using the full consumer data warehouse110. It is desirable for the sample database140to include a sufficiently large sampling of the consumer data warehouse110records to provide a statistically meaningful sample while being sufficiently small to allow for quick building of the database140and quick execution of test campaigns. Preferably, the sample database140includes fewer records than the consumer data warehouse110. In one embodiment, a sample size of 10% of the full consumer data warehouse110is preferred. That is, the sample database includes at least a portion of the data from 10% of the consumer records in the full consumer data warehouse110. In other embodiments, other preferred sizes may be used, including 1% to 70%, or 5% to 25% of the records in the credit-related database102. Although embodiments of the systems and methods are described herein with reference to a 10% sample database140, embodiments of the systems and methods are also contemplated as being used with a sample database140that represent a different portion of the full consumer data warehouse110.

As depicted inFIGS.1B1,1B2, and1B3, once a sample (for example, 10% of the data warehouse records) is selected, generic attributes from the generic view111and proprietary attributes in the client view112that are associated with consumers in the sample go through an extraction and data load process executed by a data load module150to build the sample database140. Generic attributes may be stored in a repository of consumer core data141and proprietary attributes from the client view112may be stored in a repository of client pre-calculated data142. In various embodiments, certain portions of the selected records the consumer data warehouse110may be omitted from records in the sample database140. For example, consumer name and contact information may be deleted from the records to be used for campaign testing in order to comply with various governmental regulations regarding proper use of consumer credit information. Instead, anonymous identifier numbers and general location information may be used to identify the individual records and to allow a geographically representative sample to be selected. As will be familiar to a practitioner of skill in the art, other methods of anonymizing consumer records while retaining their usefulness for campaign development may also be used.

As depicted inFIGS.1B1,1B2, and1B3, a copy of some or all of the other client data113may be stored in a repository of other client data143for use with the sample database140.

In one embodiment, to test, analyze, and refine a proposed campaign, the client120uses a campaign management tool125and/or a business intelligence tool126to access a sample client view144that includes data from the repository of sampled consumer core data141, the associated repository of client pre-calculated data142, and the repository of other client data143. The campaign management tool125and the business intelligence tool126are software applications that may be accessed and run using a personal computer (PC) or any of a variety of other commonly available computing devices in order to send queries to the sample database140, to generate reports based at least in part on information obtained from the sample database140, and to perform other research and analysis functions associated with testing and refining the proposed direct marketing campaign. In preferred embodiments, the client120may access the campaign testing and executing system100by way of the Internet or other communications network103.

In preferred embodiments, the campaign management tool125, or another aspect of the campaign testing and executing system100, provides the client120with a “layman, user-friendly” data dictionary that describes elements available within the sample database140. The client120is preferably also provided with a “look-up” capability for various available categories of attributes, for example mortgage-related attributes, credit-rating related attributes, or the like. In some embodiments, the client120may additionally or alternatively create and use proprietary attributes for use in the direct marketing campaign.

Preferably, the campaign management tool125allows the client120to be able to conduct high-level campaign development functions, such as segmentation of the consumer population, selection of one or more such segments, and/or suppression of one or more segments or one or more individual consumers from the selection results.

Furthermore, the campaign management tool125preferably provides the client120with a capability to construct queries for testing and executing the campaign through a graphic user interface (GUI). The campaign query interface allows for basic and advanced logic to be defined and used to construct queries in one or more database query languages, such as Standard Query Language (SQL). In a preferred embodiment, the query interface provides the client120with a capability to create SQL queries directly, to view either or both of SQL queries created directly by the user and/or queries generated via the query builder interface, and to edit either or both of SQL queries created directly by the user and/or queries generated via the query builder interface.

The query interface of the campaign management tool125preferably allows the client120to name query definitions, to save query definitions, to reuse query definitions. Additionally, in a preferred embodiment, the query interface provides the client120with an ability to record and modify campaign selection rules for future use. In some embodiments, the query interface allows the client120to share query definitions with one or more authorized users.

Furthermore, in a preferred embodiment, the query interface allows the client120to test a query, to view query results, and to print the query results. For each query result, the query interface may have the capability to provide a sample of the underlying data.

In one embodiment, the campaign management tool125includes a query interface that allows the client120to select individuals from the marketing database based upon individual or household criteria. The query interface allows the client120to add data sources for the purpose of selection for individual campaigns. The query interface further provides the client120with an ability to select records based on a “times mailed” calculation derived from the historical campaign response data. The query interface may provide the capability to identify customer segments. The query interface may additionally or alternatively provide the client120with a capability to utilize independent queries for each segment and segmentation trees to split the customer universe into subgroups.

In some embodiments, the same campaign management tool125and the business intelligence tool126software applications that are used for running direct marketing campaigns on the full consumer data warehouse110(the 100% environment) may also provide all functionality needed for allowing clients120to directly create and test campaigns on the sample database140(10% environment). In some embodiments, separate query interfaces for campaign testing and campaign execution may be provided. In some embodiments, the campaign management tool125and the business intelligence tool126software applications may provide some, but not all, preferred functionality for providing the systems and methods disclosed herein, in which case supplemental software may be added to or used in conjunction with the campaign management tool125and/or the business intelligence tool126software to provide the missing functionality.

The client120may run and re-run the test campaign on the sample database40as desired, performing champion/challenger tests, for example, and observing the effects of modifications on the campaign results. In various embodiments, the data in the sample database140remains temporarily static until the sample database140is re-built, using a new randomly selected sampling of the credit-related database102records which may take place at regular intervals, such as for example, once a week. Thus, the client120can have confidence that the various campaign test runs being run during a given week are being run on the same data. In other embodiments, the data in the sample database140may be updated according to another schedule, such daily, monthly, upon demand by one or more clients, at random intervals, or the like.

In various embodiments, the client120can run various types of reports using the campaign management tool125and/or the business intelligence tool126software in order to aid in analysis of the data and test results. For example, in one embodiment, the client120may run one or more campaign analysis reports that allow the client120to predict response to the direct marketing campaign within a segment or group of segments of the targeted population. The client120may also use reports to refine future marketing strategies. In some embodiments, the client120may specify a preferred output layout for the reports.

In some embodiments, the campaign management tool125and the business intelligence tool126software do not communicate directly with one another and do not directly share metadata or queries, although the client120may manually transfer queries, for example, from one to the other. In other embodiments, the campaign management tool125and the business intelligence tool126software may be configured to have access to shared metadata and queries.

Once the client120has had an opportunity to test and/or refine the campaign strategy and is satisfied with the campaign strategy, the client may provide the campaign flowchart121, which reflects the desired campaign strategy, to the project manager130for running on the full data warehouse110environment as currently updated.

As was described above, in preferred embodiments, the consumer data warehouse110is updated twice weekly or at another advantageously frequent interval to insure “freshness” of the data. Thus, although the campaign testing may, in some embodiments, have been run on data that was about ten days old, the actual campaign may be run on data that is three days old or newer. In some embodiments, once the client120submits the desired campaign strategy in the form of a campaign flowchart121to the project manager130, either directly or via an intermediary, the campaign may be run on the full consumer data warehouse110and results returned to the client120within as little as three business days or less. In other embodiments, results may be returned to the client120within another advantageously short period of time.

In preferred embodiments, the campaign management tool125and/or the business intelligence tool126may provide a variety of reporting services to the client120. For example, the campaign management tool125may also provide the client120with data about consumer responses received in connection with one or more executed direct marketing campaigns. In other embodiments, the client120may receive consumer response reports from another source. In one embodiment, a response analysis report may provide an analysis of responses received from a direct marketing campaign executed through the system100. The response analysis report may summarize results over periods of time with shorter comparison periods in the immediate weeks after a campaign is executed to longer time frames after the campaign has completed. The response analysis report may provide flexibility to perform analysis of various levels and/or categories of summarization, which may include, but are not limited to: customer segments, product line, product campaign, promotion, offer, collateral, media, and/or vendor.

In some embodiments, a client data maintenance service165provides the client120with an ability to store campaign-related data related to client campaigns. For example, the client data maintenance service165may make campaign data accessible for further campaign development purposes, for analysis purposes, and/or in order to update/delete/archive campaign data for client campaigns. The client data maintenance service165may provide the ability to receive and store campaign-related data for direct marketing campaigns that may be common to most or all of a client's campaigns and thus may be useful for future campaigns. The client data maintenance service165may collect data of individual promotions in order to derive a “times contacted” calculation for use in future campaign development.

In some embodiments, the client data maintenance service165may further record updates to identifying information, such as name, address, and/or telephone information received during a direct marketing campaign. The client data maintenance service165may record mail disposition updates for individual consumer records, such as whether a direct mailing advertisement was mailed or not mailed, along with associated explanatory reason codes. The client data maintenance service165may record telephone contact disposition updates for individual consumer records, such as whether a direct mailing advertisement call was made or not made, along with associated explanatory reason codes. In other embodiments, other types of data may additionally or alternatively be maintained on behalf of the client120, by the client data maintenance service165and/or as part of the campaign management125or business intelligence tool126services.

In some embodiments the system100may be used for planning a variety of types of campaigns, including, for example, both firm offers of credit and ITA offers. In some embodiments, the system100may provide access for clients120to two or more sample databases140, including at least one sample database that includes only non-credit related data. This type of non-credit related sample database may be used, for example, for planning campaigns where the use of consumer credit data is not permitted. In other embodiments, the sample database140may be configured to include a mix of credit and non-credit information, such that the system100may provide clients120with access to both the credit and the non-credit information or to only the non-credit information in the sample database140.

The methods and processes described above and throughout the present disclosure may be embodied in, and fully automated via, software code modules executed by one or more general purpose computers/processors. The code modules may be stored in any type of computer-readable medium or other computer storage device. Some or all of the methods may alternatively be embodied in specialized computer hardware.

FIG.2depicts one embodiment of a partitioning solution that allows a plurality of individual clients120′,120″,120′″,120″″ to access the same sample database140, without corrupting or having access to one another's proprietary data. As was depicted inFIGS.1B1,1B2, and1B3, the sample database140includes a repository of core consumer data141, available to all clients, which includes data associated with a randomly selected portion, such as 10%, of the records in the full consumer data warehouse110. In a preferred embodiment, once a week, a new 10% sample of the full consumer data warehouse110is randomly selected, extracted from the consumer data warehouse110, cleansed of undesirable or unnecessary attributes, such as name, address, other contact information, and the like, and is loaded into the repository of core consumer data141. In addition, pre-calculated attributes associated with the generic attribute view111for the selected portion of the consumer records can be calculated and loaded in to the repository of core consumer data141that is commonly available to clients using the sample database140.

Furthermore, the system100may provide each client120accessing the sample database140with additional proprietary data owned by the client. The proprietary data may include custom attributes, as defined in the client view112of the consumer data warehouse110and/or may be custom attributes defined for the current campaign. The custom attributes can be calculated for the randomly selected portion of the consumer records and are loaded in the repository of client pre-calculated data142in the sample database140. In addition, other client data143, proprietary to each client, may be made available use for by the associated client. For example, client-specific campaign history data and/or client-specific response history data may be provided to clients120using the sample database140. This test environment which persists for one week, or for another desired span of time, provides a stable environment that is very helpful to campaign developers.

As depicted inFIG.2, the generic data available to all clients and the proprietary data exclusive to individual clients120′,120″,120′″,120″″ are depicted as Schema1, Schema2, Schema3, and Schema4. Each schema may, in various embodiments, include the client pre-calculated data142for the 10% or other sized sample and/or the other client data143that were described with reference toFIGS.1B1,1B2, and1B3and may be used with the data in the repository of core customer data141.

FIG.2shows that each schema is accessible only to its respective client120, and is shielded from access or use by other clients by a system of partition. The partition plan depicted inFIG.2allows a plurality of clients120to access the sample database140simultaneously or nearly simultaneously for testing and refining their respective campaign strategies. In one embodiment, the campaign testing and executing system100allows for from one up to one hundred clients120to access the same sample database140, including the shared core consumer data141and each client's120proprietary data, simultaneously. Clients may pose up to one hundred queries per month and may extract from less than one up to over thirty million names per month. In other embodiments, the system100may accommodate more than one hundred clients120and/or may allow the clients120to pose up to another advantageous number of queries and/or extracted names per given time period. In still further embodiments, the system100may provide multiple sample databases140for use by one or more clients120.

Starting at the bottom ofFIG.2, a plurality of clients120′,120″,120′″,120″″ access the business intelligence126and/or campaign management125tools for testing and refining their respective campaign strategies. A firewall210allows access to the system for clients120with approved campaign credentials and protects computers used by the individual clients from improper access by others.

The clients120′,120″,120′″,120″″ access the campaign web application server220and are given access to their respective partitions. In some embodiments, the clients120′,120″,120′″,120″″ can connect using a Virtual Private Network (VPN) and/or can use vendor specific user credentials. In one embodiment, access to the campaign server240is controlled by an Access Control List (ACL)230, such as an ACL that makes use of a password or other identifier to correctly authenticate a client20wishing to access the system100, as will be understood by one of ordinary skill in the art in light of the present disclosure. The campaign server240accesses the data stored in the sample database server140in order to carry out the queries, tests, report generation, and the like that may be requested by the individual clients120. Once again, communications between the sample database server140and the campaign server240is controlled by means of an ACL250. In some embodiments, the sample database server140can be implemented using a relational database, such as IBM DB2, Sybase, Oracle, CodeBase and Microsoft® SQL Server as well as other types of databases such as, for example, a flat file database, an entity-relationship database, and object-oriented database, and/or a record-based database.

Thus, clients gain the benefits typically associated with a custom test and execution database system that includes their own data as well as very up-to-date generic consumer data without a substantial delay for database build time and without the very costly up-front financial investment that are typically associated with proprietary databases.

Furthermore, as was described with reference toFIGS.1B1,1B2, and1B3above, in some embodiments, in addition to having access to different proprietary data142,143, different clients may also be provided with access to different portions of the core consumer data141in the sample database140. For example, one or more clients120planning a first type of campaign may be allowed access to all of the data in the core consumer data141, while clients120planning a second type of campaign may be allowed access to a portion of the data in the core consumer data141. Furthermore, in some embodiments, a given client120may be allowed access to all of the data in the core consumer data141for a first type of campaign, while the same client120may, at the same time, be allowed access to only a portion of the data in the core consumer data141for use in planning a second type of campaign. In one embodiment, access control to the data in the core consumer data141of the sample database140is implemented, at least in part, using the various schemas for the various clients120, as depicted inFIG.2.

FIG.3is a diagram that depicts one embodiment of a selection of data from the credit database to be included in the “snapshot” sample database140. In the embodiment shown, the following types of data are included: consumer credit information310, consumer non-credit information320, client custom data330, client contact history data340, and client response data350. In some embodiments, the client20uses the campaign management software tool125for campaign development and/or the business intelligence tool126for analysis and reporting. The consumer credit information310and the consumer non-credit information320both come as part of the 10% sample data load from the generic attributes111in the consumer data warehouse110. Together, they make up the consumer core data141depicted inFIGS.1B1,1B2,1B3andFIG.2. In this embodiment, each record in the consumer credit information310and the consumer non-credit information320includes a household identifier (HSN), a personal identifier (PIN), and a selection of consumer attributes. The client custom data330is stored in the repository of proprietary attributes142depicted inFIGS.1B1,1B2, and1B3, In this embodiment, each record in the client custom data330includes a household identifier (HSN), a personal identifier (PIN), and a selection of proprietary consumer attributes. In various embodiments, client custom information may not include consumer name, street address or encrypted PIN information, and does include, for each consumer, an element, such as zip code, that can be matched to data within the sample database141and the consumer data warehouse110. The client contact history data340and the client response data350may both come from the copy of the other client data143in the sample database140, which includes data about the full population of consumers. These data sources are used, for example, to filter campaign results based on past contact history and client response information. The past contact history and client response information may indicate that if a given consumer appears in the list of campaign results, the consumer should be removed from list, for any of a variety of reasons. In some embodiments, some of the data from the client provided data330,340,350records may not be used for campaign development, in order to comply with federal and other regulations that control the use of credit-related data for advertising purposes.

In one embodiment, a sample test environment is built that represents data from a random 10% of a consumer credit database. The 10% test environment may be used for analysis, campaign development, campaign set-up, and for executing, auditing and reporting on logic proposed for the campaign. The client120may review results of the above and may approve or decline to approve execution of the proposed campaign strategy on the full and most recently updated version of the consumer credit database. If the client120declines approval, the client may choose to modify and re-test the campaign strategy one or more times until a desired campaign strategy is achieved. Thus, the full campaign executes the desired campaign strategy in the 100% environment of the full consumer data warehouse110.

Although the foregoing systems and methods have been described in terms of certain preferred embodiments, other embodiments will be apparent to those of ordinary skill in the art from the disclosure herein. For example, in some embodiments, it may be desirable to add one or more demographic tables to allow for development of Invitation to Apply (ITA) lists (non-credit data lists) for direct marketing campaigns by clients. In some embodiments, credit data from more than one credit bureau may be available for use in connection with the systems and methods described herein.

Furthermore, although the systems and methods disclosed herein have been described by way of embodiments in which the clients120are typically credit providers or marketers working to plan direct marketing campaigns on their behalf, other embodiments, in which clients120are other types of business entities who wish to make use information from the consumer data warehouse110, especially for planning direct marketing campaigns, are also envisioned.

IV. Operation

FIG.4is a flowchart depicting one embodiment of a process400for generating and maintaining a sample database environment140. In block410, the system100performs a sampling of the records in the credit-related database102. In preferred embodiments, the sampling includes data about a portion of the records in the credit-related database102. The data may include some or all of the attributes and other data stored for the sampled records. In some preferred embodiments, the sampling includes data about a percentage or fraction of the records, such as 10% of the records, or another percentage of the records in the range of 5%-25% of the records. In some embodiments, the sampling is a randomly selected portion of the records in the credit-related database102. In other embodiments, the sampling may be selected partially randomly, such as by segmenting the records in the credit-related database102and by randomly selecting a portion of the records from one or more of the segments.

In block420, the system100calculates one or more generic attributes associated with the sampled records. The generic attributes may be calculated from attribute definitions stored in one or more generic attribute views111and commonly available to clients120of the system100.

In block430, the data load module150of the system100cleanses and loads data from the sampled records and the associated attributes. For example, undesirable or unnecessary attributes, such as name, address, other contact information, and the like may be removed from the sample being used for the sample database140in order to comply with rules and regulations that govern the use of credit-related data. Attributes may also be removed from the sample data in order to decrease the size of the sample database140, so that building and running tests on the sample database140may be carried out efficiently and expeditiously.

The processes in blocks440and450are carried out individually for each client120using the sample database140. In block440, the data load module150of the system100cleanses and loads client-proprietary attributes, such as those stored in the client's client view112, deleting undesirable or unnecessary attributes. The data load module150may also load other attributes defined by the client for use in the current campaign strategy and/or may load other client data143provided by the client120.

In block450, the system100provides the client120with access to the sample database140, including the generic141and the proprietary142,143data. As was described with reference toFIG.2, the sample database140is advantageously configured, using a system of one or more partitions, firewalls, Access Control Lists (ACLs), and/or other security measures to provide access to the same generic data141to a plurality of clients120, simultaneously or near-simultaneously. Additionally, each client120may access and use their own client-proprietary data in conjunction with the generic data, without danger that there client-proprietary data will unintentionally become available to other clients120. This configuration provides for a shared database140that economically and efficiently provides a shared environment for campaign testing, while also providing the benefits of a usually much costlier custom testing environment that also for the secure inclusion of proprietary attributes and other information in the campaign strategy testing.

In block460the system100determines if a lifespan associated with the current version of the sample database140is complete. As one example, in embodiments in which the sample database120is updated weekly, the lifespan is one week. If the lifespan associated with the current version of the sample database140is not yet complete, the system100continues to provide the clients120′,120″,120′″ with access to the sample database140. If the lifespan associated with the current version of the sample database140is complete, the process400returns to block410where the system100creates a new version of the sample database140to replace the previous version.

FIG.5is a flowchart that depicts one embodiment of a process500for using the direct marketing campaign planning environment to assist a client120to test, analyze, refine, and execute a marketing campaign, in accordance with some embodiments disclosed herein.

In block505, the system100generates a sample database140test environment, as has been described with reference toFIG.4and elsewhere throughout the present disclosure.

In block510, the system100accepts from the client120a proposed set of campaign selection rules to be tested for implementing a campaign strategy. The goal of the campaign strategy may be to identify good prospects for a direct marketing campaign. The goal of the testing may be to identify selection rules, also known as prospect selection criteria, that can successfully identify from the sample database140a desired set of prospects for the campaign and that can thus be predicted to identify from the full database of consumer data110a desired set of prospects for the campaign being planned. The selection rules may, in some embodiments, be formatted as a database query based on attributes associated with records in the sample database140test environment. In some embodiments, the campaign management tool125and the business intelligence tool126can be configured to provide the client120with a data dictionary that describes various categories of attributes available for segmenting the consumer populations, such as mortgage-related attributes, credit-related attributes, various proprietary attributes, and/or the like.

In block520, the system100runs, on behalf of the client120, a test campaign on the sample database140using the proposed campaign selection rules. In some embodiments, the campaign management tool125and the business intelligence tool126can be configured to access a sample client view144of the sample database140. The sample client view144can be configured to include data from the repository of core consumer data141, repository of client pre-calculated data142, and repository of other client data143. In some embodiments, the campaign management tool125and/or business intelligence tool126can be configured to provide the client120with a GUI that provides a query interface to run, name, construct, save, and/or reuse queries for the sample database140. The queries can, in some embodiments, correspond to campaign selection rules. In some embodiments, the query interface can be configured to provide the client120with the ability to record and modify campaign selection rules for future.

In block530, the system100provides results of the test campaign performed as described in block520to the client120for analysis. The campaign management tool125and/or business intelligence tool126can be configured to allow the client120to conduct high-level campaign development functions, such as segmentation of the consumer population, selection of one or more segments, and/or suppression of one or more segments or one or more individual consumers from the selection results, using individual, household, and/or other criteria. The campaign management tool125and/or business intelligence tool126can also be configured to generate reports based at least in part on information obtained from the sample database140, and/or to perform other research and analysis functions associated with testing and refining the proposed direct marketing campaign. In some embodiments, the campaign management tool125and/or business intelligence tool126can be configured to generate reports predicting the response to the direct marketing campaign within a segment or group of segments of the targeted population.

In block540, the system100receives from the client120an indication as to whether it is satisfied with the campaign strategy. If the client120is not satisfied, and if the lifespan of the sample database140is not yet expired, then the process500returns to block510, and the testing and refining process can be repeated. The client120may modify and update the campaign selection rules and re-run the test campaign using new prospect selection criteria. In some embodiments, if the client120is not satisfied, and if the lifespan of the sample database140has expired, then the client120may continue testing the campaign selection rules once the sample database140has been rebuilt using a new randomly selected portion of the consumer data warehouse110.

Alternatively, if, in block540, the client120is satisfied with the results of the current set of prospect selection criteria, the process500moves to block550where the client120can provide a campaign flowchart121. The campaign flowchart121can be configured to specify the desired campaign strategy.

In block555, the campaign flowchart121is used as a specification for running a direct marketing campaign on the full consumer data warehouse110using the selection criteria identified during the testing on the sample database140. In some embodiments, the project manager130accepts the campaign flowchart121from the client120and causes the campaign to be executed on the full consumer data warehouse110. In some embodiments, the campaign with the tested selection criteria may be run on full consumer data warehouse110directly by the client120and/or may be run on another database of consumer information

In block560, the system100may optionally provide the client120with one or more consumer response reports associated with the direct marketing campaign. In some embodiments, the campaign management tool125and/or business intelligence tool126can be configured to provide the client120with consumer response reports received in connection with one or more direct marketing campaigns actually carried out. The consumer response reports may provide an analysis of consumer responses received from a direct marketing campaign. In some embodiments, the reports may summarize results over periods of time, including shorter comparison periods in the immediate weeks after a campaign is executed, and/or longer time frames, such as years after the campaign has completed.

The reports may provide flexibility to perform analysis of various levels and/or categories of summarization, which may include, but are not limited to: customer segments, product line, product campaign, promotion, offer, collateral, media, and/or vendor. In some embodiments, a client data maintenance service165can also be configured to store campaign-related data from executed campaigns that can, in some embodiments, be utilized for future campaigns. In some embodiments, the other client data113and/or repository of other client data143can be configured to store the campaign-related data for use in future campaigns.

IV. Various Embodiments of System and Method Implementations

In various embodiments, the systems and methods for providing a direct marketing campaign planning and execution environment may be embodied in part or in whole in software that is running on one or more computing devices. The functionality provided for in the components and modules of the computing device(s), including computing devices included in the system100, may comprise one or more components and/or modules. For example, the computing device(s) may comprise multiple central processing units (CPUs) and a mass storage device(s), such as may be implemented in an array of servers. In one embodiment, the computing device comprises a server, a laptop computer, a cell phone, a personal digital assistant, a smartphone or other handheld device, a kiosk, or an audio player, for example.

In general, the word “module,” “application”, or “engine,” as used herein, refers to logic embodied in hardware and/or firmware, and/or to a collection of software instructions, possibly having entry and exit points, written in a programming language, such as, for example, Java, Ruby, Ruby on Rails, Lua, C and/or C++. These may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as, for example, BASIC, Perl, or Python. It will be appreciated that modules, applications, and engines may be callable from others and/or from themselves, and/or may be invoked in response to detected events or interrupts. Instructions may be embedded in firmware, such as an EPROM.

It will be further appreciated that hardware may be comprised of connected logic units, such as gates and flip-flops, and/or may be comprised of programmable units, such as programmable gate arrays or processors. The modules, applications, and engines described herein are in certain applications preferably implemented as software modules, but may be represented in hardware or firmware in other implementations. Generally, the modules, applications, and engines described herein refer to logical modules that may be combined with other modules and/or divided into sub-modules despite their physical organization or storage.

In some embodiments, the computing device(s) communicates with one or more databases that store information, including credit data and/or non-credit data. This database or databases may be implemented using a relational database, such as Sybase, Oracle, CodeBase and Microsoft® SQL Server as well as other types of databases such as, for example, a flat file database, an entity-relationship database, and object-oriented database, and/or a record-based database.

In one embodiment, the computing device is IBM, Macintosh, and/or Linux/Unix compatible. In another embodiment, the computing device comprises a server, a laptop computer, a cell phone, a Blackberry, a personal digital assistant, a kiosk, or an audio player, for example. In one embodiment, the computing device includes one or more CPUs, which may each include microprocessors. The computing device may further include one or more memory devices, such as random access memory (RAM) for temporary storage of information and read only memory (ROM) for permanent storage of information, and one or more mass storage devices, such as hard drives, diskettes, or optical media storage devices. In one embodiment, the modules of the computing are in communication via a standards based bus system, such as bus systems using Peripheral Component Interconnect (PCI), Microchannel, SCSI, Industrial Standard Architecture (ISA) and Extended ISA (EISA) architectures, for example. In certain embodiments, components of the computing device communicate via a network, such as a local area network that may be secured.

The computing is generally controlled and coordinated by operating system software, such as the Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Vista, Linux, SunOS, Solaris, PalmOS, Blackberry OS, or other compatible operating systems. In Macintosh systems, the operating system may be any available operating system, such as MAC OS X. In other embodiments, the computing device may be controlled by a proprietary operating system. Conventional operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, and I/O services, and provide a user interface, such as a graphical user interface (GUI), among other things.

The computing device may include one or more commonly available input/output (I/O) devices and interfaces, such as a keyboard, mouse, touchpad, microphone, and printer. Thus, in one embodiment the computing device may be controlled using the keyboard and mouse input devices, while in another embodiment the user may provide voice commands to the computing device via a microphone. In one embodiment, the I/O devices and interfaces include one or more display device, such as a monitor, that allows the visual presentation of data to a user. More particularly, a display device provides for the presentation of GUIs, application software data, and multimedia presentations, for example. The computing device may also include one or more multimedia devices, such as speakers, video cards, graphics accelerators, and microphones, for example.

In one embodiment, the I/O devices and interfaces provide a communication interface to various external devices. For example, the computing device may be configured to communicate with one or more networks, such as any combination of one or more LANs, WANs, or the Internet, for example, via a wired, wireless, or combination of wired and wireless, communication links. The network communicates with various computing devices and/or other electronic devices via wired or wireless communication links.

Although the foregoing invention has been described in terms of certain embodiments, other embodiments will be apparent to those of ordinary skill in the art from the disclosure herein. Moreover, the described embodiments have been presented by way of example only, and are not intended to limit the scope of the invention. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms without departing from the spirit thereof. Accordingly, other combinations, omissions, substitutions and modifications will be apparent to the skilled artisan in view of the disclosure herein. For purposes of discussing the invention, certain aspects, advantages and novel features of the invention have been described herein. Of course, it is to be understood that not necessarily all such aspects, advantages or features will be embodied in any particular embodiment of the invention.