I have being digging around the documentation of Platform and I haven't been able to figure out if it is possible to create different entities apart from the customer inside Platform. I am thinking for example in creating a entity like products that would have its own unique ID (an SKU for example) but it wouldn't be attached directly to a user.
An example of use case of what I would like to achieve is this:
Imagine you are a telco company and you have just upgraded one of your products package connection speed from 100 Mbps to 200 Mbps. One of the teams running email campaigns wants to target clients who have a speed connection under 150 Mbps. In order to not send the wrong campaigns we need to update the product information inside the database, I am seeing two possible approaches:
If there is only one possible entity (the customer):
If you can create several entities (one for customers and another one for products):
I don't know if creating a schema for products and not activating the Unified Profile feature would be enough to achieve this. Would you be able to define a specific ID for products and then use it to cross it with a product array inside a customer profile? I guess that through through the application of models that would be possible but without them not.
Just saw this, so will answer now as a reference for future searches.
Yes, you can create new types of entities in AEP now. The concept is called "multi-entity segmentation", and as you describe this allows you to create lookup data that can be tied to both XDM Profile schemas and also XDM Experience Event schemas for things like product lookup, zip code lookup, etc.
These fields can then be included in the segmentation logic boolean expressions same as your profile and event attributes.
The relationship is very similar to a relational database primary-secondary index relationship, with the added restriction that each relationship can be made based on only one field of type string. But any schema can have multiple relationships to the same or different lookup entities.
Best practice it to create a new class for this against the base class of "record", create a new namespace of type "Non-people" (very important), and then label one string field in your lookup schema as the primary identity using your new "Non-people" namespace.