Vizury Combines Web Page Personalization with a Customer Data Platform

One of the fascinating things about tracking Customer Data Platforms is the great variety among the vendors.

It’s true that variety causes confusion for buyers. The CDP Institute is working to ease that pain, most recently with a blog discussion you’re welcome to join here.  But for me personally, it’s been endlessly intriguing to trace the paths that vendors have followed to become CDPs and learn where they plan to go next.

Take Vizury, a Bangalore-based company that started eight years ago as an retargeting ad bidding platform. That grew into a successful business with more than 200 employees, 400 clients in 40 countries, and $30 million in funding. As it developed, the company expanded its product and, in 2015, released its current flagship, Vizury Engage, an omnichannel personalization system sold primarily to banks and insurance companies. Engage now has more than a dozen enterprise clients in Asia, expects to double that roster in the next six months, and is testing the waters in the U.S.

As often happens, Vizury’s configuration reflects its origins. In their case, the most obvious impact is on the scope of the system, which includes sophisticated Web page personalization – something very rare in the CDP world at large. In a typical implementation, Vizury builds the client’s Web site home page.  That gives it complete control of how each visitor is handled. The system doesn't take over the rest of the client's Web site, although it can inject personalized messages on those pages through embedded tags.

In both situations, Vizury is identifying known visitors by reading a hashed (i.e., disguised) customer ID it has placed on the visitor’s browser cookie. When a visitor enters the site, a Vizury tag sends the hased ID to the Vizury server, which looks up the customer, retrieves a personalized message, and sends it back to the browser.  The messages are built by templates which can include variables such as first name and calculated values such as a credit limit.  Customer-specific versions may be pregenerated to speed response; these are updated as new data is received about each customer. It takes ten to fifteen seconds for new information to make its way through the system and be reflected in output seen by the visitor.

Message templates are embedded in what Vizury calls an engagement, which is associated with a segment definition and can include versions of the same message for different channels. One intriguing strength of Vizury is machine-learning-based propensity models that determine each customer’s preferred channel. This lets Vizury send outbound messages through the customer’s preferred channel when there’s a choice. Outbound options include email, SMS, Facebook ads, and programmatic display ads. These can be sent on a fixed schedule or be triggered when the customer enters or leaves a segment. Bids for Facebook and display ads can be managed by Vizury’s own bidding engine, another vestige of its origins. Inbound options include on-site and browser push messages.

If a Web visitor is eligible for multiple messages, Vizury currently just picks one at random. The vendor is working an automated optimization system that will pick the best message for each customer instead. There’s no way to embed a sequence of different messages within a given engagement, although segment definitions could push customers from one engagement to the next. Users do have the ability to specify how often a customer will be sent the same message, block messages the customer has already responded to, and limit how many total messages a customer receives during a time period.

What makes Vizury a CDP is that it builds and exposes a unified, persistent customer database. This collects data through Vizury's own page tags, API, and mobile SDK; external tag managers; and batch file loads.  Data is unified with deterministic methods including stitching of multiple identifiers provided by customers and of multiple applications on the same device. The system can do probabilistic cross-device matching but that's not reliable enough for most financial service applications.  Vizury doesn’t do fuzzy matching based on customer names and addresses, which is not a common technique in Asia.

The system includes standard machine learning algorithms that predict product purchase, app uninstalls, and message fatigue in addition to channel preference and ad bidding. Results can be applied to tasks other than personalization, such as lead scoring.  Algorithms are adapted for each industry and trained on the client’s own data. Users can't currently apply machine learning to other tasks.

Vizury uses a typical big data stack including Hadoop, Hive, Pig, Hbase, Flume, and Kafka. Clients can access the data directly through Hadoop or Hbase.  Standard reports show results by experience, segment, and channel, and users can create custom reports as well.


Pricing for Vizury is based on the number of impressions served, another echo of its original business. Enterprise clients pay upwards of $20,000 per month, although U.S. pricing could be different.

Azalead Account Based Marketing Tracks Web Site Visitors, Orchestrates Outbound Messages, and Reports on Results

Account Based Marketing. Perhaps you’ve heard of it?

Okay, just kidding: ABM gets just slightly less attention than Donald Trump and arguably generates a similar amount of confusion. Many of the industry vendors are addressing that problem (the confusion, not Trump) by working together in the Account Based Marketing Consortium which, among other things, has published an excellent survey and nifty six-level functional framework. You can download them both here.

The purpose of the framework is to help marketers understand the differences between ABM vendors. Let’s apply it to ABM Consortium member Azalead, a Paris-based firm that is planning to enter the U.S. market.

We’ll start with an overview of what Azalead does. It lets marketers create lists of target accounts by identifying Web site visitors (at the company level) based on IP address, by reading data through a CRM system integration, or by uploading lists any source. Users can export account lists for retargeting, connect via API with the company Web site to personalize messages shown to visitors from target firms, or send lists to CRM. Azalead tags can be embedded in Web pages or emails to track response. Opportunities and revenues can also be imported from CRM. The system reports on impressions (i.e., messages sent), responses, opportunities and pipeline value for targeted accounts and gives salespeople lists of all identified Web site visitors or of visits from target accounts.  It can also rank accounts with a system-generated engagement score.

Now that you have a more or less coherent view of Azalead functions, we can map these to the Consortium framework.

Account Selection: users can select accounts from the list of identified Web site visitors, from the list of accounts imported from CRM, or from any other list uploaded to the system. There is no predictive scoring although users can build lists by filtering on whatever attributes have been attached to the records, such as industry, country, or company size. Azalead has created its own technology to identify site visitors whose IP address cannot be tied directly to a specific company. Results vary, but in Europe this can increase the percentage of identified visitors from the usual 30% to as high as 50%..

Insights: once a company has been identified, Azalead can present users – typically sales people – with a screen that shows the company name, basic information (industry, revenues, etc.) from an external database, engagement history as captured by Azalead’s Web and email tags, and contact names from the CRM system. 

Content: Azalead doesn’t create content.

Orchestration: Azalead can create lists based on engagement level, opportunity stage (imported from CRM), and other account attributes.  Different lists can be selected for different marketing treatments.

Delivery: Azalead tags on a company Web site can both identify visitors and return basic parameters including company name, industry and size. These parameters can drive personalized Web site messages. Messages in other channels are generated by sending lists to marketing automation, CRM, retargeting, or other external systems.

Measurement: Azalead offers a summary dashboard and more detailed information on retargeting, display ads, and Web site visitors. A pipeline impact report plots sales opportunity probability against marketing engagement for individual deals, helping marketers to see the impact of their efforts.

So, what information is missing here? The framework doesn’t explicitly cover integration, arguably because that’s a supporting technology rather than a functional capability. Azalead has API-level integration with Salesforce.com and Microsoft Dynamics CRM. A general purpose API allows custom integration with Web sites and other systems. The company is working on API integration with major marketing automation platforms, but currently uses its own tags to track response to emails sent by those systems.

The framework also doesn’t including pricing or vendor background, which are also not functional capabilities.  Azalead pricing is published on its Web site. A limited system starts at $1,000 per month for a 3,000 monthly Web visits and 400,000 ad impressions. A system with all features starts at $3,200 per month for 20,000 Web visits and 1.4 million impressions. The company was founded in 2013 and currently has about 80 customers, mostly tech companies in Europe. It plans to open a New York office later this year.

Conversen Simplifies Complex Messages Through Multi-Channel Dynamic Content

Summary: Conversen makes it easy to generate dynamic messages across multiple channels. It's more a supplement than a replacement for conventional campaign management but should save a lot of work for marketers and their agencies.

One of the fundamental challenges in database marketing is that a seriously sophisticated campaign may send different messages to hundreds or even thousands of customer segments. The traditional approach has been to define these segments during the selection process, creating a tree with one end-point for each segment, and then to assign the appropriate message to each end-point. The problem is that this requires creating hundreds of versions of the messages and making sure that each is matched to the correct end-point. This is both labor-intensive and error-prone.

An alternative is to create "dynamic content" the messages that select the appropriate contents for each individual. In essence, this is moving some of the segmentation logic from the selection process to inside the message. Even though this ultimately produces the same number of variations, it lets marketers create fewer messages and segments, reducing manual effort.

