These are complex applications with many moving parts: multi-table data structures, relationship hierarchies, data acquisition, indexing, ranking and display. But matching remains a critical core function.

The specific purpose of matching is to find records that refer to the same entity, even though the records themselves are different. In a strict sense, matching involves direct comparisons of data strings. But in the real world, this is often supplemented by external reference data such as a list of all known products or all the names used by a business. This external data often allows connections that could never be inferred from strings alone, such as the fact that the John Jones who used to live in Chicago is the same John Jones who now lives in San Diego. For names and addresses, external knowledge allows parsing of data into elements such as first name, last name, and street number, so the same elements can be compared across different records. This external knowledge includes information about specific words (“David” is likely to be a first name, “Nebraska” usually is a state, “Bob” is a nickname for “Robert”) and information about common formats (“the final line in an address is likely to be in the order of city, state, and postal code, unless the first word is ‘attention’”). As that last example suggests, external knowledge implies rules as well as simple lists, and can get very complex.

In practice, parsing and standardization based on external knowledge are critical to successful name and address matching. But even the most sophisticated knowledge-based processing cannot remove all errors in a set of data. In fact, standardization and parsing can introduce errors of their own. To make matters worse, external knowledge may not be available once you move beyond well-understood structures like mailing addresses. So, in the end, there is always a need to compare two strings and decide whether they are similar enough to call them a match.

What differentiates matching engines is how they make this comparison. Simple matching systems often create a “match key” by extracting a few significant digits (say, first name initial, first three consonants in the last name, house number, city and state) and allowing a match if these are the same. Other systems use phonetic standardization such as Soundex to compensate for spelling errors. Some allow a match if strings have no more than a specified number or percentage of differences among the characters. Still others apply statistical techniques that take into account not only the similarity of the strings, but how common they are: so a common name like David Jones not be considered a likely match for David James, while an unusual name like Zydrunas Ilgauskas might match with Sid Iglakis. Often the systems assign separate match scores for different elements and then use weights or rules to assign a match score for the record as a whole.

Netrics Matching Engine (Netrics, 609-683-4002, www.netrics.com) applies a mathematical technique called “bipartite graph matching” to measure the similarity of strings. The general idea is to mimic human decisions by finding similar sequences of letters, even if they occur at different locations within two strings. This can compensate for data entry errors and deal with information that has not been parsed into separate fields. It also means the method can be applied to problems other than name and address matching. Netrics says its approach is more accurate than simpler methods such as matchkeys and Soundex, and more efficient than character-difference comparisons.

Like other matching engines, the Netrics engine returns a score that shows the similarity of the strings it compares. The system can also highlight matching blocks of text, making it easier for people to review why the system found a similarity.

Netrics also provides a Decision Engine that can use similarity scores to decide whether a pair of records is considered a match. The Decision Engine starts with examples of known matches and non-matches. With name and address records, these would typically be parsed into separate elements, although they could also be unparsed text blocks. The sample records are run through the Matching Engine and then the Decision Engine, which infers the decision rules (basically, weights and cut-off ranges for element similarity scores) that distinguish matches from non-matches. The system automatically adjusts its rules until its own decisions are acceptably consistent with the “correct” answers provided as part of the input. Users can provide additional examples of particular types of matches if the system performs poorly at identifying them. A couple thousand sample pairs are typically required for training. The Netrics approach is considerably easier than having users specify the rules explicitly.

Netrics is used both to search for individual records in a reference file and for batch deduplication such as merge/purge. It loads the data into system memory, which allows quick performance. The system has been tested on databases with hundreds of millions of records, returning as many as 25 matches per second. The product was released in 2000 and has more than 100 installations, mostly in healthcare and government agencies. About half the installations involve name and address matching, while the balance involve other types of data. The software is usually purchased through business partners, such as applications providers and systems integrators, who incorporate it into products they deliver to their clients. Pricing is based on the number of processors in the host computer, starting at $50,000 for a two-processor server.

The technologies needed for the two approaches are significantly different. Most interaction managers use the single profile table to ensure quick performance, while most campaign managers access multi-level customer databases for complex segmentation and in-depth analysis. Even systems that do both interaction management and campaign management run different internal processes for each. Many companies deploy entirely separate systems for each approach in each channel.

Actual message delivery is usually handled by yet another set of systems, such as digital printers and Web server software. Email and text messages are exceptions: many customer management systems can transmit these directly.

