As a placeholder for storing objects
The "Interactions" entity can be seen as a log of events connected to a contact. All the interactions stored for a contact can't be changed once saved, although they can be deleted. However, the Engage interactions schema also allows a retailer to collect data on anything else that could be encoded as an interaction, for example the cars or pets owned by a specific contact.
Example: Subscriptions
A retailer's business might involve subscription-based services. The events involved when such a subscription starts, changes or ends can easily be expressed as interactions.
It's possible to save the active subscription to a contact as a specific interaction type and then delete it when it is no longer valid. This allows the Engage user to segment customer with a specific number of subscriptions active. All the detailed information could be put into the interaction schema as properties, either for display in the Engage contact card or for use in automations.
For targeting this is somewhat limited in that Engage can’t tell how many active subscriptions a contact has at any one time.
Limitations
As the Interaction format is so flexible, Engage is unable to understand every possible schema, meaning you can't segment on all the properties of an interaction. For example, it's not possible to fetch all contacts that have Interactions with a specific property field, or based upon how many contacts have a certain interaction saved to them, regardless of the other metadata on those interactions.
So even if an Engage user adds Pets or Cars to the interactions table they still won’t be able to segment on how many contacts have a certain number or brand (or breed) of pets or cars.
A contact related to several objects need a new entity type
A new approach is under consideration where customers can define the structure and number of object types they want to store. This could help address some of the issues encountered when using interactions to store objects instead of events, as well as the problems mentioned below. This could help to widen the use cases.
Alternatives to Interactions
It's possible to encode objects and their properties as multiple custom attributes. This is a fairly easy way to deal with having different properties for each instance of an object. It's done by giving the contact model a set of fields, some of which might be empty. For example:
Car1-type, Car1-brand, Car1-year
Car2-type, Car2-brand, Car2-year
Car3-type, Car3-brand, Car3-year
Car3-type, Car3-brand, Car3-year
A limitation here is that it becomes cumbersome to segment based on how many of an object a contact has.