Let’s take a concrete example. Suppose you’re sending offers for winter vacation travel. People in New York will be sent offers for Florida and people in Los Angeles will get offers for Mexico. In addition, people in high-income zip codes will be offered a deluxe package while those in middle-income zip codes get an economy offer. A segmentation-based approach would use three segmentation rules (New York or Los Angeles; if New York, high or middle income; if Los Angeles, high or middle income) to create four segments, each tied to a separate message. A dynamic content approach would require just two decisions (New York or Los Angeles, high or middle income) that are each tied to a specific content block.


It’s still possible to make a mistake: you could accidentally link the Mexico offer to New York. But each assignment is made only once so it’s easier to be sure it’s correct.

Note that the advantage of dynamic content increases as you add complexity: a three city-pair, three level program would require four segmentation rules (one for city, three for city/level combination) and nine unique messages, while dynamic content still needs only two rules (one for city, one for level) and six message blocks (three destination cities, three luxury levels).


So where’s the catch? Well, dynamic content requires the marketing automation vendor to work inside the message itself, using different technologies for each medium. This is significantly trickier than just pointing each segment to a message created elsewhere.

One way to avoid this complexity is to generate a file containing the customer records and segmentation variables and let channel-specific output systems generate the customized messages. But this adds its own costs and risks, since the external systems must be configured separately for each project. As a practical matter, most high-end marketing automation vendors have compromised by providing dynamic customization for email and Web pages, and letting external systems handle the other channels.

Conversen has taken a different approach, building a specialized system to support dynamic content across as many channels as possible. This puts it in a somewhat confusing business position, since it can sometimes replace a traditional campaign management system but more often receives output from one. Resolving this confusion is largely Conversen's own problem, however, since it sells to marketing service providers rather than end-users.

Conversen is organized primarily around campaigns. These include filters to select an audience, processing steps and content. The key here is consistency: the rules used in filters, steps and dynamic content are exactly the same. It's not just that they're built with the same interface and run against the same data structures: the same rule can actually be used for any purpose. Rules can also be shared across multiple campaigns and referenced within other rules. This reuse substantially reduces the number of rules needed, and thus both the effort and opportunity for error.

The rules themselves are quite powerful, extending beyond the usual selections on field values to include advanced features such as if/then/else loops. One gap is missing support for a/b testing, which Conversen decided to omit because it added too much complexity. The system doesn’t maintain an audit trail of changes to each rule, but does provide reports listing everywhere each rule is used. This helps to avoid unintentional consequences when a rule is changed.

Rules connect with data gathered from source systems through batch processes or a real-time API. The resulting database is stored in Microsoft SQL Server and hosted by Conversen. This is important point, since it means that Conversen doesn’t simply attach to an existing marketing database. Although moving data into a separate database does add some cost, it also provides options to maintain persistent customer histories, combine data from multiple sources, and directly capture events such as campaign responses.

The system includes basic features to define data structures and map data from external sources into those structures. Load maps can include basic rules for whether to update or append matching records, but more advanced processes such as name/address matching have to be done externally.

Users who don’t need any of these functions could simply send Conversen the output files from a conventional campaign manager. This costs no more than loading files into any other message delivery system.

The heart of Conversen are the marketing messages. Conversen defines each message as an XML template. This holds any static elements plus the rules used to select content blocks.

The blocks themselves are created outside of Conversen and stored in a content library. This is another example of Conversen drawing the line between its core functionality and supporting functions to be handled elsewhere. It also probably reflects the reality that content will be created by external vendors, such as ad agencies, who will want to use their own tools in any event. Lack of an integrated content-builder does mean that personalization tokens such as [First Name] must be manually embedded within the content block. This can be done in the original content creation system, requiring a relatively inconvenient cut-and-paste from a list provided by Conversen, or be added after the content is loaded into Conversen.

Each Conversen content block currently supports a single medium. Thus, there would be separate content blocks for 10% discount in email, Web, direct mail, mobile and other types of messages. Conversen is working on multi-media content blocks that could be inserted into any medium. This would further simplify marketers’ lives.

One Conversen campaign can deliver multiple messages over time, based on dates such as a contract expiration or recent activity, or on events such as promotion responses. The system can react to qualifying events at regular intervals or in near-real-time as they are posted.

Clients can also build custom interfaces by direct access to the Conversen API. This lets them create branded systems and offer specialized portals with limited functionality. These might give designers access to the content-management features of the system, or make predefined campaigns to available to field offices.

