Interaction Management Guide

Campaigns

Campaigns are powerful tools for personalization, letting you target users with specific Web content, e-mails, and discounts based on specific conditions and fine-grained rules.

The following topics guide you through the campaign creation process:

Overview of Campaigns

Campaigns let you provide the following for individual users:

Personalized Web content - When you use a campaign to display personalized content, the content (such as an image) is retrieved from BEA's Virtual Content Repository through a query and displayed in a placeholder on a JSP, whether the JSP is in a portlet or in a desktop header region.
Predefined e-mails sent automatically - The campaign service reads user profile properties to obtain a user's e-mail address, then sends a predefined e-mail to that user.
Personalized discounts in a commerce application - If you have built a commerce application with the necessary catalog and shopping cart functionality, you can provide a variety of discount types to specific users.

Campaigns are extremely flexible, because they let you create business logic without requiring code changes. For example, campaigns show Web content using a JSP tag called a placeholder that looks like this: <ph:placeholder name="myPlaceholder1"/>. Add JSP placeholder tags (uniquely identified by the "name" attribute) anywhere you want in your portal's JSPs. Then simply define your campaigns to use the existing placeholders, each of which can display content unique to the campaign and to the individual users. Campaigns can change and be added, but you never have to change your JSP code. The placeholders you need stay the same.

In addition to providing this high level of flexibility and personalization, campaigns, as the name implies, begin at a specific time and end when their purpose has been fulfilled, whether specific goals have been achieved or a time deadline has been reached. Campaigns can even be set up to run only once for each visitor.

Structurally, a campaign contains one or more scenarios, and each scenario contains one or more actions that show personalized content, send an automatic e-mail, and/or provide a personalized discount. The advantage of scenarios as containers for actions is that you can use user segments to determine which users are eligible to be targeted with the actions in a scenario (though you are not required to assign user segments to scenarios). For example, you could create a campaign with two scenarios: One that will target its actions only to males and the other that will target its actions only to females. The logic would work like this in a scenario for females:

Are you a member of the "female" user segment?

Yes. Your user profile says you are. If this campaign is triggered, you will be targeted with any of the actions in this scenario that apply to you.
No. Your user profile says you are a male. If this campaign is triggered, you will not be targeted with any of the actions in this scenario.

Campaign Examples

The following scenarios provide examples of the versatility and power provided by campaigns:

A company provides open benefits enrollment for its employees, where employees can change their current benefits choices. In the internal human resources portal, the company creates a campaign that runs from November 1 to 30, during which time the campaign displays an Open Enrollment graphic in the portal header region and, when employees make changes to their benefits and click Submit, they are automatically sent a confirmation e-mail.
A large online retailer is running a holiday special for its external customers. The retailer creates a campaign that provides a one-time discount of 30% off the cost of books when the total cost of books in any order is $100 or more.
A mobile devices ISP creates a campaign that shows targeted add-on services that are specific to each type of mobile device when users click the "New Stuff!" link.

Campaigns and behavior tracking are not currently supported for anonymous, non-trackable users. See "Anonymous Users" in the User Management Guide at http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/users/anonymous.html.

How Campaigns are Triggered

Campaign scenario rules are evaluated only when a single event occurs for which the campaign service is listening.

Note: By default, the only events that do not trigger campaigns are DisplayContentEvent, DisplayProductEvent, BuyEvent, SessionBeginEvent, and SessionEndEvent, as listed in <PortalApplication>/wps.jar/com/bea/campaign/internal/listeners.properties.)

If your campaign conditions use request, session, or event properties, those properties are captured when a listened-for event is triggered. The event takes a snapshot of the current session properties, the single request property (contained in the session), and the event properties (contained in the request). The snapshot taken by the event is in the form of a request object, which the event passes to the campaign service for evaluation. If the values in that snapshot evaluate to true against any campaign action rules, those campaign actions are triggered.

When campaign actions are not triggered as expected using session, request, and event properties, one or more of the following is usually to blame:

No event was fired that the campaign service was listening for.
The session, request, or event properties contained in the campaign rule were not part of the Request object snapshot taken when the event was fired.
In campaign rules that are defined so that all conditions must apply for the campaign action to be triggered, one or more of the conditions evaluated to false.

Consider the following Campaign action rules as created in WebLogic Workshop:

When all of these conditions apply:
an HTTP request has the following properties:
RequestPropertyOne is equal to "success"
any of the following events has occurred:
SessionLoginEvent
Do the following [content action, e-mail action, or discount action].

The rule will be evaluated only if an event for which the campaign service is listening occurs. (This event need not be used directly in the campaign rule.) For example, if the campaign service is configured to listen for the BEA-provided UserRegistrationEvent (which it is by default), then when a UserRegistrationEvent occurs the event takes a snapshot of the Request object and the Campaign rules are evaluated.

Here is how the previous Campaign action rules would be evaluated:

Is there a request property called RequestPropertyOne with a value of "success"?
Am I a SessionLoginEvent?
Are all of these conditions true?

Because a UserRegistrationEvent woke up the campaign service and took a snapshot of the request object, the campaign action will not be triggered, because the rule requires that all of its conditions evaluate to true. The SessionLoginEvent rule is false (because it was the UserRegistrationEvent that woke up the campaign service).

If the rule was defined differently so that any of the conditions evaluating to true would trigger the action (rather than all conditions), the campaign action would have fired if the request property evaluated to true.

Note: If you are using e-mails in your Campaign, you can choose to send the e-mails in batch mode or real-time (batch mode is the default). In batch mode, when you run or test your Campaign, no e-mails will be sent. See Setting Up Bulk E-Mail Messages to learn how to send batch mode emails. See Creating Campaigns for instructions on how to change the mailing behavior to real-time.

Preparing to Use Campaigns

Before you create campaigns, ensure that you have performed the following appropriate steps.

Note: Campaigns and behavior tracking are not currently supported for anonymous, non-trackable users. See "Anonymous Users" in the BEA WebLogic User Management Guide at http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/users/anonymous.html.

1. Create a Portal Application

See Creating a Portal Application and Portal Web Project in the WebLogic Workshop help system.

2. Set up Content

When you show personalized content with a campaign (using a content rule), the content is retrieved from BEA's Virtual Content Repository and displayed in a placeholder. There are many properties you can add to your content that enable necessary and helpful features for campaigns. For example, to increase the chances of a specific content item being shown in a placeholder, create an adWeight property (as an Integer) for your content items. The greater the adWeight number you enter for a content item, the greater the chances that it will be displayed in a placeholder if it is retrieved by a query.

For more information on setting up content for use in interaction management, see Setting up Content in this guide.

For instructions on using content management in WebLogic Portal, choose from the list of Content Management topics on the e-docs home page at http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/index.html.

Goal Setting Performance

If you are using Goal Setting in campaigns to end a campaign based on the number of content items displayed and/or clicked:

You can determine how frequently the campaign service checks to see if goals have been met. In the WebLogic Administration Portal, select Service Administration, select Campaign Service in the resource tree, and set the Goal Check Time to the frequency you want. The default is 300000 milliseconds (5 minutes). Less-frequent goal checks improve performance, but the campaign service is slower to find out whether goals have been met. For testing, set the value to 0 so that there are no delays in checking for goals.
You can determine how many impressions/clickthroughs occur before that number is written to the database. In the database, the campaign service compares the current count to the impressions/clickthroughs goal you set in the campaign. In the WebLogic Administration Portal, select Service Administration, select Ad Service in the resource tree, and set the Display Flush Size to the number you want. The default is 10. A larger flush size improves performance, but the campaign service is slower to find out whether goals have been met. For testing, set flush size to a small number to ensure campaigns end right when your goals have been met.

You must restart the server for this change to take effect.

3. Create Placeholders

Campaigns use placeholders to display personalized Web content. If you will display personalized content through campaigns, create the placeholders that will hold your campaign queries and display the Web content.

For more information on placeholders, see Placeholders in this guide. In particular, see the section on "Combining Default Queries and Campaign Queries in Placeholders."

4. Create User Segments

If you want to trigger campaign scenarios based on users who are grouped dynamically based on specific characteristics, create user segments. For more information on user segments, see the Interaction Management Overview in this guide and "Creating User Segments" in the WebLogic Workshop help system at http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/portal/buildportals/CreatingSegments.html.

5. Create Property Sets

If you will trigger campaigns based on user, event, HTTP session, or HTTP request properties, perform any of the following relevant procedures found in the WebLogic Workshop help system:

For more information on how these properties are used in interaction management, see the Interaction Management Overview in this guide.

