# Best Practices for Treasure Insights Dashboard and Insights Model Design

The following best practices provide tips to enhance your dashboard design and insights model design.

This topic contains:

* [Dashboard Design](/products/customer-data-platform/treasure-insights/best-practices-for-treasure-insights-dashboard-and-insights-model-design#dashboard-design)
* [Insights Model Design](/products/customer-data-platform/treasure-insights/best-practices-for-treasure-insights-dashboard-and-insights-model-design#insights-model-design)


## Dashboard Design

These are guidelines for improving the performance of dashboards:

* The number of recommended widgets in a dashboard is 7-10; every widget results in one or more independent queries.
* Limit the number of elements in the dashboard such as filters, as it results in additional queries being run.
* Presenting large amounts of data using a pivot or table widget with many rows adds to the dashboard load time.
* Avoid wide or long pivot tables. Reduce the number of columns and filter on values to reduce the number of rows.
* Avoid using a wide X-axis in line/column charts and fields with multiple items in the “break by” clause.
* Avoid too many include/exclude values and dashboard date functions. It is recommended to create the logic in an insights model instead.
* Dashboard performance can be improved by limiting the amount of data returned to render; aggregate data as much as possible.


## Insights Model Design

These are guidelines for improving the performance of Insights models:

* It is recommended to build the Insights model relationship between tables as either a 1-to-many or 1-to-1. Avoid many-to-many relationships.
  * One of the join keys should be the *unique key* for that table.
  * **If neither join key is unique,** this will result in a many-to-many relationship, which should be avoided.
* Any dashboard usage will generate a many-to-many query, causing a huge memory spike and should be avoided.
* Avoid creating a model relationship where 2 tables are joined on multiple columns.
  * Multi-column relationships impact query performance resulting in slower dashboards that consume more memory
  * Replace a multi-column unique key with a single-column composite/surrogate key
  * It is recommended that you create a dummy integer key for each unique combination of the columns that are needed to define uniqueness for a row.
  * If the columns that define uniqueness are 2 short strings:
* Add a custom column that concatenates them into a single string
  * Create the relationship on that custom column