RTCDP B2B Schemas

27 Nov 2022 » Platform

As I said in the introduction to RTCDP B2B, marketing automation activities are very different in B2B compared to B2C. If there is one detail that I have found particularly difficult to understand in B2B, that is the data model. The first time you see it, it feels too complex, until you start to understand what it is all about. This post is an explanation of the AEP B2B schemas, using my own words. My goal is to help you understand this data model if you, like me not that long ago, have no clue about it. Any subject matter expert could write a dissertation on each schema. However, my goal in this post is to help newbies. If you find any error, let me know in the comments and I will fix it.

Last week, I was in a conversation with one of my clients, and the data architect was explaining some details about the B2B data model. I could notice that she was having trouble following the explanation. I also understood why, as I had been in that same situation. I intervened, showing her this standard diagram:

B2B Classes

Half jokingly half seriously, she said that she was going to put it as her screen background. Again, I was with her, as this picture has helped me a lot when dealing with the B2B data model. I therefore also recommend that you bookmark the following URL, where this diagram comes from: https://experienceleague.adobe.com/docs/experience-platform/xdm/tutorials/relationship-b2b.html?lang=en.

In the next sections, I will briefly explain each of the schemas. If you get lost in the explanations, I suggest that you come back to the top of this post to review the diagram.


This is the standard Individual Profile schema that you are already used to in AEP, with just a different name. It is also worth noting that this is the only mandatory schema; the other schemas are there to support this main schema. At the end of the day, people sign contracts or acquire products and services, not companies.

You also need to take into account that, in the B2B world, there is a division in the Person schema:

  • Lead. These are people who are showing interest in your products or services, but you do not have much information about them.
  • Contacts. Once you know that this person is interested in what you have to offer, but they are not ready to convert yet, they are known as contacts.

There is no technical division between the two. However, if you need to identify which type of person a particular profile is, you need to make sure you have enough information in the data model to identify this type.


This is probably the most important additional schema that you will work with. If you have heard the concept of Account Based Marketing (ABM), this schema is key to it. The profiles that you have in the Person schema work or consult for entities (businesses, government agencies, non-profits). It is in the Account schema where you keep the list of all these entities, together with all their attributes: name, location, size… AEP also supports a hierarchy of accounts, denoted by the arrow that points at itself.

With the Account schema, you can create segments of leads or contacts that:

  • Work for a particular company
  • Are in a given vertical
  • Work for a company in a specific region

Finally, be careful when you the term “account” for other concepts that colloquially are also referred to as accounts, but are not in the B2B jargon. It can lead to confusion. For example, an account at Amazon or Google does not denote a company, but a single profile.

Account-Person Relation

Initially, you would expect that one person works for one company. In this case, you could add a direct relationship between Person and Account, supported by the data model as shown in the diagram. This is a one-to-many relationship: one account can be referenced by many persons. However, there are many cases where this is not enough. Consider the following examples:

  • An external consultant can work for multiple companies, supporting them in the process of acquiring a new product or service.
  • One employee working for a parent account is also responsible for multiple child accounts.
  • One person quits from one of your clients and starts working for another client. If your database is not regularly updated, you may have this contact linked to 2 accounts.

If you are in this situation, you need a many-to-many relationship between Person and Account. This is where the Person-Account Relation schema saves the day. Remember that this is an optional schema, which you should only use if you need it. It is also worth noting that you can use this schema to add attributes to the relation. One example where this is useful is when the person plays different roles for each of the accounts he is working with; in this case, the role would be an attribute of the relation.


This is part of the B2B sales jargon. I assume that opportunity is short for “sales opportunity”. Once the sales team has reached out to a contact and this contact has stated that the account is interested in their offering, the sales team can create an opportunity. As you can imagine, an opportunity should have links to the multiple people involved in it and the account that is going to acquire your services or products.

This Opportunity schema has a lot of additional information about the potential revenue and products/services that can be sold, which makes it very useful for segmentation.

Opportunity-Person Relation

As I have just explained above, one opportunity will be linked to multiple people: the decision maker, the point of contact, the influencers… At the same time, one single person can be involved in multiple opportunities: it is common practice to open multiple opportunities, depending on the services or products that could be sold. You are probably already seeing that the Opportunity and the Person schema requires a many-to-many relationship. It is so prevalent, that the direct connection between these two schemas is not even considered.

As with the Account-Person Relation, you can use this intermediate relation to add additional attributes that are specific to the combination of Person and Opportunity.

Marketing List

Marketing lists allow you to prioritize prospective clients who are most likely to buy your product. Typical examples of such lists are Marketo’s smart lists and static lists.

Marketing List Member

A contact can be part of multiple marketing lists and one marketing list can have multiple profiles. So, a many-to-many relationship is needed.


One of the main features of marketing automation tools like Marketo is to manage marketing campaigns. The Marketo website defines a marketing campaign as, […] a strategic sequence of steps and activities that promote your company’s product or service, with a specific goal in mind. Multiple campaigns are then grouped under a program.

Campaign/Program Member

As I said earlier, marketing activities target real people, not accounts. One person can be part of multiple campaigns and one campaign will target multiple individuals. This many-to-many relation is captured in the Campaign/Program Member.


As a closing remark, I have not documented much of the last four schemas. I have to admit that I do not have much experience with them and I cannot go any deeper. However, I will also add that in the RTCDP B2B projects I have been working on, they have always been a very low priority and have been left from the MVP implementation. I assume that they are not that important in general, at least from a CDP perspective.


Photo by Thirdman

Related Posts