The maximum number of times Contact Optimization 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 limits the effort the core algorithm spends on a customer before Contact Optimization moves to the next customer in the PCT.

If your number of customers that are optimized is greater than CustomerSampleSize, Contact Optimization divides the customers into groups of no greater than CustomerSampleSize. Contact Optimization then 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 Contact Optimization to process at a time, you can increase performance with minimal loss to optimality.

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

The maximum number of iterations Contact Optimization processes a group of customers. Contact Optimization 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 Contact Optimization 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 Contact Optimization implementation, contact your IBM® representative.

The number of threads available to Contact Optimization to use to read a customer sample from the PCT. Increasing the number of threads might improve the performance of a Contact Optimization session. For detailed instructions on tuning your Contact Optimization implementation, contact your IBM® representative.

The number of threads available to Contact Optimization to write a customer sample to a staging table for the OCT. Increasing the number of threads might improve the performance of a Contact Optimization session. For detailed instructions on tuning your Contact Optimization implementation, contact your IBM® representative.

If true, Contact Optimization 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, Contact Optimization uses a single thread when processing the optimization algorithms.

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

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

Use this configuration property to stop processing a group of customers when the rate of optimization reaches a specified level. The MinImprovmentPercent property sets a rate of score improvement, which is 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 Contact Optimization from querying the Contact History tables to improve performance. You can control this behavior with the UseFutureContacts configuration property.

If you set UseFutureContacts to false, and the optimization rules for your Contact Optimization session do not use time periods, Contact Optimization does not query the Contact History tables. This setting improves the time that is needed to run the Contact Optimization session. However, if the Contact Optimization 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 about 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 Contact Optimization always queries the Contact History tables.

If False, Contact Optimization stops the Contact Optimization session if it is not possible to process a set of customers for the following reasons:

Contact Optimization logs this condition with the following error:

If True, Contact Optimization skips all the customers in the set which triggered the generation loop error. Contact Optimization then continues processing the next customer set in the Contact Optimization session. If Optimize|logging|enableBailoutLogging property is also set to TRUE, the skipped customers are logged to unprocessables_10-digit-session-ID.csv in the partition/partition[n]/logs directory in the Contact Optimization installation directory. Customers skipped because of the generation loop error have the reason SkippedOnGenerationLoopError.

See the Contact Optimization Troubleshooting Guide for details about how to avoid the generation loop error.