Classifying CDPs: Another Try

November 29, 2017

I’m still working on the project to clarify differences among CDP vendors.   The latest iteration is based on a functionality map I put together to help non-CDP vendors understand where they fit in the industry.   This was based on the Data, Decisions, Delivery layers I often use to classify components of an over-all marketing stack.  It applies to CDPs because many CDPs extend beyond the Data layer to offer Decision and Delivery functions.   It also highlights that even many Data functions are optional.

The latest version of the map is below.  As you see, it gives each channel (email, Web site, mobile device, etc.) its own set of possible functions for message delivery, content creation, optimization, and connectors.  This makes sense because those functions usually channel-specific.   I’ve cheated a bit by putting all channel-specific functions on the Delivery layer, including a few such as content creation and prebuilt connectors that I usually consider part of the Decision or Data layers.  It’s just easier to understand the results when all functions related to each channel are presented together.

The remaining Decision and Data functions are not channel-specific.  I’ve grouped them into broad categories (campaigns, analytics, ingestion, storage, etc.) and then listed specific capabilities for each category.  This is a departure from the approach I described in my last post on this topic, which aligned all types of functions with specific channels.  At the time, I noted that only about half of all the functions I listed actually did apply to a particular channel, even when I allowed pseudo-channels including un- and semi-structured data, real time processing, and B2B marketing.  In reality, there’s fairly little connection between the items on different rows, so I don’t think we lose much clarity dropping the channel-based organization for decision and data layers.

Marketing System Capabilities
execute email web mobile mail call center social ads display ads search ads POS
optimize email web mobile mail call center social ads display ads search ads POS
create content email web mobile mail call center social ads display ads search ads POS
message connectors email web mobile mail call center social ads display ads search ads POS
audience connectors email web mobile mail call center social ads display ads search ads POS
ingestion connectors email web mobile mail call center social ads display ads search ads POS
access connectors email web mobile mail call center social ads display ads search ads POS
campaigns no-code interface multi-step multi-channel journey framework schedule based trigger based real time interact rules select messages scores in rules
analytics segment BI/ explore ideal customer manual models automated models recommend products incremental attribution
content no-code templates store workflow cross-channel dynamic content auto-test/ optimize auto-classify (NLP, video)
admin budgets project mgmt marketing plans simulate results optimal spend by channel
ingestion structured semi- & un- structured no-code set-up high volume batch real time stream API find deltas
storage raw detail multi-table data model auto-add attributes manage PII in-memory dynamic scaling industry data models B2B data model read external
identity stitch offline match cross device match identify devices persistent ID lead to account anonymous to known golden record
enrichment location intent personal postal B2B data feature extraction external device graph external ID graph
access extract API SQL/HQL analytical data sets prebuilt connectors

What I like about the map is exactly that it encompasses all marketing functions, not just what’s done by a CDP.  This lets it accommodate any function built into any CDP, now or in the future.   This, in turn, lets us identify sets of functions needed to meet particular requirements.  For example, the shaded boxes on the map I’ve published here are the minimum functions required to qualify as a CDP.  Other collections might define functions that are common or support specific use cases such as online-only marketing or journey orchestration.  But I’m getting ahead of myself.

The other big departure that this map makes from my last effort was the boxes contain general functions (“offline match”) , not specific technical features (“name/address standardization, postal address verification, similarity matching”).  In some cases, additional technical criteria are probably needed to clarify what would or wouldn’t qualify as having that feature.  Those could easily be appended to this map.  But in many cases, the general function description is specific enough that it should be fairly clear whether or not a particular system qualifies.  To help things along, I’ve added another version of the table below that gives more specific definitions for each box.  I still wouldn’t necessarily ask vendors to decide for themselves whether they qualify for a particular box, but I think these are specific enough to make it pretty easy for an objective observer to make that judgement and get the vendors to accept it.

Keeping them somewhat general also fits with the broad purpose of this exercise, which is to help marketers understand which systems have the types of functions they need without trying to provide the details of how each system performs those functions.  That more detailed analysis is something that marketers need to do for themselves based on direct interaction with the vendors.  In other words, we’re only helping marketers exclude the clearly irrelevant products, not create a short list of the best systems for their purpose.

