I've been working with BlueConic now for a few months. I am pleased with the features available for such a low price point. Integration with other technologies has been relatively pain-free. With that said, it is the engineers behind BlueConic devised the platform feature set to go beyond a strict CDP's scope and into both personalization and email marketing. I can understand why: a CDP feature set is complimentary to many other marketing technologies (personalization, A/B testing, marketing automation). But if a company has not invested in those other technologies, the value proposition for a CDP is hard to demonstrate. Building in some ancillary features helps solve that problem.

BlueConic, like many technologies of its kind, has a particular value proposition which defines it, and that is collection, segmentation and distribution of audience data. As such it should only really be evaluated by that capability. Any other features are not why you get a CDP, and a good CDP will perform these three functions exceptionally well, aside from anything else.

So, let's evaluate the core of BlueConic. We will broadly discuss their Listeners, Segments, and Connectors as representative of the core features of the platform. Then we'll also cover some additional features which differentiate BlueConic from other CDPs.

Core Features

Listeners

Listeners is the name of the feature which BlueConic presents as a main means of data collection. This is a rules-based configuration, where you direct the system to collect data on all manner of things from website events to location and time analysis. They listen for triggering events, then update a person's profile with new data.

It comes pre-configured with some out-of-the-box listeners. These are handy data collectors, and I've been impressed with the amount of forethought that went into them. Beyond that, I immediately found the Listeners configuration tool quite limiting because of the complexity of conditions I have for my critical events. After some attempts to get BlueConic listeners coordinated and functioning with my other technologies, I abandoned them in lieu of their Javascript API.

This isn't a deal-breaker. It's a result of already having invested in a tag management system, data layer, and personalization platform. I need to leverage these investments, which means I need BlueConic to integrate into the web page and coordinate with these other systems. I have other tools to trigger events to which BlueConic is subordinate, for a few good reasons. Those event triggers will use the API to communicate profile changes to BlueConic servers. So for my critical events, Listeners didn't work for me.

Still, you can really do a lot with these in general. Each listener either throws an event code to trigger other listeners or changes profile data based on specific conditions, so a complex implementation could get out of hand very quickly with hundreds of listeners to get the job done. For one reason or another each time I would set out to use a Listener to collect behavior data or something, there is always a missing feature or limiting constraint that made it overly complex. In the end I still use the API to make profile data updates, integrated with the data layer system. But I kept the default global listeners they set up. Those are handy for segmentation.

Segments

Segmentation is very straightforward. You can set up conditions with "and/or" clauses. I wish you could do that with Listeners, which is a major limiting factor and why I don't use them. But you can with segments. It's really a glorified query system so my expectation is that I be able to construct whatever rules that I could in a SQL database. It's an easy bar to reach, and they do it just fine. Advanced segmentation capabilities, like statistical models, are likely to require implementation through the plugins feature.

Segments are processed for each profile via a couple of properties. One of them is a comma-delimited string of all segments a given profile is in. This key piece of information is the most useful output of a CDP. Distribution of this along with other profile data to other systems in real time is what constitutes data "activation".

Connections

No problem, that's what Connections are for. But I have hit a snag in that I am unable to use a connection to send segment data to other martech platforms directly. I want to be able to send a profile with all of the presently associated segments to any system I like. We can't do this with BlueConic. We can use what they call a 'firehose connection' to send all profile data to another event queuing system, like Amazon Kenesis. From there I can send the data on to my marketing automation platform, analytics platform, and sales CRM.

So why this distinction? It's unclear to me at the moment. But it underscores the importance of having cloud services available to fill the gaps around your platform investments. We are not quite to the place where platform-to-platform interfaces will solve all of the business needs for marketing. We have to have capable systems where we can make custom solutions so that our strategies can come to life.

Other Features

Objectives

Objectives are the instantiating concept in BlueConic. This is a big deal for the platform, and a super idea. Everything we do in customer interaction is toward an Objective. So, BlueConic has you state these objectives explicitly in a series of containers. These containers are then filled with all of the other elements that work toward those objectives: connectors, listeners, dialogues, segments, etc. This is a novel idea and it serves to reinforce the notion that everything we do is to serve a purpose.

Extending the concept of objectives is the notion of consent. We need a person's consent to use data toward an objective. So getting their consent to the objective would grant consent for the elements in service of the objective. Brilliantly simple. And all of the consent states for a profile are stored in accessible properties.

Dialogues

This is a superfluous feature for a CDP to have. It is better to relegate this to a fully-featured personalization platform, like Optimizely. But since we cannot simply send segment data to Optimizely, we are constrained a bit to attempt to use BlueConic to do content modification first instead. It's a manageable interface, and you can get pretty complex. Notably cool is the JSFiddle-like advanced interface, where you can build your own templates.

One dialogue I can think of serving value would be the Pre-fill Form Dialogue. This should map profile data to a detected form without having to 1) route the profile data to the data layer, 2) feed the data to the personalization engine, and finally 3) fill in the form with custom scripting. I have this running on my site, and I am happy with it.

Another which is of value is the consent management tools available in BlueConic. They have pre-built tools that you can drop into your site to collect consent for the Objectives you have defined. These changes to consent for Objectives can enable/disable the BlueConic features associated with that Objective. Consent management is one of the great aspects of a CDP, and BlueConic has an admirable implementation of the concept.

TL;DR

This is a great CDP for the cost. And if you haven't already bought into the other parts of a marketing stack, you can go a long way with this platform alone. I rely on BlueConic as the first choice candidate for my business engagements who have little or no martech investments already.

I am wary of a tool that goes beyond its intended feature set to do things it shouldn't before it has mastered the features that it should. Remember, a CDP should collect, segment and activate 1st party data. BlueConic deserves some forgiveness for this because they are pioneering a new genre of tools. Doing that requires some demonstrative effort. So they have made the platform capable of doing personalization and email directly, even though there are much better tools for that. I would expect BlueConic to evolve their core features and improve collaboration with other platforms going forward.

For instance, BlueConic can improve data collection by integrating better with TMS systems on the market (and by extension, the data layer that those systems manage). They can also improve segmentation by allowing more advanced model integration and profile property transformation in the UI. And lastly, they can improve data activation by getting more collaborative (read: share those segments with other systems directly). Enhancement of Dialogue features should only come after.