We use cookies. You have options. Cookies help us keep the site running smoothly and inform some of our advertising, but if you’d like to make adjustments, you can visit our Cookie Notice page for more information.
We’d like to use cookies on your device. Cookies help us keep the site running smoothly and inform some of our advertising, but how we use them is entirely up to you. Accept our recommended settings or customise them to your wishes.

True Value of Building a Comprehensive Marketing Model

In technology, data models serve a purpose much like blueprints in the construction industry. Though it’s impossible to imagine a multi-million dollar construction project without comprehensive and accurate blueprints being developed first, in the software industry, too often projects are attempted without proper investment in the development of a comprehensive data model. Generally the reason for that is simple: the time and the cost associated with the task of developing a data model can be daunting and technology staff can minimized the impact of not developing the model in their collective minds.

A comprehensive data model should contain logical and physical layers equipped with all of the following aspects:

  • The data model accurately represents the business overview of the solution it supports (for example, a solution for a multi-brand retail business that markets its products under multiple banners in both eCommerce and traditional stores and outlets). All the entities that are important to the business as well as the relationships between these entities are accurately represented in the data model.
  • The data model is developed by following the best practice sequence: conceptual → logical → physical.
  • The data model contains logical (business) entity and attribute names that are used to derive physical table and column names. All the names (logical and physical) are consistent across different projects and developed based on the naming best practices (such as always using a class world suffix, for example) and standard naming abbreviation.
  • The data model contains comprehensive definitions that don’t leave any ambiguity about the entity or the data element.
  • The data model as a deliverable consists of an entity-relationship diagram and an entity-attribute report, that replaces a data dictionary.
  • Logical data models are used to communicate with the business community and they have business names that accurately represent an entity or a data element from the business perspective. A relationship between the entities accurately represents the business rule (for example, an individual can be associated with multiple organizations at the same time).
  • The physical data model contains data types and lengths of data elements, indexes, views and other information that are important to the database developers, report developers, and campaign tool architects. Consistent object naming enables developers and other users of the physical data model to re-use their code and other assets.          
Obviously, development of a high-quality data model that supports all the above points is a big investment. Most data technology professionals have seen quite a few bad results when the decision was made not to invest in the up front development of a data model in order to try to save time or financial resources. Almost always, such projects require a lot of rework due to data quality issues, performance issues, misunderstanding of data structures by users and developers, and misunderstanding of the business rules that the database was expected to support. The results have consistently proven the importance of a comprehensive data model and that developing it the right way largely avoids such problems.

A best practice is to develop a set of data models that provide us with the ability to create a comprehensive data model for each project, but without a huge time investment. These templates are used as a starting point for developing a project-specific data model versus having to develop it from scratch each time. The templates are marketing data models that are also industry-specific. Each industry-specific template supports the information important to that industry from the marketing business perspective. This approach minimizes costs associated with the development of data models without sacrificing the quality; it also ensures scalability of data models for the client. For example, the marketing data model developed to support a retail industry client that currently only has a single brand is easily scaled to support multi-brand business if this client acquires other brands, because our retail template data model already supports that. Another example of this built-in extensibility is in insurance. If an insurance company that sells property insurance products decides to add an auto insurance line of business at some point, the data model will not need to undergo any major changes, since our insurance template data model already supports all of these product types and is already included in the insurance model.

The comprehensive model, when paired with the prebuilt data integration assets, BI, and campaign all translate into a more quickly deployed, lower risk, high efficiency solution for clients.

Merkle’s template data models support connecting customer information across brands, product lines, media, and channels, including anonymous big data, eliminating data silos, and providing the ability to analyze customer behavior and develop a centralized and consistent marketing approach. During the development of a marketing solution for a client, we simply extend industry-specific template data models to meet specific customer requirements that may be unique to them and deliver a comprehensive, scalable, flexible, and stable data model in much shorter period of time.