This fragmentation has organizational as well as technical roots. But the costs are severe: beyond the considerable expense of supporting multiple systems, businesses must rely on administrative processes to coordinate the treatments received by individual customers. Inconsistencies that slip through can reduce value and sometimes do serious harm to important customer relationships.

Concentri (Knotice, 800-801-4194, www.knotice.com) attempts to unify customer management systems for email, Web, mobile phones, and interactive TV. Structurally, it maintains a shared customer database with levels for profiles, activity history, and responses to forms such as surveys. This falls between the simple profile table of interaction managers and the complex marketing database of the campaign managers. Data matching, transformations and consolidation must be done outside the system before the tables are loaded.

Functionally, Concentri supports both batch selections for outbound campaigns and real-time responses for interaction management. These are managed through a single campaign interface, which lets users define selection rules that can be attached to email campaigns, SMS mobile text messages, Web pages and WAP mobile web content. The system delivers the email, mobile messages and Web pages directly.

Concentri’s use of segmentation to both select lists and control real-time content is the specific trick that lets it combine outbound and interactive marketing. The segment definitions themselves are fairly conventional: users select from pull-down lists of data elements, operators and values to build logical expressions which can be combined into multi-condition queries. The data elements can draw from the customer profile, activity history, and form responses. Concentri provides a standard database structure. Non-technical users can add custom elements through an administrative interface.

For outbound campaigns, the segments can create lists which are either frozen to store a specific set of customers or reselected each time the list is chosen. Email and mobile messages can be sent to the list on a regular schedule or when triggered by behaviors captured in the system.

For interactive campaigns, the segment can be treated as a “content display rule” which is attached to a specific piece of Concentri-created content. For example, content displaying vegetarian products could be linked with a display rule that selects only vegetarians. What makes this interactive is that the data determining who matches a particular display rule is updated in real time by the system’s activity tracking and form capture components. So a customer who answered a particular question a particular way could automatically be shown Web content that reflects this information, as well as sent an email with suitably customized contents.

This approach takes some getting used to. Conventional interaction management systems work a bit differently, defining a sequence of customer actions and system responses such as a telemarketing script. Concentri’s approach is more similar to Web advertising systems that use business rules or call an external recommendation engine to pick content relevant to a particular customer. Either way, Concentri should provide the practical benefit of real time interaction management—that is, the ability to react to customer behaviors as they occur.

Concentri also differs from conventional interaction management systems in providing functions to create the content it delivers. The system includes base templates for email, Web pages, Web forms, text messages, WAP pages and WAP forms. Users can modify these with Concentri design tools and attach specific contents to regions within the templates. Display rules are attached to the content, not the template.

Content elements can either be created for a specific channel or defined as “master elements” used in templates across multiple channels. Sharing these master elements provides a consistent customer experience and makes it easier to understand which messages have been sent to each customer. Concentri automatically adjusts how master elements are displayed in each template to accommodate different channel formats.

Content management includes practical refinements such as Web page previews, sending test messages, and simulation of how emails would be displayed in different email clients. Web contents can either be embedded within an external Web page as “live zones” that call Concentri when the page is rendered, or displayed with a Concentri-built page that is reached through a link on an email or other Web page. Either way, the content resides on a Concentri server.

Concentri automatically keeps adds the contents displayed to each customer to its activity history. At present, it uses third party cookies to track Web visitors, although the vendor is exploring use of the more-reliable first party cookies. The system can also use standard interfaces to import data on customer behavior captured by Web analytics systems like Omniture and WebSideStory. It can insert those systems’ tags in Concentri content, allowing them to capture Concentri activity.

Reporting includes conventional Web, email and mobile measures such as page views, messages delivered, and email opens, clicks and conversions. Concentri also reports on total impressions for each piece of content, in total and by campaign.

Concentri is offered as a hosted service by Knotice. Pricing depends on channels used, activity levels, and level of support. A system used across all channels would cost $350,000 to $500,000 or more per year, depending on volume. Knotice was founded in 2003 with a focus on cable TV and broadband companies. Concentri was introduced in 2006 and has about 20 installations.

But drawing the picture is one thing and making it happen is something else. Many software products have enabled such targeting or provided pieces of a solution. They differ in technical approaches, channels served, selection methods, degree of automation, user skills needed—you name it. Just among selection methods for Web site personalization, choices have included rules engines, collaborative filtering, behavioral targeting, event detection, and multivariate testing.

Kefta Dynamic Targeting (Kefta, Inc., 415-391-6881, www.kefta.com) fits somewhere within this universe. Kefta itself says it competes primarily against behavioral targeting systems like Touch Clarity (recently purchased by Omniture), Certona or [x+1] (formerly Poindexter Systems). Like those systems, it inserts code snippets into Web pages that gather visitor information, send this to a server with visitor profiles and selection rules, and receive the content to display.

