Thursday, October 20, 2016 Offers A Customer Data Platform for B2B Marketers

The need for a Customer Data Platform – a marketer-controlled, unified, persistent, accessible customer database – applies equally to business and consumer marketing. Indeed, many of the firms I originally identified as CDPs were lead scoring and customer success management vendors who serve primarily B2B clients. But as the category has evolved, I’ve narrowed my filter to only consider CDPs as companies that focus primarily on building the unified data.  This excludes the predictive modeling vendors and customer success managers, as well as the big marketing clouds that list a CDP as one of many components. Once you apply that filter, nearly all the remaining firms sell largely to B2C enterprise clients. is an exception. Its clients are mostly small, B2B companies – exactly the firms that were first to adopt software-as-a-service (SaaS) technologies including marketing automation and CRM. This is no accident: SaaS solves one problem by making it easy to acquire new systems, but that creates another problem because those systems are often isolated from each other. Hull addresses that problem by unifying their data, or, more precisely, by synchronizing it.

How it works is this: Hull has connectors for major customer-facing SaaS systems, such as Salesforce, Optimizely, HubSpot, Mailchimp, Facebook custom audiences, Slack, and Zendesk. Users connect with those systems and specify data elements or lists to synchronize. When data changes in one of customer-facing products, the change is sent to Hull which in turn sends it to other products that are tracking that data.

But, unlike data exchanges such as Zapier or Segment, Hull also keeps its own copy of the data. That’s the “persistent” bit of the CDP definition. It gives Hull a place to store data from enhancement vendors including Datanyze and Clearbit, from external processes called through Javascript, and from user-defined custom variables and summary properties, such as days since last visit. Those can be used along with other data to create triggers and define segments within Hull.  The segments can then be sent to other systems and updated as they change.

In other words, even though the external systems are not directly reading the data stored within Hull, they can still all work with consistent versions of the data.* Think of it as the martech equivalent of Einstein’s’ “spooky action at a distance”  if that clarifies things for you.

To extend its reach even further, can also integrate with Zapier and Segment allowing it to exchange data with the hundreds of systems those products support.

Three important things have to happen inside of to provide a unified customer view. First, it has to map data from different sources to a common data model – so that things like customer name or product ID are recognized as referring to the same entities even if they come from different places. simplifies this as much as possible by limiting its internal data model to two entities, customers and events.  Input data, no matter how complicated, is converted to these entities by splitting each record into components that are tagged with their original meaning and relationships. The splitting and tagging are automatic, which is very important for making the system easy to deploy and maintain.  Users still need to manually tell the system which elements from different systems should map to the same element in the shared data.

The second important thing is translating stored data into the structure needed by the receiving system. This is the reverse of the data loading process, since complex records must be assembled from the simplified internal model. What’s tricky is that the output format is almost always different from the input format, so the pieces have to be reassembled in a different format.  While we’re making questionably helpful analogies, think of this as the Jive Lady translating for the sick passenger in the movie Airplane.

The third key thing is that data relating to the same customer needs to be linked. Hull will do “deterministic” matching to stitch together identities where overlapping information is available – such as, connecting an account ID to a device when someone uses that device to log into their account. Like many other CDPs, Hull doesn’t attempt “probabilistic” matching, which looks for patterns in behavior or data to associate identifiers that are likely to belong to the same person. It does use IP address to associate visitors with businesses, even if the individual is anonymous.

All told, this adds up to a respectable set of CDP features. But Hull co-founder Romain Dardour says few clients actually come to the company looking for a unified, persistent customer database. Rather, they are trying to create specific processes, such as using Slack to send notifications of support tickets from Zendesk. Hull has built a collection of these processes, which it calls recipes. Customers can use an existing recipe or design their own. Dardour said that once clients deploy a few recipes they usually recognize the broader possibilities of the system and migrate towards thinking of it as a true CDP, even if they still don’t use the term.

This is consistent with what I’ve seen elsewhere.  Big enterprises can afford to purchase a unified customer database by itself, but smaller firms often want their CDP to include a specific money-making application. That’s why my original B2B CDPs usually included applications like lead scoring and customer success, while the B2C enterprise CDPs often did not.

The other big divide between Hull and enterprise CDPs is cost. Most enterprise CDPs start somewhere between $100,000 and $250,000 per year and can easily reach seven figures. Hull starts as low as $500 per month, with a current average of about $1,000 and the largest clients topping out around $10,000. Price is based primarily on the number of system connections, with some adjustments for number of contact records, guaranteed response time, data retention period, and special features. Hull has over 1,000 clients, mostly in the U.S. but with world-wide presence. It was founded in 2013.

*You could argue that because the external systems are not reading’s data directly, it doesn’t truly qualify as a CDP. I’d say it’s not worth the quibble – although if really massive amounts of data were involved, it might be significant. Remember that is dealing with smaller businesses, where replicating all the relevant data is not a huge burden.

No comments: