Introduction to RTCDP B2B Edition
13 Nov 2022 » Platform
Although I have been 10 years at Adobe, during 9 of those years I had been oblivious to the business-to-business (B2B) world that lies out there. My customers had been from many different verticals: retail, telecom, banks, gambling, CPG… but all these cases were business-to-consumer (B2C). Last year I had my first encounter with a B2B customer; this year I have had two RTCDP B2B implementations. If you are a bit lost regarding the differences between B2B and B2C in the Adobe Experience Platform (AEP), this post is for you.
B2B vs B2C
Let’s start with the very basics. A quick internet search of “b2b vs b2c” will render thousands, if not millions, of results. In my search, Marketo’s page ranked 3rd: https://www.marketo.com/articles/b2b-vs-b2c-marketing/. At its heart, the difference is:
- B2C refers to a business that sells products or services to end customers.
- B2B refers to a business that sells products or services to other businesses.
While it may seem like a minor difference, the reality is that it is very big. Consider the following questions:
| Question | B2C | B2B |
|---|---|---|
| Who are the decision-makers? | One, two, maybe three people | Multiple people in a company, sometimes dozens |
| How long does it take to secure a sale? | From minutes to days | Weeks or months, and even years |
| How big is the deal size? | Small | Big |
| How do you win a deal? | “Wow” factor | Building trust |
The consequence of these major differences influences greatly the marketing activities and the marketing tools. AEP is no different and it required an extension to its core to support B2B clients. In the rest of this post, I will explain these additions.
Commonalities
Before I continue, I want to explain that everything you know about the standard, B2C edition of AEP, still applies in the B2B edition: identities, unified profile, XDM, datasets… And the architectural diagram that I have been showing a few times is, at large, still valid:
B2B data model
The main difference between the B2C and B2B editions lies in the data model. The B2C data model uses mainly two classes, the Individual Profile and the Experience Event schemas, with some use cases requiring custom lookup schemas. In B2B, you get 8 additional classes. Conceptually, they are still lookup schemas, but they carry crucial information for B2B marketing activities and have a special treatment. Tools like Marketo also have a similar data model. This is what it looks like in AEP:
The Person and Experience Event classes are the same as in B2C, although you will have noticed that we have renamed the Individual Profile to Person. You can find the previous diagram in the following URL: https://experienceleague.adobe.com/docs/experience-platform/xdm/tutorials/relationship-b2b.html?lang=en. If you are going to work with this data model, I recommend that you bookmark the previous page. I have used it countless times to follow conversations and to explain these concepts to my clients.
In a future post, I will explain in more detail this data model. From what I have understood in the conversations with customers and data architects, this model is fairly standard.
Identities
As I said above, AEP identities work exactly the same in B2B as in B2C. In principle, you would analyze the source data to identify a parameter that can be used to uniquely identify an entry in each schema. For example, email address for the Person schema. That being said, there is a twist to this explanation, very specific to B2B.
Primary identity
It is not uncommon to see B2B businesses with multiple CRM databases or marketing automation tools (like Marketo). For example, this can happen if the company is made of acquisitions or different business units operate almost independently. If you choose the primary identity to be the primary key of the source database, there is the risk of profile collapse. If the databases follow the same pattern of generating IDs, it could well be that two completely unrelated records get the same ID in different database engines.
The solution that Adobe suggests is to create a composite identity. This means that various parameters are concatenated to generate a new identity, which should be truly unique. To facilitate this feature, you can use the B2B Source data type.
A few clarifications are needed regarding the previous identity generation:
- This solution works for all B2B schemas, not just the Person schema.
- It is not mandatory to use it, only recommended.
- If you choose to follow the recommendation, the only mandatory attribute is
sourceKey, as this should be marked as the primary identity of the schema. - Even if you use these fields, you do not need to follow the recommended concatenation pattern for
sourceKey:[sourceID]@[sourceInstanceID].[sourceType].
The second consideration is closely related to the previous explanation. The additional B2B schemas (account, opportunity…) are linked to other schemas through the destination’s primary identities. Adobe’s proposed solution already takes the links into account and, by applying the same pattern to all ingested records, all links should work as expected. On the other hand, if you decide to use your own identities, you will need to come up with a solution that links the schemas correctly.
Additional identities
What about other identities? What if you have email addresses or telephone numbers? Well, as a CDP, AEP supports additional identities. If you have checked that they are unique in your databases, you can (and probably should) mark these fields as additional identities to extend the device graph.
Limitations
At the time of writing this post, there is one major limitation in the B2B edition: all B2B tables behave like lookup or auxiliary tables. In other words, they are not treated like Individual Profile schemas. This has two consequences:
- Your segments can only be of persons. You cannot create segments of accounts or opportunities.
- You cannot export fields in the B2B schemas other than the Person schema. If you need to export such fields, the best workaround is to copy the values you need to a Person schema and dataset.
I would strongly recommend that, if you have use cases that stumble upon these limitations, you ask your Adobe representative. It could well be that, by the time you read this post, they have been lifted.