Balandra Orchestrates Customer Journey Without a CDP

Balandra Customer Flow Diagram

The need for a system that assembles unified, sharable customer profiles is now widely accepted. So is the label of “Customer Data Platform” to describe such systems. What people do still debate is whether a Customer Data Platform should only assemble those profiles or should also include features to “activate” them in the sense of selecting customer treatments. I personally find the discussion uninteresting since the plain reality is that some companies want activation features in their CDP and others do not.  Companies that don't want activation in their CDP may already have a separate activation system or prefer to purchase a separate one.  This means that activation is optional, and, thus, not a core CDP feature. QED.

Theory aside, it’s true that the majority of CDPs do include activation features.  This makes a stronger argument for the weaker claim that most buyers want activation features in their CDP.  But this has nothing to do with CDPs in particular: it’s just an instance of the general rule that buyers prefer integrated systems to separate components. This is known (to me, at least) as Raab's Law, stated most succinctly as "suites win".

A diehard advocate of “CDPs need activation” might question whether activation systems can truly be purchased separately. My response points to Journey Orchestration Engines (JOEs), a small but intriguing category that includes Thunderhead, Pointillist, and Kitewheel among others. These products select the best treatment for each customer in each situation and transmit their choice to delivery systems (email, Web CMS, mobile app, call center, etc.) for execution. All need customer profiles to function, but they don’t necessarily meet the RealCDP requirements for accepting data from all sources, retaining all details, storing the data internally, or sharing their profiles with others. This is because their designers’ focus is on the very different challenge of making it easy for users to define, manage, and optimize customer treatments across channels.

Meeting that challenge requires presenting customer data effectively, identifying events that might require an action, selecting the right action in the current situation, and sending that action to external systems for delivery. Some tasks, such as data presentation and delivery system integration, are also found in other types of systems. The unique challenge for Journey Orchestration Engines is finding the right action while taking into account the customer’s complete situation (not just the current interaction). This requires understanding all the factors that are relevant in the current situation and choosing the best among all possible actions.

Of course, "all" is an impossibly high standard.  A more realistic goal is to understand as many factors as possible and choose among the broadest range of available actions. It’s an important distinction because the scope of available data and actions will grow over time.  This means the key capability to look for is whether a system has the flexibility to accommodate new data and actions as these become available.

This brings us to Balandra, a Madrid-based journey orchestration engine.

Balandra is designed for complex service industries such as insurance, telecommunications, and healthcare, where companies have multiple, complex operational systems. Left to run independently, these systems will each send their own messages, creating a disconnected and often inappropriate experience for each customer. Balandra intercepts these messages and replaces them with a single stream is governed by a common set of rules.

The rules themselves draw on a structure that organizes customer experience into major processes such as onboarding a new client, setting up a new service, or filing an insurance claim. Each process is assigned a combination of data, lifecycle stages, available actions, and decision rules. When an event occurs that involves the process, Balandra executes its rules to pick an action based on the customer’s data and lifecycle stage.

This may not sound especially exciting. But it’s important to contrast Balandra’s approach with conventional customer journey flows.  These follow a specified sequence of messages and events, at best with some branching to accommodate different customer behaviors as the journey progresses. But a conventional journey flow can only include a fairly low number of steps and branches before it becomes incomprehensibly complex. The rule-based approach avoids this problem by letting users  create different rules for different factors and apply them in sequence. So, you might have one rule that checks for recent customer service issues, another that checks for customer value, and another for previous purchases. Each rule would add or exclude particular messages from consideration. After all the rules had executed, a final rule would select from the pool of messages that remain available.

The advantage of this approach is that each rule executes independently, avoiding the need for a complex decision tree that specifies different treatments for different combinations of conditions. Rules can just be added or dropped into the mix knowing that they’ll apply themselves only when relevant conditions are met. For example, a rule might check for recent customer service problems and suppress new product offers within the following two weeks if one occurred. This happens (or doesn’t happen) across all interactions without explicitly building that check into each journey flow.

To be clear, Balandra isn’t the only system to take this approach. In fact, its actual rule definition and execution is done using a standard business rules engine – IBM’s Operational Decision Manager (ODM), formerly ILOG. The system does have an interface that lets non-technical users define the data associated with each process and specify connections with delivery systems. It can ingest data in real time via APIs, through event streams such as Kafka, or through batch file updates. It can support both real time interactions and batch processing for outbound campaigns.