But behavioral targeting systems automatically create segments based on which visitors select which content. Kefta users define the segments in advance and specify which contents are presented to each group. Multivariate testing systems including Optimost, Offermatica, Memetrics and SiteSpect use a similar approach. On the other hand, Kefta and the behavioral targeting systems can automatically direct larger portions of visitor traffic to the best-performing content. Most multivariate testing systems (Offermatica is an exception) keep the content mix steady until users intervene.

Kefta’s primary offering is a “full-service” system that extends beyond ads within Web pages to support follow-up emails, page layers, exit pop-ups, and off-site banner ads. A “self-service” system, introduced late last year, is limited to Web pages and lacks many advanced features.

Both products use the same underlying engine and both are organized around campaigns. To set up a Web campaign, users specify the pages, placeholders within each page, and content elements that can populate the placeholders. Each placeholder is defined by a “Kefta probe” which contains HTML that calls the Kefta server when the page is viewed. The server will refer to the campaign rules to determine which contents the particular site visitor should receive. The contents themselves are blocks of HTML that could refer to materials stored externally, execute Javascript or other programs, return information for analysis, or do pretty much anything else. Kefta uses cookies to identify repeat visitors.

Placeholder probes also store a default content definition, which ensures that visitors see something relevant even if the connection to the Kefta server is lost. Other probes can track “actions” which are accumulated for reports and can be used as the object of a test campaign. Actions can be defined as the number of times a given probe has executed or as the sum of a value, such as order amount, which is gathered when the probe is fired. The full-service system allows any number or type of actions per campaign, while self-service is limited to ten. Kefta staff creates probes for full-service users, while self-service users can produce their own placeholder probes and one action probe. Additional action probes are built for them by Kefta.

To conduct a test, self-service users attach multiple content items to one placeholder, specify the number of splits for the placeholder, and then select the content items to attach to each split. Users can assign control content for each placeholder and specify at the campaign level what percentage of visitors will be in the control group.

Kefta offers several ways to allocate test contents among visitors. Users can manually assign the percentage of visitors who will receive each item. They can specify percentages of visitors to receive the best- and worst-performing combination and let the system implement this based on actual results. Or the system can execute a “full factorial” test plan, meaning it tries all possible combinations of contents across all placeholders. Although Kefta can also test a subset of combinations and estimate results for the remainder (the “Taguchi” method), it has found the full factorial approach to be significantly more reliable.

The simplest tests rotate the same contents among all visitors. However, Kefta argues strongly that finding the best contents for an “average” visitor is less effective than finding the best contents for different segments. Users can define visitor segments and assign test contents separately for each segment. In the self-service system, users must choose one of several segmentation factors: search engine key words; referring site URL; tracking codes or values within the referring URL; geographic location (usually state) or connection speed. The full-service system allows segmentation on combinations of these factors, visitor profiles stored on the Kefta server, and behavioral information stored in cookies deposited on the visitor’s PC. Although the self-service system uses cookies to identify repeat visitors, these do not store behavioral data.

The full-service system can also apply statistical scoring systems to identify the best contents to offer individual customers, drawing on their segment, life stage, previous contents viewed, and available content. Business rules can further control the contents selected. Optimization uses logistic regression to automatically read test results and deploy the best-performing contents.

Full-service also creates third-party cookies (that is, sent to www.kefta.com) for visitors to external Web sites, allowing it to coordinate messages outside of the client’s own site when such cookies are not blocked.

System reports show click-through rates, actions and lift vs. control, with trends by days and details by segment. Other reports show exposures by placeholder combinations and detailed results per placeholder. The optimization system can estimate the incremental impact of individual content items on final results, even across multiple site visits.

Both versions of the Kefta solution are hosted. Reports and the self-service interface run in a Web browser. Kefta was founded in 2000 and has more than thirty users on its full-service system. Pricing is based on volume and services provided. It starts at $10,000 per month for the self-service system.

QD Technology Quick Response Database
by David M. Raab
DM News
February, 2007

There are many ways to organize data: flat files, XML tags, networks, hierarchies, cubes, columns, objects, and others still more exotic. But by far the dominant database management systems today are relational databases like Oracle, DB2, and SQL Server. These products are designed primarily for transaction processing—that is, to add, change and remove individual records. The features needed for transaction processing sometimes conflict with the features needed to analyze records in large groups. But relational databases can be used for analysis through a combination of feature extensions, clever database design and powerful hardware. Although this approach adds cost, many companies prefer it to the alternative of making their technical environment more complicated by bringing in another database engine designed specifically for analytics.