Conversen supports email, mobile (SMS), RSS feeds such as blog posts, print, call center and Web. The system provides specialized services for each channel, such as rendering to preview emails and postal sorting for direct mail. Print output is integrated with Bitstream PageFlex, which supports direct output to high-speed printers. Conversen sends the digital messages itself and ships print and call center files to third parties for execution.

The system also provides operational reporting on campaign volume and responses. The reports are designed to provide activity information rather than detailed marketing analysis.

Conversen was introduced in 2007. The company now has about 25 marketing agencies as customers, serving more than 125 end clients. The system is offered only as a Conversen-hosted service. Pricing includes a $15,000 setup fee plus $1 to $20 per thousand messages based on volume and type.

Kynetx Lets Marketers Customize User Experience Across Web Sites

Summary: Kynetx lets marketers enhance and coordinate user experience across multiple Web sites. It’s so different from site-based Web personalization that the possibilities can be hard to grasp. But I think they’re substantial.

The classic view of online anonymity is the 1993 New Yorker cartoon, “On the Internet, nobody knows you’re a dog.” Today, we realize that our online identities are not as private as they then seemed. But from a marketer’s viewpoint, it’s still maddeningly difficult to recognize online visitors and interact with them as individuals.

The challenge is usually focused on the marketer’s own Web site: when people visit, how can I identify them? But, ideally, marketers would track their customers across all Web sites and interject themselves when appropriate. Ad networks already do this to some extent, using third party cookies to coordinate the messages shown to each individual on different sites. But this doesn’t help marketers who want an active role in managing the user’s experience.

Kynetx offers a more powerful alternative. It installs a browser extension that can send data to an externally-hosted rules engine which returns JavaScript snippets that enhance the current Web page. The data describes the rules to execute and the current context, such as the Web page being viewed. It could potentially include personal information the user has chosen to share, although current Kynetx applications do not.

A concrete example would surely help. One Kynetx application is downloaded by members of the AAA automobile club. When users do a search on Google or other major sites, the application calls the Kynetx rules engine which checks a list of vendors who offer AAA discounts and flags them within the search results. No personal data is shared, yet AAA’s marketers deliver a customized experience that reminds members of their benefits and supports AAA’s partners.

Kynetx applications can also move data from one Web site to another, for example by capturing data and using it fill in a form or execute an API call.

The underlying technology for most Kynetx applications includes “Information Cards”, an open standard for digital identity management supported by Microsoft, Oracle, Google, PayPal and others. The general idea is that people can have different “cards” with different information for different purposes, allowing them to control (and, presumably, minimize) the amount of information they provide in each context. See the Information Card Foundation Web site for details.

In the case of Kynetx, Information Cards also minimize user effort, since the Kynetx browser extension must be installed only once, and then new applications can be added simply by loading a new Information Card. All the heavy lifting is done by the Kynetx rules engine, which resides on a central server accessed over the Internet. In addition to reducing the burden on the user’s computer, this makes updates easy since any changes are made on the server and go into effect without being deployed to user systems.

Development effort is further reduced because each Kynetx application runs on major browsers and operating systems without customization. Rules are written in a Kynetx-developed language with special features for context management. I was particularly pleased to see support for A/B tests, including facilities to randomly select different actions, capture success or failure, and report on results. Applications can run on personal computers, smartphones, or any other Web-enabled device.

Marketers who don’t want to use Information Cards can distribute applications through other “endpoints” including browser toolbars, cookies, wireless proxy servers (for example, in a coffee shop), or bookmarklets http://en.wikipedia.org/wiki/Bookmarklet . All that’s required is something that can identify a user, capture permissions, and call the Kynetx server.

Kynetx was founded in 2007 and currently is used in more than 700 applications from about 250 developers. Although the company does some application development, its primary business is selling execution on its platform, at rates from $.24 to $1.60 per thousand ruleset evaluations.

I’m frankly intrigued by the possibilities of Kynetx, which seems to open a direct channel onto users’ desktops, bypassing traditional Web advertising. It does require a preexisting relationship with the user, but gaining user permission is fast becoming a condition for most online interactions. Kynetx makes it easier to gain this permission by offering something of value in return. Even more important, it should help marketers to strengthen existing relationships by repeatedly demonstrating value after an application is installed.