If you’re keeping score, Balandra doesn’t qualify as a CDP because it only uploads a fraction of the data related to a customer – the interactions between customer and company systems. While this means Balandra clients might still want a separate CDP system, it also enables Balandra to use many fewer resources than a CDP would.

Balandra launched its product in 2014. It currently has four clients in production, all in Spain, and is looking distribution partners in other regions. Pricing starts around $50,000 per year and grows based on the number of customers.

Quantivo Offers High-Volume Customer Analytics at a Modest Price

These are exciting times in the world of analytical systems. The Web has created new demands to handle unprecedented data volumes and semi-structured data. Cloud-based deployment offers near-infinite hardware scalability and flexibility.  Acquisitions by enterprise software giants have opened opportunities for smaller, more nimble alternatives. The result has been an explosion of companies using new techniques for managing and analyzing huge data volumes. Many, including Vertica, Aster Data, Greenplum, and Netezza, have also been assimilated by enterprise vendors. Others, including Paraccel, Kognitio, SAND Technology, and 1010data, have grown steadily while remaining independent.

Quantivo is part of this latest technical flowering. Its core is a data structure that sits somewhere between columnar – now the most common approach for analytical processing – and hierarchical indexes. Specifically, Quantivo identifies unique pairs of values within incoming records and stores each pair only once. It then builds new pairs by identifying unique combinations of each pair with another element (which might itself be previously-identified pair). For example, the first analysis might find all transactions that involve a specific product on a single date. The second pass might find all transactions with that product/date pair that were made by a given customer. The process repeats, working up a hierarchy of combinations. The system also tracks the number of times each pair occurs and the specific records involved, so the full detail of the original data can always be reconstructed. The system doesn’t build pairs for all possible combinations of data elements, although users can define several hierarchies if they want the same element to be part of several pairs. Indexes also allow analysis across pairs that are not directly built into the data.

Quantivo doesn’t hide the details of its approach, but it doesn’t talk much about them, either. This likely reflects a (correct) judgment that users will care more about the system’s benefits than how it works. Those benefits include data compression (typically 10% of the original volume), fast response, high scalability, flexible schemas, handling unstructured data, and efficient processing of queries that cause problems in standard SQL. The choice of hierarchy also inherently organizes data around “concepts”, which can be different from the physical structures of the inputs. Queries are relatively simple because users see only a flat list of data elements; relationships are managed automatically, behind the scenes.

Yes there are trade-offs. The data must be processed during the load – a computation-intensive task that takes longer than creating a simple columnar database. The schema must be designed, which requires some technical expertise and can lead to slower response for queries outside the expected paths. Non-SQL queries require a Quantivo-built user interface, meaning users cannot stick with their familiar SQL-based business intelligence tools.

Some of these issues are mitigated by Quantivo’s other major differentiator: it was designed from the start as a true multi-tenant cloud-based solution.  This means it can easily spread its workload across multiple servers and replicate data as needed to support higher data volumes (billions of rows), reduce load times (typically one to two hours per day for daily updates), and improve response time. Support for multiple hierarchies and queries across hierarchies also minimize the price of making a bad decision during initial schema design, since even unplanned queries will execute reasonably efficiently. Designing a schema is relatively simple: in fact, Quantivo plans to add self-service data provisioning, including schema design, in the near future.

The Quantivo user interface is purposely designed to look like other business intelligence tools: users get a list of measures and dimensions, which they drag into place to create pivot tables. They can create filters, define calculated values, add summary levels, and drill down to details. There are simple graphics such as bar and pie charts, but no advanced visualization.

The unique power of the system lies within the filters, which can select data that’s outside the standard dimensions. For example, a filter could select all transactions for customers who purchased a specific product – the type of market basket analysis that’s hard with traditional SQL queries. The system also calculates “association metrics” which compare the data across two groups, such as products in the baskets including product A vs. products in baskets including product B.

Quantivo pricing is based on data volume and complexity. A typical client pays $40,000 to $50,000 per year for 100 million to one billion rows of data, making the system remarkably affordable for a product of its type.  Most clients are using the system for customer data analytics, and the vendor has created connectors for SAP, Salesforce.com, Marketo, Responsys, ExactTarget, Omniture, Google Analytics, IBM, Microsoft, and NCR systems. Quantivo launched as a cloud-based service in 2008 and has an undisclosed number of paying clients.