6. Set up E-Mail Messages

If you will send automatic e-mails in campaigns, make sure you have done the following:

Define an e-mail address property - Create a property in a user profile property set that will store the user e-mail address. For example, the default CustomerProperties.usr property set contains an Email property that can contain a single, unrestricted String value for an e-mail address.

Set up the Campaign Service - You must tell the campaign service where to get the e-mail address for sending automatic e-mails to users. In the WebLogic Administration Portal, choose Service Administration --> Campaign Service. Enter the property set name and the name of the e-mail property you set up in the previous step.

You can also tell the campaign service to send automatic e-mails only if users have specified that they want to receive them. To achieve this, define a user profile property with the single, restricted values of true and false. Then, in the Campaign Service configuration, use the Opt In fields to enter the property set and name of the property containing that preference. E-mails will not be sent to users who have their property value set to false.

Set SMTP for outgoing mail - In the WebLogic Administration Portal Server Administration tools, choose Service Administration --> Mail Service. In the SMTP Host Name field, set the host name for your e-mail server's outgoing mail.

Create e-mail messages - Create your predefined e-mail messages. E-mail messages can be in any of the following formats: TXT, HTML, JSP, or XML (with style sheets). Store them in the following location: <PortalWebProject>/campaigns/emails. If you want to use a different directory for storing e-mail files, follow the instructions in the next step.

If you are using e-mails in your campaign, you can choose to send the e-mails in batch mode or real-time (batch mode is the default). In batch mode, when you run or test your campaign, e-mails are not sent. See Setting Up Bulk E-Mail Messages to learn how to change the mailing behavior to real-time

Set e-mail security - Use the following information to prevent unauthorized access to e-mail messages:

When a campaign sends an automatic e-mail, it uses a predefined e-mail message stored on the file system within your portal Web project. By default, WebLogic Portal prevents unauthorized access to those e-mail files when the files are stored in <PortalWebProject>/campaigns/emails. Use the following information if you need to change the default e-mail security configuration.
Email files are secured by the following deployment descriptors:

<PortalApplication>/wps.jar/META-INF/weblogic-ejb-jar.xml - The following line in this file provides the name of a user who is in the global PortalSystemAdministrator role:

<run-as-principal-name> portaladmin </run-as-principal-name>

Membership in the global PortalSystemAdministrator security role is defined in the WebLogic Server Administration Console at the server level. In a portal domain created with the Configuration Wizard, the groups "Administrators" and "PortalSystemAdministrators" that are provided by default are configured to be members of the global PortalSystemAdministrator role. Because the user "portaladmin" (also provided by default in a portal domain) is a member of the portal "Administrators" and "PortalSystemAdministrators" groups, "portaladmin" is a member of the global PortalSystemAdministrator role.
If you need to use a different user for e-mail security: 1) Back up wps.jar; 2) Un-jar wps.jar and change the name of the user in weblogic-ejb-jar.xml; 3) Make sure the user exists; 4) Make sure the user is a member of the global PortalSystemAdministrator security role; and 5) Re-jar and replace the old wps.jar and redeploy the application. If you enter the name of a user in <run-as-principal-name> that does not exist, or if you delete the "portaladmin" user without changing the <run-as-principal-name> entry, you will receive deployment errors on wps.jar.

<PortalWebProject>/WEB-INF/web.xml - The following line in this file secures the e-mail files in <PortalWebProject>/campaigns/emails, allowing only the campaign service (through the PortalSystemAdministrator user defined in the previous section) to access and send the e-mails:

