The maximum number of times Optimize tests combinations of proposed transactions, or alternatives, to find the optimal alternative for a customer.

Since the number of alternatives to test might be large, this value allows you to place a limit on how much effort the core algorithm spends on a customer before Optimize moves to the next customer in the PCT.

If your number of customers being optimized is greater than CustomerSampleSize, Optimize divides the customers into groups of no greater than CustomerSampleSize and optimizes each sample group separately. Rules which span across groups, such as a Custom Capacity rule, are still met. Increasing this number might increase optimality but hinder performance.

The most optimal CustomerSampleSize is equal to your number of customers. However, processing a large set of data might take a prohibitive amount of time. By dividing customers into smaller groups for Optimize to process at a time, you can increase performance with minimal loss to optimality.

The random seed represents the starting point that Optimize uses to select records randomly before populating sample groups defined by the CustomerSampleSize. If you have fewer customers than CustomerSampleSize, this property has no effect on the optimization.

The maximum number of iterations Optimize processes a group of customers. Optimize processes a group of customers until optimality is reached or the number of iterations equals MaxIterationsPerCustomerSample.

Search for the following information in the session log to observe the effect of setting changes for MaxIterationsPerCustomerSample.

The maximum number of threads Optimize uses to process the optimization algorithms. In general, the higher you set MaxCustomerSampleProcessingThreads, the more you might improve performance. However, the performance increase is limited by several factors including the type and number of optimization rules you use and your hardware. For detailed instructions on tuning your Optimize implementation, contact your IBM® Unica® representative.

The number of threads available to Optimize to use when reading a customer sample from the PCT. Increasing the number of threads might improve the performance of an Optimize session. For detailed instructions on tuning your Optimize implementation, contact your IBM® Unica® representative.

The number of threads available to Optimize to use when writing a customer sample to a staging table for the OCT. Increasing the number of threads might improve the performance of an Optimize session. For detailed instructions on tuning your Optimize implementation, contact your IBM® Unica® representative.

If true, Optimize attempts to use multiple threads when processing the optimization algorithms. You can configure the number of threads with the MaxCustomerSampleProcessingThreads, ProcessingThreadQueueSize, and PostProcessingThreadQueueSize configuration properties. If false, Optimize uses a single thread when processing the optimization algorithms.

If true, Optimize writes contact history transactions to a file to read during an Optimize session run. If false, Optimize reads from the UA_ContactHistory table in the Campaign system tables.

If false, Optimize creates a read lock on the UA_ContactHistory table for the length of the Optimize session. This lock might cause attempts to write to the table to fail if you are using a database load utility. If true, Optimize creates a read lock on the table only for the time it takes to write the query to a file.

This configuration property allows you to stop processing a group of customers when the rate of optimization reaches a specified level. The MinImprovmentPercent property allows you to set a rate of score improvement, measured as a percentage, to continue iterating. The default is zero, which means that there is no limit to the number of iterations possible.

If you are not using time periods in any of your optimization rules, you can prevent Optimize from querying the Contact History tables to improve performance. You can control this behavior using the UseFutureContacts configuration property.

If you set UseFutureContacts to false, and the optimization rules for your Optimize session do not use time periods, Optimize does not query the Contact History tables. This setting improves the time needed to run the Optimize session. However, if the Optimize session uses time periods, Contact History tables are queried.

If you record potential future contacts in Contact History, you must set UseFutureContacts to true. For example, if you know that you are sending an email communication next week regarding a special promotion to certain customers, those contacts might already be in the Contact History tables as placeholders. In this case, set UseFutureContacts to true and Optimize always queries the Contact History tables.