• By limiting the number of records returned, adding a filter can significantly speed up reports.
  • Because they limit the amount of data returned by reports, you'd think filters would always make reports run faster. However because each record must be evaluated against each report filter, filters with complex logic can slow down reports. Apart from the performance-slowing filters described in this guide, adding a filter to return fewer records is a surefire way to speed up a sluggish report.
• Filter with EQUALS instead of CONTAINS
  • When you set a filter with CONTAINS the report executes many steps to return data, which slows down the report. EQUALS executes in fewer steps, resulting in a faster report.
• Filter with NOT EQUAL TO instead of DOES NOT CONTAIN
  • When you set a filter with DOES NOT CONTAIN the report executes many steps to return data, which slows down the report. NOT EQUAL TO executes in fewer steps, resulting in a faster report.
• Don't filter by row-level formulas
  • Filtering by a row-level formula slows down reports. If you have a slow-running report that filters by row-level formulas, speed it up by removing the row-level formula filters.
• Remove unnecessary columns
  • Much like returning lots of records can slow down a report, returning many columns can slow down a report. Many report types add a dozen or more columns to a report when it’s created. Removing columns you don't need speeds up the report.
• Avoid using the filter 'Contact ID' to include a few people in a larger Report
  • For example, if you have a Report of students it seems convenient to include a few people from your office in the Report based on their Contact ID. These Reports should be separate, one for students and a second for those in your office you need to be aware of delivery. 

• Start with a Report Type that uses the fewest objects, while allowing you to apply criteria without using a cross filter.
  • For example, instead of using the Contacts & Accounts Report Type, use the Contacts Report Type. This renders the same information while evaluating half as many records.
• When you need to Report across multiple objects, it's better to have those objects in the Report Type, rather than applying a cross-filter.
  • For example, instead of using a Contacts Report and using an Interests Cross-Filter, use the Contacts with Interest Report.

If you experience a failed send* to a Report, follow these steps:

1. Try the send again. Sometimes it is a fluke and sending at a different time is enough to get it out the door successfully.
2. If you haven't already made your Report as simple as possible (above), do so and try the send it again.
3. If it still fails, convert the Report to a Data Extension and use the Data Extension instead.
4. If your send still fails, contact the System eComm team with relevant details (MID, Email ID) to troubleshoot.
   • If sends continue to fail, a notification can be enabled in the Business Unit. Failed send notifications are only triggered due to "a system error or subscriber limit," so if the error is outside of these reasons, the notification will not be activated. eComm has yet to experience a failed send for a systemic reason, but there is no harm in enabling the notification.

* A failed send is not the same as a successful send to 0 individuals. We have other documentation to troubleshoot other sending issues.