4 tips for a great CDP implementation

If you’re reading this article, you’ve probably heard that customer data platforms (CDPs) have many benefits to offer. Among them is the ability to monitor site traffic, then “stitch” or connect this information to other data sources in your tech stack. 

While this is true, there is a caveat to consider during the CDP implementation process. A few choice decisions here can have a potentially massive impact on the audience size that can successfully connect website behavior to other existing internally stored data. 

Additionally, did you know where and when your CDP tag “fires” (i.e., when your website allows the CDP flag to begin its monitoring and tracking) could impact your analytics and metrics? 

Picture this: You work for Company Z. Your organization has spent a lot of resources (time, money, humans, etc.) to create a fantastic website. This front-end (a.k.a., “the site”) is brimming with opportunities to capture loads of fantastic visitor data; forms here, easy newsletter subscriptions there, and so on. 

On the back-end (a.k.a., the repositories where all that data is sent and stored)? A shiny CDP that’s already been integrated/connected to your CRM system of choice.

Well then, this must be the golden ticket. The formula for 100% data connection between site visits and first-party authenticated data, right? Well, not so fast. 

Here’s where I’d like to offer a few of the seemingly insignificant, yet potentially impactful CDP implementation and integration points to consider. 

1. Who’s handling (or has handled) the integration of the CDP within your organization?

Who is the day-to-day user? Is it self-service or managed by the CDP provider? It’s usually not the same group. (But if they are — hooray!) 

If they aren’t (i.e., the classic IT/marketing org mix), don’t fret. Knowledge is key in this scenario. The goal is to identify the key stakeholders and align oneself as closely as possible to them during implementation. 

Dig deeper: 10 CDP implementation mistakes to avoid

2. What’s being connected to the CDP? 

In other words, what additional sources of data are being “connected” together to create your ideal customer profile? For the purposes of this article, let’s stick with three components: 

• CRM will be the system that generates a “form” (i.e., email subscription, lead form, etc) as well as the repository for visitor data submitted via those forms.
• Website will be the system where a visitor lands, clicks on all sorts of fascinating information about your organization and is the “host” for the “form” generated by the CRM. 
• CDP (the proverbial “fly on the wall”) is the system that deploys a tag on your website, tracks the visitor click behavior, captures this click behavior including the data entered via the form (depending on your CDP setup) and finally, fulfills its promise by “connecting” the site visitor data to the authenticated data (i.e., form fill). 

You may pause here and think, “Well, I know the systems that are connected and which teams were responsible for the various integrations. I even have a complete data dictionary of each platform, so what’s the problem?”

If you have all of that identified, that’s excellent. But here comes the curveball… 

3. When does your CDP fire? 

Here’s a scenario that probably sounds familiar. 

Visitor comes to your website and is immediately served some illustrated form of consent questioning (i.e., “Do you consent to these cookies?”) and all of the other included fine print (i.e., types of cookies, what they mean, options to globally accept or reject the options, etc.).

Uh-oh… Is your CDP deploying before or after this question is asked? Which cookie category is your CDP tied to? Is it advertising, analytics, marketing, functional or essential? Is it the same globally? Is there a separate system in charge of recording that cookie opt-in? 

Do all these really matter? Perhaps. 

Statistics on cookie acceptance vary widely based on a number of factors, such as geography, consent regulations (i.e., GDPR), “cookie culture” and more. 

The best gauge for your own situation is to check internally with the appropriate team to get a better understanding of how cookie management is currently impacting your organization’s website. 

Here are two potential scenarios.

1: CDP tag “fires” as soon as the website is loaded. In this scenario, your site visitor activity begins to be accumulated and captured visitor prior to the visitor being served the cookie notification and/or taking action on it (which as stated above, can vary widely). 

This essentially means you’ve captured site behavior, on an individual level, prior to cookie acceptance (or rejection) that could potentially provide useful analytical opportunities to explore (i.e., site abandonment, length of time on site prior to engagement with cookie, etc.).

2: CDP tag “fires” after cookie consent is either accepted or rejected. Are you stating your metrics correctly? In this scenario, your general site visits vs. the number of profiles your CDP has created may be out of sync as the CDP is not allowed to begin its tracking until after the site visitor has taken definitive action (unless your cookie settings are set to default to “accept” vs. “reject”). 

4. Where is your CDP tag firing? 

Is your tag deployed directly onto your website? Or is it perhaps one of the many tags and pixels and other assorted goodies that are being deployed by your tag management system? 

Either setup is fine, but it’s useful to know and understand that each setup has its own downstream considerations. 

For example, let’s say you’re a marketer who will be activating audiences within your CDP platform. You not only plan to activate audiences but also create them directly in your CDP platform, instead of pushing existing segments from another platform like a CRM. 

Generally, to be able to do this, you’ll probably want to at least take a peek at the individual data fields available in the CDP so you can create your own audiences. 

However, depending on where your CDP tag fires and how it was integrated with the rest of your tech stack, you may not have a full line of sight into your website behavior. 

How does this work? Let’s say you launch your tag from a tag management system, but you didn’t integrate that system into your CDP. Sometimes, this results in what you could essentially refer to as a “data wall.” Here, the site traffic the CDP has captured is being stored within the tag management system, so you’d need to pop over into that platform to decipher captured data. 

The alternate scenario is deploying a CDP tag directly on your site, which will generally result in the ability to view this site behavior directly in your CDP platform and the ability to create audiences and the like. 

Dig deeper: How to ensure the success of your CDP initiative

Setting up your CDP for success

Now, this is not an endorsement of one integration method vs. another. It’s simply a piece of advice that I believe helps establish a solid foundation when using your CDP. 

I get it, you may not want to or be able to dig into this level of detail. As I mentioned earlier, aligning yourself closely with the relevant stakeholders can be a beneficial alternative that gets you to a successful outcome. 

By working with these points of contact, you can utilize their subject matter knowledge to more expediently get you to your end goals.

And now that you have these types of questions in your back pocket, you’ll also equip yourself to set a solid foundation as you dive into the powerful and constantly evolving CDP landscape. 

Opinions expressed in this article are those of the guest author and not necessarily MarTech. Staff authors are listed here.