Delivery (by channel)
execute send complete messages and audiences in the specified channel (email transfer agent, Web CMS, mobile app, mailing list generation, Adwords bid, programmatic display ad bid, retail POS)
optimize automatically run tests and pick winning message (a/b or multi variant copy testing; possibly find best message per segment)
create content the system provides tools to create content in the specified channel
message connectors prebuilt API or SDK connectors to send message components to specified channel systems (templates & personalization variables inc. customer IDs; no configuration needed beyond providing credentials)
– Web ability to personalize anonymous users based on device, campaign, referrer, location, weather, behavior, etc.)
audience connectors prebuilt API or SDK connectors to send campaign audiences to specified systems (email lists, next best offer lists to Web personalization, advertising audiences, etc.)
– display ads ability to continuously update audience segments, to send suppressions lists, to cookie synch with DMP/DSP; DMP functions
– social ads ability to continuously update audience segments, to send suppressions lists
ingestion connectors prebuilt API or SDK connectors to ingest data from specified systems (e.g. MailChimp, Sitecore, Google Analytics, Adwords, Facebook, BlueKai DMP, NCR POS)
– Web Web tag management, own Javascript site tag, capture non-click Web behaviors e.g. time spent, page tags, product categories; extract UTM parameters
– mobile collection of mobile device attributes and location, batch mobile data collection to save battery
access connectors prebuilt API or SDK connectors to expose data to specified systems (e.g. MailChimp, Sitecore, Adwords, BlueKai DMP, NCR POS)
no code interface users can set up marketing campaigns by filling out forms or drawing a flow chart; no writing of code or script
multi-step one campaign can include a sequence of messages over time
multi-channel one campaign can include messages in different channels
journey framework the system can track customers through user-defined journey stages or states; campaigns can be triggered when a customer changes state; state is available to use in campaign rules
schedule based campaigns can be set to execute on a regular schedule e.g. daily, hourly, weekly
trigger based campaigns can be set to execute when a trigger event occurs; triggers may be recognized immediately or at a given interval (e.g. nightly)
real time interact campaigns can react in real time to customer behaviors
rules select messages rules within a campaign can select messages (i.e., different customers get different messages depending on the rules)
scores in rules rules within a campaign can use predicitve model scores or other modeled values (e.g. cluster membership) as inputs
segment the system provides tools to define customer segments based on all data within the system
BI/ explore the system provides tools to analyze all data within the system, such as cross tabs, profiles, visualization, etc.
ideal customer the system provides tools to identify an ideal customer profile
manual models the system provides tools for skilled users to create predictive models
automated models the system provides tools for unskilled users to create predictive models
recommend products the system provides tools to generate product recommendations (best choice among many)
incremental attribution the system provides tools to calculate the incremental value created by any single marketing action
no-code templates the system lets users apply templates to create content without coding in HTML, etc.
store the system provides a repository to store and access content to use in marketing messages
workflow the system includes workflow functions for content planning and approvals
cross-channel the system can create content that is used across multiple channels
dynamic content the system can create messages that contain rules to select content based on customer data and other variables (time of day, weather, inventory, etc.)
auto-test/ optimize the system can automatically execute tests that find the best content for a given campaign and deploy that content. Tests might compare complete pieces of content, different combinations of content components, and/or different content for different customer segments.
auto-classify (NLP, video) the system can automatically tag content based on subject, tone, images, brand, etc.
budgets the system can track budgets and spending against budgets for marketing campaigns and other marketing expenses
project mgmt the system can track tasks to develop marketing campaigns, including due dates, status, resources assigned, approvals, etc.
marketing plans the system can track marketing plans including campaign schedules and expected results
simulate results the system can simulate the results of a planned set of marketing campaigns over time
optimal spend by channel the system can develop an optimal marketing plan including allocation of spend across different channels and campaign types
structured the system can ingest structured data such as CSV files and relational database tables
semi- & un- structured the system can ingest unstructured and semi-structured data such as text comments and Web logs; specific requirements include nested JSON objects
no-code set-up users can set up a data feed into the system without writing program code
high volume the system can handle high volumes of input data (we need specific criteria)
batch the system can ingest data via batch feeds such as CSV files
real time the system can ingest data via real time feeds such as API calls
stream the system can ingest data via data streams (we need specific criteria)
API the system can ingest data via API calls, not necessarily in real time
find deltas the system can ingest copies of a complete data set and identify and store only changes since the previous version of that data set
raw detail the system can store inputs without losing any details
multi-table data model the system can store data that is organized into multiple tables or data types
auto-add attributes the system can automatically accommodate new attributes in input data (without manual adjustments to the data model)
manage PII the system can manage personally identified information (including compliance with privacy regulations for access and security)
in-memory the system can store data in-memory (for fast access and processing)
dynamic scaling the system can automatically accommodate changes in demand through features such as dynamic load balancing, addition of new processors and storage, etc.
industry data models the vendor has prebuilt industry-specific data models (for retail, travel, financial services, communications, etc.)
B2B data model the system has a prebuilt B2B data model with separate account and individual layers
stitch the system can maintain relationships among personal identifiers that are deterministically matched to the same individual
offline match the system can match offline data (names and addresses) with features including name and address standardization and similar-string matching
cross device match the system can maintain relationships among devices that are probabilistically matched based on usage patterns
identify devices the system can identify devices over time using cookies, device fingerprints, and other methods
persistent ID the system can assign each individual an ID that remains the same despite changes in identifiers (new address, new device, etc.)
lead to account the system has features to match individuals (business leads or contacts) to business accounts (companies or departments).
anonymous to known the system has features to retain identity links when an anonymous profile is linked to an identified cusstomer profile
golden record the system can select the most likely value for personal data (name, address, etc.) and expose it to other systems
location the system has prebuilt integrations with location data providers (data about venues e.g. store traffic; possibly data about individuals e.g. types of stores visited)
intent the system has prebuilt integrations with intent data providers (data about topics or products individuals are interested in)
personal the system has prebuilt integrations with personal data providers (data about individual name, address, phone number, income, education, interests, etc.)
postal the sytems has prebuilt integrations with postal and address data providers (data about valid postal addresses and address changes)
read external the system can connect in real time with external systems to look up specified data (local weather, recent behaviors, etc.)
B2B data the system has prebuilt integrations with B2B data providers (data about companies and individuals e.g. company revenue, CIO name)
feature extraction the system can extract structured data from unstructured inputs (e.g., products mentioned in social media comment, products viewed from Web log)
external device graph the system has prebuilt integrations with external vendors (e.g. TapAd, Crosswise, Google) who provide a list of devices associated with specific individuals
external ID graph the system has prebuilt integrations with external vendors (e.g. LiveRamp) who provide a list of identifiers (in different channels) associated with specific individuals
extract the system can generate batch extract files to share with other systems
API the system has an API that can be called to retrieve data it contains
SQL/HQL the system can accept SQL or related queries and return the results to external systems
analytical data sets the system can create extract files in formats suitable for analytics (e.g., containing aggregates or with multiple tables flattened to a single row)
prebuilt connectors the system has prebuilt connectors for specific external systems e.g. BI tools, predictive modeling tools, etc.

As you examine the second table, you’ll notice that the Delivery section shows one definition for each row, while the Decision and Data sections show one definition for each box on each row.  I think you’ll see that makes sense.  But I’ve also allowed a few exceptions in the Delivery section, such as “Web” under “manage connectors”, where I’ve listed specific technical criteria that apply to a single channel.   This is simply an efficient way to present that information.

Over-all, I think this approach brings us closer to a workable solution.  No doubt there are more items that could be added, although too much detail would be bad.  There’s also an objection that function checklists like this are easily misinterpreted to suggest that systems with more functions are better.  That’s certainly a danger, but I’m hoping that marketers know enough about their needs to look only at the functions relevant to their situation.   This approach does avoid creating a vendor typology, which was implicit in the previous approach and seemed likely to cause confusion.

The next step is to get feedback from the community about whether this approach seems reasonable and about specific items they’d add or remove from the map.  After that, we’ll need to assess the functions provided by individual CDP vendors – a great deal of work but something that is probably inevitable.   Once that’s done, we can publish a proper guide to the vendor systems, making it easier for marketers to find products that meet their needs.

What do you think?