<url-pattern>/campaigns/emails/*</url-pattern>

If you need to use a different directory for storing e-mail files: 1) Change the <url-pattern> path in web.xml to ensure the files in the new directory are secured. 2) In the WebLogic Administration Portal, choose Service Administration > Campaign Service, and change the directory in the Base Directory for Email Browsing field. 3) Redeploy the application.

Note: Using a wildcard character (*) in the URL pattern does not provide recursive directory protection. The wildcard protects only the files in the last directory listed. For example, if you want to store e-mail files in /campaigns/emails/q1, the url-pattern /campaigns/emails/* does not protect the e-mail files in the /q1 directory. To protect those e-mail files, the url-pattern must be /campaigns/emails/q1/*.

After making changes to the Campaign Service settings in the WebLogic Administration Portal, redeploy the application (or restart the server during development in WebLogic Workshop) to apply your changes.

Setting Up Bulk E-Mail Messages

You must use a command to periodically send the batch e-mails that the JSPs store in the WebLogic Portal data repository. You can also use cron or any other scheduler that your operating system supports to issue the send-mail command.

For Windows, the send-mail command is located in a .bat file wrapper script. For UNIX, the send-mail command is located in a .sh file. The following sections refer to the .bat file. UNIX users should substitute .sh for .bat.

Note: When you send campaign e-mails, the default is set to true to use a batch mode operation. Batch mode requires you to run the mailmanager.bat file from the <root>/weblogic81/portal/bin directory to send the e-mails through the SMTP server. For WebLogic Workshop 8.1.x, you can request a patch to modify the batch flag to change it to false to send the campaign e-mails in real-time.

This section contains the following topics:

The send-mail wrapper script specifies the name and listen port of the WebLogic Portal host that processes the send-mail request. By default, the wrapper script specifies localhost:7501 for the hostname and listen port. However, localhost:7501 is valid only when you run the script while logged in to a WebLogic Portal host in a single-node environment (and only if you did not modify the default listen port). If you use the send-mail script from any other configuration, you must modify the script.

Modifying the Send-Mail Script to Work from a Remote Host

Perform the following steps to run the send-mail script from a remote host (a computer that is not a WebLogic Portal host):

Open the following file in a text editor:

PORTAL_HOME\bin\mailmanager.bat (Windows) or PORTAL_HOME/bin/mailmanager.sh (UNIX)

In the mailmanager script, locate the SET HOST= line. Replace localhost with the name of a WebLogic Portal host.

If the host uses a listen port other than 7501, replace 7501 in the SET PORT= line with the correct listen port.

Save the mailmanager script.

Modifying the Send-Mail Script to Work in a Clustered Environment

If you work in a clustered environment, you must modify the send-mail wrapper script to specify the name of a host in the cluster. The default localhost value is not valid for the Mail Service in a clustered environment.

Note: The following steps must be performed on each host that will run the script.

Perform the following steps on each host to use the send-mail script in a clustered environment:

Open the following file in a text editor:

PORTAL_HOME\bin\mailmanager.bat (Windows) or PORTAL_HOME/bin/mailmanager.sh (UNIX)

In the mailmanager script, replace localhost in the SET HOST= line with the name of a WebLogic Portal host. Because each host in a cluster can access the data repository that stores the e-mail messages, you can specify the name of any host in the cluster.

If the host uses a listen port other than 7501, replace 7501 in the SET PORT= line with the correct listen port.

Save the mailmanager script.

Using the Mailmanager Commands

The mailmanager command is a wrapper script that uses the jav.com.bea.p13n.mail. MailManager class.

Use the following command syntax:

mailmanager.bat [ appName ] [ list | send | send-delete | delete ] batch-name ] (mailmanager.sh on UNIX)

If you specify only the appName arguments, the mailmanager command prints to standard output the names all e-mail batches in the application and the number of e-mails in each batch.

Table 5-1 contains a list of the command arguments.

Table 5-1 Mailmanager Command Arguments

Command Argument	Description
appName	The name of the enterprise application that generated the e-mail batch.
list	Prints to standard output the names of all e-mail batches in the data repository and the number of e-mails in each batch.
`list` batch-name	Prints to standard output the subject and recipients of all e-mails in the batch that you specify.
`send` batch-name	Sends all e-mails in the batch that you specify.
`send-delete` batch-name	Sends all e-mails in the batch that you specify and then deletes the batch from the data repository.
`delete` batch-name	Deletes e-mails in the batch that you specify.
batch-name	The name of a batch that `mailmanager list` returns. This argument does not support wildcards.

Table 5-2 contains examples of mailmanager commands.

Table 5-2 Examples of Mailmanager Commands

Command Example	Description
`mailmanager.bat list` batch-name	Lists all available batches
`mailmanager.bat wlcsApp list /campaigns/campaign1.cam`	Lists the contents of a batch named `/campaigns/campaign1.cam` that the wlcsApp application generated
`mailmanager.bat wlcsApp send-delete /campaigns/campaign1.cam`	Sends the `campaign1.cam` batch and deletes it afterwards
`mailmanager.bat wlcsApp delete /campaigns/campaign1.cam`	Deletes the `campaign1.cam` batch

Sending Bulk E-Mail

Perform the following steps to send bulk e-mail from a shell that is logged into a WebLogic Portal host:

Start the WebLogic Server.

To determine the names and contents of the e-mail batches in the data repository, enter the following command:

mailmanager.bat appName list (Windows)

The appName is the name of the enterprise application that generated the e-mail batch. The command prints to standard output. You can use shell commands to direct the output to files.

To send a batch and remove it from the data repository, enter the following command:

mailmanager.bat appName send-delete batch-name

Note: If you are using e-mails in your campaign, you can choose to send the e-mails in batch mode or real-time (batch mode is the default). In batch mode, when you run or test your campaign, no e-mails will be sent. See Setting Up Bulk E-Mail Messages to learn how to send batch mode emails and how to change the mailing behavior to real-time.

Scheduling Bulk E-Mail Delivery

You can use a scheduling utility to send the e-mail batches in the data repository. You must specify the name of a batch when you use the mailmanager command to send mail, so you must schedule sending mail for each campaign scenario separately. The name of a batch corresponds to the scenario's containerId. The containerId specifies the ID of the campaign to which the scenario belongs.

For information in using a scheduling utility, refer to your operating system's documentation.

Deleting E-Mail Batches

You can delete e-mail batches after you send them (see Sending Bulk E-Mail).

You can also perform the following steps to delete e-mail batches:

To determine the names and contents of the e-mail batches in the data repository, enter the following command:

mailmanager.bat appName list

The appName is the name of the enterprise application that generated the e-mail batch. The command prints to standard output. You can use shell commands to direct the output to files.

To delete a batch, enter the following command:

mailmanager.bat appName delete batch-name

7. Set up Commerce for Discounts

If you are going to create discount campaign actions, perform the following steps. For details on these steps, see "Building a Commerce Application" in the WebLogic Workshop help system at http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/portal/buildportals/navCommerce.html.

Add commerce services to your portal application.
Set up a shopping cart using the WebLogic Portal commerce API.
Create a catalog in the Virtual Content Repository.
Use the WebLogic Portal catalog classes in the commerce API to surface catalog items from the Virtual Content Repository and identify them with "categories" and "sku" numbers.
Create discounts and use the commerce API to surface the discounts in your shopping cart. If desired, use the API to surface the discount's description next to the discount amount displayed in the shopping cart.

8. Trigger the Campaign

You must use a Regular or Behavior Tracking event to begin your campaign or trigger a campaign action based on events and their values. A commonly used event is SessionLoginEvent.

See Using Events in Campaigns and Registering Events for Campaigns for instructions. See also How Campaigns are Triggered.

Creating Campaigns

For instructions on using all the previously mentioned pieces to create a campaign in WebLogic Workshop, see "Creating Campaigns" in the WebLogic Workshop help system at http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/portal/buildportals/createCampaigns.html.

Use the following guidelines for creating campaigns:

To use session or request properties to trigger campaign actions, make sure you do the following:

In the JSP containing the event to be fired, get the request attribute through a variable or set it directly in the JSP.
In the JSP containing the event to be fired, get/set any event properties you want to use.
If you want to use session properties to trigger campaign actions, make sure the firing event is in the same session containing the session properties you want to use.

Note: When you send Campaign emails, the default is set to true to use a batch mode operation. Batch mode requires you to run the mailmanager.bat file from the <root>/weblogic81/portal/bin directory to send the e-mails through the SMTP server. For WebLogic Workshop 8.1.x, you can request a patch to modify the batch flag to change it to false to send the Campaign e-mails in real-time.

Resetting Campaigns

You can reset different aspects of your campaigns. For example, you may want to do one or all of the following:

Clear content from a placeholder that had been previously put in the placeholder so that the users who were supposed to see personalized content one time see it only one time.
Clear from the database the number of times an image has been viewed or clicked so that your campaign does not reach its goals.
Give users a second chance on "run once" campaign actions that they have already triggered.
Clear any e-mail messages waiting to be sent.

You can reset campaigns either in the development environment (for testing) or in the production environment.

Resetting a Campaign in the Development Environment

With a campaign file open, choose Portal --> Reset Campaign. The Reset Campaign dialog box appears, as shown in Figure 5-1.

For details on using this feature for testing, see Testing Campaigns in this chapter.

Figure 5-1 Resetting a campaign in the development environment

Resetting a campaign in the development environment

Resetting a Campaign in the Production Environment

To reset a campaign in the production environment, select the campaign in the WebLogic Administration Portal and click the Reset Campaign button. The Reset dialog box appears, as shown in Figure 5-2.

Figure 5-2 Resetting a campaign in a production environment

Resetting a campaign in a production environment

Testing Campaigns

Use the following guidelines for testing campaigns in your development environment on your development server:

Make sure the campaign is complete. The entire campaign, each scenario, and each action have specific conditions for completeness. When you select each, the "Is Complete" property in the Property Editor window displays a read-only value of "true" or "false". If "Is Complete" is false for any part of a campaign, select the property in the Property Editor window and read the Description to find out which properties are required for completeness.
Make sure the campaign is active. With the campaign selected (not a scenario or action), make sure the Active property in the Property Editor window is set to "true".
Just below the Campaign Designer window, if you see the text "Campaign is currently stopped", you must change the Start Date and/or Stop Date properties so that the current date falls between the two. Once the current date is within the campaign date range, the "Campaign is currently stopped" text disappears.
If your campaign uses Goal Setting to end a campaign based on content impressions or clickthroughs, modify the following Service Administration settings in the WebLogic Administration Portal:

Select Campaign Service, and set the Goal Check Time to 0. This creates no time delay in the amount of time the campaign service checks to see if goals have been met.

Select Ad Service, and set the Display Flush Size to 1. This writes each impression or clickthrough to the database each time it occurs and ends the campaign on the exact number of impression/clickthrough counts you have established. If, for example, you wanted to end a campaign on 5 impressions, but your Display Flush Size was set to 10, you would need to see 10 impressions before the that number is written to the database, at which point the campaign service would see that the 5 impressions had already been met, effectively ending the campaign after 10 impressions rather than 5.

You must restart the server for this change to take effect.

Note: Do not deploy your application into production with these settings. Performance would be adversely affected.

You can reset many aspects of campaigns during testing, such as impression and clickthrough counts that can end a campaign and scenarios that run only once for each user. With a campaign file open in WebLogic Workshop, choose Portal --> Reset Campaign and reset any aspects of the campaign.
Testing "run once" content actions - Follow this procedure to test content actions that you want to run only once per user:

With the campaign open in WebLogic Workshop, choose Portal --> Reset Campaign.

In the Reset Campaign dialog box, select "Reset all options" and click OK.

View the portal and run the content action by kicking off an event that the campaign service is listening for (such as logging in). Make sure the campaign content is displayed.

Log out or click the browser's Back button to return to the place where you can launch the event again.

Go back to the campaign in WebLogic Workshop and choose Portal --> Reset Campaign, and reset the "Remove previously placed content from rotation" option.

Go back to the portal and kick off the event again. The campaign content should not appear again.

Other placeholder issues - To troubleshoot campaign content in placeholders, make sure you understand how placeholders handle default and campaign queries. For example, default and campaign queries have priorities that help determine which query runs. Also, you can set default queries so that they do not run when campaign queries are present. For more information, see Placeholders in this guide.
Managing content caches (performance testing) - From WebLogic Workshop, you can disable, enable, and flush caches that are used for Web content. With a campaign open in WebLogic Workshop, the Portal menu provides those cache options. The following caches are affected (which you can view in the WebLogic Administration Portal by selecting Service Administration and expanding the Cache Manager).

adBucketServiceCache - (Reserved for future use.)
searchCache - Caches the results of content searches for the virtual content repository.
documentMetadataCache - Caches the results of document searches for the DocumentManager. It is not used by the content repositories.
binaryCache.BEA Repository - Caches binary property values for the BEA Repository.
documentContentCache - Caches the document bytes for the DocumentManager. It is not used by the content repositories.
nodeCache.BEA Repository - Caches Nodes for the BEA Repository.
documentIdCache - Caches the results of document searches (ids only) for the DocumentManager. It is not used by the content repositories.
adServiceCache - Used by the ad service to cache the results of searches for content rendering.

Note: For optimal performance, be sure to enable these caches in your production environment.

Optimizing Campaign Performance

See Tuning for Campaigns in the Performance Tuning Guide.