Such analytical databases do exist. Marketers in particular have frequently chosen to use them because they wanted the speed, flexibility and low cost that they provide. The leading products in this group have changed over the years but the dominant products for marketing applications are currently Alterian and SmartFocus. Both organize data into columns (for example, all last names or all Zip codes), so only the items needed in a particular query can be loaded to resolve it. This reduces the total amount of data to be retrieved from storage, which is usually the major determinant of query response time. Both products also use compression and indexes to further reduce data volumes and increase speed. In addition, they provide specialized query languages that simplify tasks which are difficult in a conventional relational database. These languages are embedded in the systems’ own query tools.

Memetrics xOs (Memetrics, 415.513.5120, www.memetrics.com) is a multivariate testing system based on discrete choice models. This approach measures consumer preferences by asking them to choose among simulated versions of a complete offer, each having a different value combination. (Think of product design: attributes might be size, price, color, etc.; consumers would be asked to choose among sample products with different values for each.) Discrete choice models have proven more effective at determining the actual impact of each attribute and value than asking about single attributes or values in isolation.

This is all heady stuff and there are Nobel Prizes involved. But for projects such as Web page optimization, the practical result is similar to other multivariate testing methods: each page is divided into one or more zones (attributes), such as message, image, and offer, and these are assigned multiple test values. If all possible value combinations have been tested—something called a “full factorial” design—the system will identify the best-performing combination as optimal and identify any relationships (“interactions”) among values. If only some combinations have been tested, the system ignores any interactions, identifies the best-performing value for each attribute, and proposes the combination of best-performing values as optimal. Testing only some combinations is a typical multivariate approach that yields faster results from smaller, simpler tests. It requires proper test design, which, like other multivariate testing systems, Memetrics does automatically.

Either way, the system also builds a “choice model” that can estimate the results for any combination of values. This can be particularly helpful if the user is interested in multiple outcomes—say, gross revenue, profit margin and number of orders—and wants to balance them against each other rather than maximizing just one. The Enterprise version of xOs lets track several outcomes and either model them separately or combine them into a single measure and model that. Enterprise users can also assign an offer cost and selection value to each outcome and combine these into a target measure. Outcomes can be based information captured during an interaction or imported from external sources such as an order processing system. These features are not available in the simpler Express version of xOS, which tracks only one outcome.

Setting up a test in Memetrics begins with defining the attributes, values, outcomes and proportion of traffic to be tested. Attribute values can be defined with a name, Internet address (URL), or by uploading the actual content to the Memetrics server. A sample size calculator helps users determine the number of attributes and values to test based on traffic volume, time available, conversion rates, expected response variations, and target confidence level.

Once the elements are specified, xOs can generate a block of Javascript that identifies the test and its attributes. The user then embeds the Javascript in the Web page to be tested. The Javascript calls the Memetrics server each time the page is displayed, allowing Memetrics to assign each visitor to a test, control or default group and present the appropriate content. Memetrics uses persistent cookies to identify site visitors so it can ensure consistent treatment when they return.

The Memetrics Javascript can also capture information from the user’s URL, such as the search query that led them to the page. This is stored on the Memetrics server and used to analyze results by visitor segment. Javascript for the same test can be embedded in several pages, allowing consistent treatments and tracking of results such as registration or purchases.

xOs Express is limited to the Javascript approach. Enterprise can also use techniques such as .NET, PHP and JSP to communicate with Web servers or other interaction systems such as call centers. This enables Enterprise to manage tests across multiple channels. Enterprise, but not Express, can also use real-time filters to limit tests to predefined customer segments. These filters can access data provided by the interaction system or read from other sources such as a customer database.

After a test is complete, both systems let users define segments based on whatever visitor data is available. Users can test alternate segmentation approaches to find the best results. xOs can build one model against the entire test universe or build separate models for each segment. Reports for each model show the effect of each value and its statistical significance. Users can accept the system’s choice of optimal values or select their own, and then deploy this combination as a default. Either way, the system will show the expected results for the specified combination.

There is no automated adjustment of default values as customer behavior changes over time. Memetrics argues that humans should examine each test result and make conscious decisions about what to do next. A typical Web page test runs two to four weeks and evaluates five or six attributes, each with multiple values.

The default values will be shown to all visitors outside of a test sample and are also displayed if the Memetrics server is unavailable. The default contents are also viewed by Web search engines.

