Being able to define segments based on multiple tables would be really valuable for B2B marketers, who know a lot more about their customers than just their birthday. For instance:
- past product purchases
- past service purchase, like training
- whether a contact visited a booth at a trade show
- whether a contact attended a conference/company event
I agree that simple cases can be handled with tags, but in my opinion this quickly becomes unmanageable when you add many dimensions to your customer profile. Example: I want to send a message to people who bought this particular consumable item several times in the last 24 months.
- I have a catalog of 20,000 references. Do I have to use 20,000 different values for the purchase tag field ?
- How do I capture the fact that a customer bought the same article 3 times in the last 24 months with a tag?
You really need the proper data structure here … which is a purchases table! Moreover with tagging, you have to anticipate all use cases and tag your contacts accordingly in advance. What if you discover new marketing ideas on the spot?
Having the whole 360° customer data available in a single database, usable from a marketing tool, is the holy grail of marketing/sales. The problem is that this customer data is generally scattered into multiple saas/internal apps/silos. The big advantage of an open source solution like Mautic is that integrating all these silos is possible without waiting for vendor’s, often half baked, integrations.
Support for multiple tables is also a solution around the mundane problem of having too many fields on the contact table, which breaks Mautic because of MySQL limitations. Hundreds of custom fields can be naturally organized into several smaller, yet more logical and easier to navigate tables.
One problem I see though, is expressing segments/queries joining several tables around a contact (typical star schema). Such a query will possibly aggregate several one-to-many relations around a contact, and will be complex to express with a graphical editor in my opinion. Use real SQL instead?
This feature would clearly be a very significant development. One first step in this direction, without going for the full multi-table stuff, could be to allow JSON values as a new data type for custom fields. You could then store the complete purchase history directly attached to a contact/customer in the appropriate JSON structure. However, the problem of easily expressing meaningful queries on such JSON arrays still remains.
If some other Mauticians are interested in moving this “multi table profile” idea forward, please let me know here.