One key element of Adobe Experience Platform (AEP) is its schema definition. If you have set that up correctly, there is a big chance that you will avoid many pitfalls and problems down the line when using AEP.
However, as I am starting to work with clients that either did not follow recommendations, or did not know the recommendations to follow when implementing Adobe Experience Platform, I am seeing many mistakes that are hard to fix.
As a consultant, I am starting to see some pattern emerging and, as usual, at some point, it bothers me so much that I decide to do a blog post about it.
So without further due, here are the common mistake to avoid when establishing a schema on Adobe Experience Platform:
Misunderstanding how schema work
I created a whole article on this, but understanding what a class is, what a schema is and what field groups or data types are is very important. So please check it out (especially as some mistakes such as creating a Data Type instead of a Field group are already discussed).
Most client I know imagine that they are actually modifying or editing schema when they moved field groups. They think that the class is not so important because everything ends up in Platform.
It is important to understand what area you can manipulate and what are native in the schema definitions. Without this understanding, the choices you are going to make will not have every possible considerations.
Modifying (Cloning) a default Field Group
When clients try to create a schema by themselves, they go read some articles, they play around the interface and decide that the official OOTB Field Groups are not good enough for them.
Fair enough!
This could have been one of my main common mistake: limiting yourself to OOTB field groups. Especially for the clients used to Adobe Analytics and its flat schema. If you still use eVar and prop with AEP and CJA… you need to seriously consider if you are making the most of AEP.
However, the issue I am talking about is when clients add custom fields to OOTB Field Groups.
Even if that possibility exists and is supported by AEP, what it is quite impactful.
By changing the field group that is official, you create a clone version that is snapshot of the official definition and its field. You will not receive any update of that field group if any comes. That can cause problem in the future if the field group receive important update that are required for some App Services (CJA, AJO, etc…).
Technically, you can ask the Adobe engineering to do a merge again from the main branch (Official Field Group) but it is a manual process.
It would also start creating dependencies on path that exist only within that official Field Group, within a namespace that you do not technically control, be it `experience or `web`.
My recommendation is always, if possible, to create your own custom field groups and set your new fields in your own namespace, such as `_tenant`. (tenant being a placeholder for your company).
Doing so, it makes handling the definitions, the replication and the promotion of such field groups way easier than custom OOTB field groups.
Wrong identities setup
A common mistake I am seeing very often is to setup a primary identity on your web schema.
It is expected on your web schema that your identity will be provided in the Edge, via AEP Web SDK server service, it creates an ECID automatically for any request (if one does not already exist).
A primary identity is required to be present in every event of an Experience Event dataset, or every record of an Individual Profile dataset. That element should only be possible for a device based identity, which in Adobe Experience Platform, is the ECID.
If you want to switch the primary identity, you can do that by setting the Primary identity in the Identity Map directly. It will not prevent the usage of an ECID but it could be a good strategy when it comes data retention and pseudonymous profile. (An article coming on that soon I hope):
Do not get business inputs when setting up schemas
When setting up Adobe Experience Platform, it is very tempting to try to replicate your current Adobe setup, be it Target, Adobe Analytics or Audience Manager.
The thing is that Adobe Experience Platform is much more than these 3 tools, combined.
It opens a lot more capabilities to the business users, but only if the setup is done correctly. It has a lot of prerequisites to be met in order to use the data in Adobe Experience Platform. Per example, for personalization, you could be more inspired to use Profile Attributes than Experience Event, for activating AJO, you better use streaming ingestion of event than batch ingestion of profile.
Not knowing what your marketing team wants to do and analyze, you may end up creating a good data storage but it is not usable. Alignment with the use-cases and scenarios that your team wants to use is important before modeling your data.
Getting data in the wrong class
This mistake has a strong correlation from the previous mistake. It is clear that if you do not have the right understanding on how the data will or should be used, you may end up putting the data in the wrong class, which could be the wrong format if you prefer to think that way.
There are ways to use the data (ex: Computed Attributes, Segmentation) but they may not cover your use-cases.
The clearest and most important information I see customer do mistake is consent. Being in America, Asia or Europe, everyone has started to require consent before activation.
The consent information must always be stored in an Individual Profile dataset. Do you want it in an Event Dataset as well ? Possibly, depending on your use cases, but Individual Profile first.
However, because many consent data points come from the web, they may end up in the wrong class …or as I said… the wrong format. 😉
Do not use the possibilities offer by the API
OK, this one is less of a mistake than a limitation.
The Adobe Experience Platform engineers are doing their best to provide you easy ways to manipulate, setup and activate the different elements you want in Adobe Experience Platform. There is now even a capability (Sandbox Tooling) to promote artifacts (Schema, Identity, Segments) between development to prod sandboxes.
However, with large companies buying Adobe Experience Platform, you would need to automate some tasks on managing, monitoring or analyzing the Adobe Experience Platform setup you have.
Luckily, we have a python wrapper that has been officially released for that, check out the aepp package.
I hope this article has been informative to you and let me know in the comment if you have noticed any mistake that you have done and wish you knew the implication of your setup before.