Memetrics was founded in 1999 and has more than 30 clients. Its original product was Enterprise, which is priced at $150,000 per year plus consulting. It can run in-house or be hosted by Memetrics. Express is a hosted service that was introduced in 2006. Price begins at $40,000 per year and is based on volume.

Actually, Grandpa might feel right at home with multi-variate testing, since the concepts were originally developed in the 1920’s and adopted for industrial use in the 1950’s. Marketing applications date from the late 1990’s. In all cases, the general idea is the same: an experiment can measure the impact of several elements, each with multiple versions, by testing a small fraction of all possible combinations. Results for each element are read separately: so all results for headline A are compared with all results for headline B, even though some people saw different copy, prices, photos, and so on. Results from different combinations of elements are estimated by adding up the impacts of their components. (This is a simplified explanation: there are additional nuances that only a statistician could love.)

Offermatica (Offermatica, Inc., 866.627.3557, www.offermatica.com) offers both multi-variate and A/B testing for Web marketers. The system not only helps marketers design the tests, but executes them by taking over specified areas on a Web page and controlling their contents for each site visitor. The execution functions are critical because the mechanics of test delivery are much more demanding than the test design itself.

Each multi-variate test in Offermatica starts with a test name, start and end dates, and percentage of visitors to include. Users can optionally specify targeting rules to narrow the audience and definitions of segments within the audience to report on. The user then builds a list of elements and versions, which the system automatically converts into a test grid. Finally, the user links the elements to Web page locations, which Offermatica calls “mboxes”.

The mboxes are physically added to Web pages by inserting a couple lines of Javascript. These send the mbox name to an Offermatica server and display content that Offermatica returns. Each mbox has its own Javascript; all code is identical except for the mbox name. The mbox can also transmit the page ID, visitor ID, and URL parameters such as search terms. These can be used to update visitor profiles and capture test outcomes such as clicking on an ad or placing an order. Users can also track outcomes by importing external data such as order logs. Visitors are identified by first party cookies which contain an ID linked to a detailed profile stored at Offermatica.

Offermatica automatically builds its list of available mboxes by adding each one when it first calls the server—that is, the first time the page with the mbox is viewed in any browser. This usually happens immediately after the Javascript is added to a Web page.

Adding mboxes is pretty much the only involvement that Web site technicians have with Offermatica. Test content can be uploaded to Offermatica using the system interface, stored on a client server or reside with a third party. When the content is elsewhere, Offermatica stores an identifier that tells the other system what to deliver. Users can view the each piece of content within the Offermatica interface and can preview full Web pages as contents are assigned to mboxes.

Reports show both the winning version for each element and the winning combination that was actually tested. Results are updated in real time. Users specify the success metric, with options including conversion rate, lift, average order value, revenue per visit and total sales. The system also shows the influence and confidence level of each result. Users can filter results by segment, week day vs. week end, and time period, and can exclude very large orders that might skew the results. A ‘push winner’ button makes the winning combination the default for all visitors in one step. If the best combination was not tested, users must set it up manually.

The system does not identify interactions or correlations among test elements. Users looking for interactions can download element-by-element statistics or have Offermatica staff explore the data for them. Offermatica generally recommends that tests be designed so that interactions are not a major concern, arguing that quick, simple tests are ultimately more productive than larger, more complicated ones.

But in practice, Offermatica places very few constraints on its users. The system does not limit the number of variables or elements per test. The same mbox can be used by multiple tests and appear in multiple locations. Any content can be assigned to any test or mbox. Visitors can be kept within the same test over multiple visits or not. Users can set priorities across tests and apply target segments within tests to control how such conflicts are resolved. This flexibility makes the system very powerful, although it also opens opportunities for error. Offermatica account managers and consultants help users make the right decisions and interpret their results.

Because Offermatica controls the mbox content seen by all visitors, it can do more than testing. One approach is to set rules that deliver different content based on the visitor’s source, site behavior or profile. This could, for example, treat existing customers differently from prospects or make offers related to previous purchases. Another approach uses “self-optimizing” tests that automatically increase the proportion of visitors shown the best-performing combination as the test progresses. Such tests review results every two hours, so they can adjust to changes in user behavior over time. A new offering, called “AdBox”, manages online ads served outside the client’s own site.

Offermatica is sold as a hosted service. Contracts run for one year or more and range from $5,000 to $25,000 per month based on the volume of test visits and staff hours. The original version of the product was released in 2004 and the company states it has more than 100 active customers.