Mail Service Operation

This chapter describes the configuration and operation of the PeopleSoft Online Marketing Mailcasters and Single Mailers.

This chapter includes the following sections:

See Also

PeopleSoft Enterprise CRM 9 Supplemental Installation Guide

Using the Control Center

Mailcaster States

Click to jump to parent topicUnderstanding Mailcasters

Four types of Mailcasters can be configured to work with Online Marketing:

The three types are defined by the kinds of mail jobs they are set up to handle. Each one is described in more detail in the following sections.

Click to jump to top of pageClick to jump to parent topicSmall Job Only Mailcaster

The Small Job Only Mailcaster, as its name implies, handles only small mail jobs. The actual size of a small mail job is configurable, and is controlled by the configuration parameter smallAudienceThreshold. Only those jobs containing fewer emails than this parameter specifies can be handled by a Small Job Only Mailcaster.

Typically, Small Job Only Mailcasters are used to handle test dialogs and dialogs with very small audiences.

To define a Mailcaster as Small Job Only, set the following configuration parameters:

Click to jump to top of pageClick to jump to parent topicSmall Job Priority Mailcaster

Like the Small Job Only Mailcasters, Small Job Priority Mailcasters handle small jobs; however, Small Job Priority Mailcasters will also handle large jobs if no small jobs are available for processing.

To define a Mailcaster as Small Job Priority, set the following configuration parameters:

If any small jobs exist in the queue at the time this Mailcaster becomes available, it will take these jobs first. If only large jobs exist, it will process large jobs only until another small job becomes available.

Click to jump to top of pageClick to jump to parent topicLarge Job Priority Mailcaster

Large Job Priority Mailcasters are configured to handle large mail jobs first, and to process small jobs only if no large jobs are available.

To define a Mailcaster as Large Job Priority, set the following configuration parameters:

If any large jobs exist in the queue at the time this Mailcaster becomes available, it will take these jobs first. If only small jobs exist, it will process small jobs only until another large job becomes available.

Click to jump to top of pageClick to jump to parent topicLarge Job Only Mailcaster

The Large Job Only Mailcaster handles only large mail jobs. The actual size of a large mail job is configurable, and is controlled by the configuration parameter smallAudienceThreshold. Only those jobs containing more emails than this parameter specifies can be handled by a Large Job Only Mailcaster.

Click to jump to parent topicHow the Mailcaster Works

This section describes the basic operation of the Mailcasters. It describes the mail queue, the way Mailcasters handle jobs, and job assignment priority. Also included is an example of Mailcaster operation.

Click to jump to top of pageClick to jump to parent topicThe Mail Queue

Mail jobs are placed in the mail queue by the Online Marketing Dialog Server (also called the DES). When a Mailcaster is started, it immediately checks the mail queue for jobs that match its configuration. If it finds such a job, it handles the job (either by processing the entire job or by taking a smaller piece of it to process, depending on how it is configured) and then checks back with the queue for another job. If it does not find a job that matches its configuration (for example, if it is a Small Job Only Mailcaster and the queue contains only large jobs) it will go to sleep for one minute, then wake up and check again. It will continue this process until an appropriate job becomes available.

If multiple Mailcasters have been configured, each one goes through the same process of checking the queue and taking a job that most closely matches its particular configuration. If more than one such job exists at the time a Mailcaster checks the queue, it will by default take the oldest available job (the one that has been on the queue the longest) to process.

Each time a Mailcaster finishes processing a job, it becomes available and immediately checks the queue again for a new job.

Click to jump to top of pageClick to jump to parent topicJob Types

Mailcasters handle three types of jobs:

A parent job is a mail job that is divided into smaller jobs, which are then handled by Mailcasters. Parent jobs are by definition large mail jobs (that is, jobs larger than the smallAudienceThreshold parameter).

A child job is a subset of a parent job—each parent job can have two or more child jobs, with the actual number determined by the interaction of the following factors:

Refer to Mailcaster Configuration Parameter Reference on page 17 for a description of the configuration parameters, and to How Job Size is Determined on page 4 for information on job sizes.

A small job is a mail job that contains fewer records than the value of the smallAudienceThreshold parameter. Small jobs are handled as single jobs and are not broken into child jobs.

Click to jump to top of pageClick to jump to parent topicHow Job Size is Determined

Job size refers to the size of a “chunk” of emails a given Mailcaster will accept for processing. In the case of a small job (a job containing fewer emails than specified by the smallAudienceThreshold configuration parameter), a Mailcaster takes the entire job and processes it as a single entity. In the case of larger jobs, these jobs are divided into smaller “child” jobs and processed by different Mailcasters. In this way, a Mailcaster that has finished processing a job can obtain another job from the queue and continue processing rather than being forced to remain idle until all the other jobs have finished.

The configuration parameters that govern job size are smallAudienceThreshold, minJobSize, maxJobSize, and percentageJobSize.

Mailcasters of type Small Job Only will only accept jobs where is_small_job is set to ‘y’. This is done during deduping by the DES when the job size is less than the smallAudienceThreshold used by the DES. Note that smallAudienceThreshold can be set for each Mailcaster.

For large jobs, the Mailcaster (of type Large Job Priority or of Small Job Priority if there are no small jobs in the queue) divides the job up into smaller “child” jobs using the following guidelines:

  1. First it looks at the overall job size. If the entire job fits within the range specified by minJobSize and maxJobSize, it divides the job into a single child job. For example, if the job size is 2112 emails, minJobSize is set to 2000, and maxJobSize is set to 10000, this job falls in the range of 2000–10000 and is processed as a single child job.

  2. If the job does not fit within the range specified in minJobSize and maxJobSize, the Mailcaster will look at the percentageJobSize parameter and attempt to divide the job using its value. For example, if the parent job is 100,000 records and percentageJobSize is 3, the Mailcaster will attempt to use a job size of 3000 (3% of 100,000).

  3. Next, it will look again at the minJobSize and maxJobSize parameters. If the child jobs in step 2 do not conform to these parameters, it adjusts them so they do. For example, if maxJobSize was set to 2000, it would not be possible for this Mailcaster to process a job of 3000 records. Instead, a job of 2000 records is created. Likewise, if minJobSize was set to 5000 records, then a 5000-record job would be created and processed. However, minJobSize is ignored if there are not enough emails left to send.

Click to jump to top of pageClick to jump to parent topicJob Assignment Priority

Mailcasters search the queue for jobs in priority order, based on the job’s type and its current state. Refer to Job Types on page 4 for a description of the types of jobs handled by Mailcasters, and to Mail Job States on page 6 for a description of job states.

Small Job Only Mailcasters and Small Job Priority Mailcasters look for jobs in the following order:

  1. Small mail jobs in RECOVERING state

  2. Small mail jobs in RUNNING state that are not being updated (also called “hanging” jobs)

  3. Small mail jobs in QUEUED state

    At this point if the Mailcaster is Small Job Only it can go no further, because these are the only types of mail jobs it can process. If it is a Small Job Priority Mailcaster, it continues its search:

  4. Child jobs in RECOVERING state

  5. Jobs in P_ASSIGNING state

  6. Jobs in P_QUEUED state.

Large Job Priority and Large Job Only Mailcasters look for jobs in the following order:

  1. Large jobs in RECOVERING state

  2. Large jobs in RUNNING state that are not being updated (“hanging” jobs)

  3. Jobs in P_ASSIGNING state

  4. Jobs in P_QUEUED state

  5. Small jobs in RECOVERING state (Large Job Priority Mailcasters only)

  6. Small jobs in RUNNING state that are not being updated (“hanging” jobs)(Large Job Priority Mailcasters only)

  7. Small jobs in QUEUED state. (Large Job Priority Mailcasters only)

Click to jump to top of pageClick to jump to parent topicMail Job States

This section describes the various states for mail jobs. These states appear in the Control Center.

Parent Mail Job States

The following states apply to parent mail jobs only.

State

Description

QUEUING

The parent job is waiting for processing—that is, it has not yet entered the dedup stage.

(Deduping is a process done by the DES when the mail job is first created. A mail job can be sent to multiple audiences, and a contact can likewise be in multiple audiences. Deduping is the process where it is ensured that even if a contact is in multiple audiences of a mail job, that contact receives the mail only once.)

P_QUEUED

The parent job has finished deduping, but has not been worked on by a Mailcaster.

P_ASSIGNING

The parent job is being processed, but not all child jobs have yet been created. It is in the process of assigning child jobs.

P_ASSIGNED

The parent job has finished processing. All child jobs have been assigned but they have not yet finished running.

P_FINISHED

All child jobs are finished—the job has been completed successfully.

P_FAILED

All child jobs have failed.

P_PARTIAL_FINISHED

Some child jobs are finished and some have failed.

STOPPED_R

The job was stopped while it was in RUNNING state, using the Control Center. If the job is restarted, it will be changed to RECOVERING state.

STOPPED_Q

The job was stopped while it was in a P_QUEUED state. If the job is restarted it will revert to the P_QUEUED state.

Small Mail Job States

The following state applies only to small jobs.

State

Description

QUEUED

The job has finished deduping and is waiting to be processed by a Mailcaster.

Child and Small Job States

The following states apply to child and small jobs.

State

Description

RECOVERING

A child or small job is ready for recovering. This status is used when the Administrator performs the manual recovery—the Administrator sets the job status to RECOVERING by stopping and restarting the job using the Control Center, then waits for the Mailcaster to restart the job.

RECOVERED

When a Mailcaster picks up a job in RECOVERING state and creates a new job for it, it is marked RECOVERED.

STOPPED_R

The job was stopped while it was in RUNNING state, using the Control Center. If the job is restarted, it will be changed to RECOVERING state.

STOPPED_Q

The job was stopped while it was in a QUEUED state. If the job is restarted it will revert to the QUEUED state.

STOPPING

The job is in the process of being stopped from the Control Center, but the Mailcaster has not yet finished stopping it. When the job has finished stopping it will be updated to a STOPPED_R state. STOPPING is a transient state.

INTERRUPTED

The Online Marketing Dialog Server has crashed during the dedup process and an orphaned job has been left in the database. When the scheduler next runs, it will update any such jobs to the INTERRUPTED status.

FAILED

The job has failed to complete.

FINISHED

The job has finished successfully.

RUNNING

The job is being processed by the Mailcaster.

Parent, Child, and Small Job States

The following state applies to all types of mail jobs.

State

Description

STOPPED

The small, child, or parent job has been stopped because the dialog was edited and the BulkEmailTask has been deleted. A job will also be marked STOPPED if it has no recipients.

See Mailcaster States.

Click to jump to parent topicMailcaster Recovery

When something unexpected (such as a system crash or power failure) occurs while Mailcasters are running, jobs can be left in a “hanging” state. It is necessary to recover these mail jobs and, if necessary, resend them. There are two types of recovery:

Note. Recovery applies only to small and child jobs. Note also that Small Job Only Mailcasters will not recover child jobs. This is because in order to recover a child job, the Mailcaster must process the entire job, and its job size could be greater than the Mailcaster’s maxJobSize.

Click to jump to top of pageClick to jump to parent topicAutomatic Recovery

In automatic recovery, the Mailcaster recovers a hanging job using the recover log table from the database. Depending on the time the hang occurred, it is possible that the recovering process might send out one or more duplicate emails. This is because, when using the recovery table to reconstruct the job, the Mailcaster can encounter a gap between the sending of the mail and the writing to the recovery log. This can result in the sending of at most one duplicate email per send mail thread.

To specify automatic recovery, set the automaticMailJobRecovery configuration parameter to true.

Click to jump to top of pageClick to jump to parent topicManual Recovery

In manual recovery, the Mailcaster does not try to recover the hanging job. Instead, the Administrator must manually restart the job using Control Center. To do this, stop the job and then restart it. This changes the job’s status to RECOVERING, which allows a Mailcaster to pick it up and create a new one from it. This might be desirable, for example, if Mailcasters were being run in different time zones. The new job is identical to the old one except that it has a new Job ID number and lists the original Job ID as its parent job.

To specify manual recovery, set the automaticMailJobRecovery configuration parameter to false.

See Using the Control Center.

Click to jump to top of pageClick to jump to parent topicRecovery Expiration

In some cases, you might not want a hanging mail job to be recovered. For example, if the job in question was a broadcast email announcing special sale prices good for this Saturday only, it would not make sense to recover the job if it was hanging beyond the end of the business day on Saturday. Likewise, you would not want to send a reminder to attend a seminar after the seminar is over. To handle these time sensitive situations, you can set a time period in hours after which no attempt will be made to recover the mail jobs.

To specify a recovery expiration, set the jobRecoveryExpireInHours configuration parameter to the number of hours after which you no longer want mail jobs recovered.

Click to jump to parent topicMailcaster Operation

This section contains an example Mailcaster run, illustrating some of the concepts discussed in this chapter.

Click to jump to top of pageClick to jump to parent topicMailcasters

In this example, the system uses seven Mailcasters, numbered #1 through #7.

Mailcaster diagram 1

Click to jump to top of pageClick to jump to parent topicMail Queue

For the example, the mail queue (in the PS_RY_BULK_JOB table) contains three jobs:

Click to jump to top of pageClick to jump to parent topicThe Process

All the Mailcasters have already been started. In this example, Mailcaster 1 (the Small Job Only Mailcaster) wakes up first and checks the queue for a job.

It looks at Job 101 first, but skips it because it is not a small job.

Next, it checks Job 102. At 135 emails, is_small_job is y, so Mailcaster 1 begins processing it and changes its status to RUNNING.

Mailcaster diagram 2

Next, Mailcaster 4 wakes up. It checks the queue and finds Job 101 waiting in P_QUEUED state. Because there are no large jobs in RECOVERING state, hanging, or in P_ASSIGNING state (the first three priorities for Large Job Only Mailcasters), it takes Job 101. It updates Job 101’s status from P_QUEUED to P_ASSIGNING and inserts a new job, Job 104, in the PS_RY_BULK_JOB table with status RUNNING.

Because Job 101 is larger than Mailcaster 4’s maxJobSize of 5000, it will have to be broken into child jobs. To determine the size of Job 104 (the child job), Mailcaster 4 first checks the percentJobSize parameter, which is 4. Dividing 11,000 emails into chunks of 4% each results in jobs of 440 emails. Because this value is smaller than the Mailcaster’s minJobSize of 2000, the Mailcaster instead sets the child job to 2000 emails and begins processing it.

The queue now looks like this:

Job 101 (P_ASSIGNING)

Job 103 (QUEUED)

Job 104 (RUNNING)

Job 101, which formerly had 11,000 emails, now has 9,000 remaining.

Mailcaster diagram 3

Next, Mailcasters 5, 6, and 7 wake up in order, check the queue, and in each case they find Job 101 still in P_ASSIGNING state.

Mailcaster 5 creates child job 105 with 2000 emails.

Mailcaster 6 creates child job 106 with 2000 emails.

Mailcaster 7 creates child job 107 with 2000 emails.

In each case, the jobs are set to RUNNING and the Mailcasters begin processing them.

At this point, parent job 101 has 3000 emails remaining (9000 - 6000).

Note. In all three cases, Mailcasters 5 through 7 ignored the percentageJobSize parameter because its result was smaller than the Mailcaster’s minJobSize.

Mailcaster diagram 4

Mailcaster 2 wakes up and checks the queue. Although Mailcaster 2 is a Small Job Priority Mailcaster, there are no small jobs available so it discovers Job 101 still in P_ASSIGNING state. Checking percentageJobSize, it finds that the result is smaller than its minJobSize (4% of 3000 is 120, or less than 200) so it creates Job 108 with 200 emails.

Mailcaster 3 wakes up, checks the queue, and creates Job 109 with 200 emails.

Parent Job 101 now has 2600 emails.

Mailcaster diagram 5

Mailcaster 1 finishes processing its job and marks it FINISHED. It checks the queue, but there are no small jobs available for processing. It goes to sleep, and will wake up again in 1 minute to check again.

Mailcaster 4 finishes processing its job, marks it FINISHED, and checks the queue. It finds Job 101 still in P_ASSIGNING state, so it creates Job 110 with 2000 emails, marks it RUNNING, and begins processing it.

600 emails remain in Job 101.

Mailcaster diagram 6

Mailcaster 6 wakes up and creates a new child job to process the remaining 600 emails in Parent Job 101. Job 101 is now in P_ASSIGNED state—all the jobs have been assigned, but have not yet finished processing.

All the Mailcasters processing children of Parent Job 101 finish successfully. Job 101 is marked P_FINISHED.

Mailcaster diagram 7

When the Mailcasters next check the queue, they will begin dividing up and processing Job 103. Mailcaster 1 (the Small Job Only Mailcaster) will be idle until another small job is added to the queue.

Click to jump to parent topicMailcaster Configuration Parameter Reference

The following table lists the configuration parameters that control the Online Marketing Mailcasters. Mailcaster configuration parameters are set in the MCR.config file.

smallAudienceThreshold

Defines what the DES considers to be a “small” mailjob. In conjunction with the maxJobSize parameter, defines whether a Mailcaster is Small Job Priority or Large Job Priority.

The default value is 100.

smallJobOnly

If the Mailcaster is a small Mailcaster and this parameter is set to true, the Mailcaster is defined as a Small Job Only Mailcaster and will only process small jobs. If it is set to false, the Mailcaster can process both small and large jobs. Default is false.

smallJobOnly is ignored if the maxJobSize for a Mailcaster is greater than or equal to the smallAudienceThreshold.

minJobSize

The minimum size for a child mailjob. This value must be smaller than maxJobSize.

The default value is 2000.

maxJobSize

The maximum size for a child mailjob. This value must be larger than minJobSize. In conjunction with the smallAudienceThreshold parameter, defines whether a Mailcaster is Small Job Priority or Large Job Priority.

The default value is 10000.

percentageJobSize

The percentage of a large job to use as a child job size. This value must be greater than 0; the default is 3.

Note that if the calculated percentage is smaller than minJobSize or larger than maxJobSize, these values are used instead of percentageJobSize.

Note also that when percentageJobSize is used to divide up a large job into equally-sized child jobs, any records remaining are included in their own (smaller) child job.

recoveryStringUpdateFrequency

Defines the number of emails that are sent before the Mailcaster updates the database tables with information about the job. Setting this parameter to a low number results in more accurate reports in the Control Center but can slow down performance; setting it high increases performance but Control Center reports will be less up-to-date.

The default value is 100.

automaticMailJobRecovery

When a Mailcaster detects a hanging running job (that is, a job with status Running that has not been updated in the last two hours), this parameter is used to determine if the Mailcaster will try to recover it.

If the parameter is set to false, the Mailcaster will not try to recover the job and the Administrator must manually recover it. If it is set to true, the Mailcaster recovers the job automatically. In some cases this can result in the sending of duplicate emails. Default is true.

jobRecoveryExpireInHours

The time period, in hours, after which mail jobs will not be recovered. This parameter is commonly used when dealing with time sensitive audiences or mailings containing time sensitive information.

The value must be greater than 0, and the default value is 96.

Click to jump to parent topicUnderstanding the Single Mailer

Single mails to be sent are placed on the single mail queue. If the mails are to be sent immediately, they will have a status of Queued. If they have been scheduled to be sent in the future then they will have a status of Scheduled. The single mailers update the email status from Scheduled to Queued when the appropriate time is reached.

When a single mailer starts to send mail, it reserves a batch of emails for it to send. It then sends those emails sequentially. If problems occur during the rendering or sending of the email then the single mail is updated with the appropriate error code and description. This allows the administrator to fix the underlying problem. They can then resubmit the failed mails for delivery using the Control Center.

A single mailer can recover mail reserved by another single mailer but not sent. After a configurable time period mails that have been reserved by a single mailer and not sent will be updated so that they are no longer reserved by that process. They can then be sent by any running single mailer.

The following table displays a list of single mailer states:

State

Description

Scheduled

The mail is scheduled to be sent in the future.

Queued

The mail is queued to be sent.

Sending

The mail is in the process of being sent.

Failed

The single mailer attempted to send the mail but it failed in rendering or in delivery.

Paused

The mail has been paused due to a change in dialog state.

Stopped

The mail has been stopped due to a change in dialog state or dialog editing.

The following table displays a list of single mailer error codes:

Error Code

Description

Bad Email Address

The recipient's email was rejected by the mail server.

Persistence Exception

There was an error with the database when loading the email.

Failed to Load Campaign or Document

There was a problem with the metadata of the document or the dialog.

VCRenderingException

There was a problem in rendering the email.

FailSingleEmail

There was a problem in rendering the email in a custom function.

IOException

There was a problem sending the email.

TagFormatException

There was a problem with the document when rendering the email.

SenderNotAccepted

The sender's address was not accepted by the mail server.

See Also

Administering the Single Email Queue

Administering Single Email Failure and Recovery

Click to jump to parent topicUnderstanding Email Frequency Management

When sending email as part of an online dialog, a marketer might want to keep track of how many emails have been sent to a given person during a given time period, to avoid annoying recipients with too many emails in too short a time. Email frequency management lets you set thresholds for number of emails allowed to be sent in a specified time period. Counters keep track of how many emails have been sent to each recipient, and when the threshold for a recipient is reached the system queues up the remaining emails and holds them until time has passed and the previously sent emails age out of the counters.

For example, suppose you have specified that recipients should receive no more than 3 emails in 7 days, and that the 7 days begins on May 20. If, on May 20, 5 emails are intended for a recipient, 3 of these will be sent (and that person's counter will be incremented for each email) and the other 2 will be queued and sent on May 28 (after 7 days the first emails will have aged out of the counters). That person can then receive one more email between May 28 and June 4 (the next 7-day period).

Email frequency management also includes a Process Scheduler batch job that runs on a schedule to decrement the counters as sent emails “age out” of the delivery window. You can specify that if an email ages beyond a certain point (for example, if the email announces a seminar and the date of the seminar has passed by the time the recipient can receive more emails), the email is removed from the queue and logged as not delivered.

Click to jump to parent topicManaging Email Frequency

Online Marketing manages email frequency using an Email Frequency Policy. This policy includes policy rules, which specify the number of emails that can be sent to a recipient in a specified time period. Each email frequency policy can contain four policy rules. This section describes the functionality of the email frequency policy, the policy rules, and the email frequency queue.

Click to jump to top of pageClick to jump to parent topicEmail Frequency Policy

You define the email frequency policy on the Global Options page.

When it is enabled, the global frequency policy governs all emails that Online Marketing sends, for all online dialogs. It specifies the defaults for whether the counter should be incremented with each email, the maximum number of days that emails should remain in the queue before being removed (“shelf life”), and how the queue should behave.

Once it has been enabled, disabling the global frequency policy results in the loss of all prior logging of email. No historical data is retained. Further, it also results in the immediate sending of all the waiting emails that are currently in the email frequency queue. If you do not want this to occur, you must delete all messages from the queue using the Control Center's Email Frequency Queue page.

You can override the global frequency policy on the Broadcast Email and Single Email pages in the dialog flow—in this case, the system will use the settings you specify for that email only, but the global policy will continue to be in effect for all other emails.

See Setting Global Options.

See Using the Control Center.

See Designing Online Dialogs.

Click to jump to top of pageClick to jump to parent topicFrequency Policy Rules

Each contact has four aggregated counters to keep track of how many emails the contact has been sent. These counters correspond to four counter rules, which consist of a maximum email count and a time duration. For example, you might specify a one-day count, a seven-day count, a 30-day count, and a 90-day count. You can set each rule independently to Active or Inactive; only the counters corresponding to rules that are in the Active state will be updated.

Rolling counter policy rules are used to “age out” messages that are reflected in counters. Each time an email is sent, the recipient's counter is incremented. Each night, a batch job runs to decrement the rule counters for those messages that are older than the rule calendar window. When these counters have been decremented, any emails that are queued can be sent (provided that they comply with any other rules set for that recipient).

By default, four global calendar counter rules are included: 1 day, 7 days, 30 days, and 90 days. You can change these rules globally, or you can change them by individual email.

Note. The system enforces consistency between the rules so that they do not contradict each other: for example, you cannot specify one rule as 1 email per 7 days and another rule as 10 emails per 30 days. The 7-day rule would prevent the 30-day rule from being enforced.

Counters and Counter Calculation

Database tables keep track of the daily email count for a contact. The maximum number of days allowed in defining a policy rule is 365.

To calculate the count, a Process Scheduler batch job runs at a specified time to reset the daily email count log. It reads from the daily count log and produces the aggregated count, according to the active rules. (For example, if a rule's counter is 7 days, the batch job determines the current day and selects the past 7 days' logs (including the current day) .

Click to jump to top of pageClick to jump to parent topicEmail Frequency Queue

When emails cannot be sent to a recipient because he or she has already received the maximum allowable emails for that time period, the remaining emails are placed on the email frequency queue, where they remain until one of four things happens:

You can specify (on the global or individual email level) whether the email should be queued if it cannot be sent—if you choose the Do Not Queue option, emails that cannot be sent because they violate the frequency policy will simply be discarded.

You can also specify whether or not to count an email task with the frequency counter. If you specify Do Not Count, the mail service does not increment the frequency counter for that email. Like Do Not Queue, you can specify Do Not Count at the global or individual level.

If you have specified that emails should be queued and that the frequency counter is active, then each time a contact's frequency counter is decremented, the system scans the email queue to see if there are any pending emails for that recipient. Any emails that can be sent (according to the policy) are sent until the recipient's counter once again reaches the maximum allowed by the policy rules.

Expiration of Queued Emails

Every email that is queued because of the frequency counter has an expiration date. This is the date after which the content expires, so that even if it “ages out” of the count and should be allowed to send, it will be removed from the queue and not sent. You can specify the expiration date as an actual date or as a “shelf life” — a time period from the queuing date (for example, 7 days from the date the email is added to the queue).

Note. If an email from a repeating trigger is to be queued, and an email from an earlier sequence exists, the new email will not be added to the queue; instead, it will immediately expire.

Single Email Notifications

Single emails sent to specific addresses (for example, email notifications) are excluded from the frequency policy: they are sent immediately, are not counted toward the user's total for the purpose of incrementing the frequency counters, and are not queued.

Overriding the Frequency Policy

You can choose to override the frequency policy for an email task, opting to ignore the frequency policy rules and send any emails immediately. These emails are still logged, and the frequency counter is still incremented. When you run Dialog Check, you will get a notice that these emails are overriding the frequency policy.

Managing the Email Frequency Queue

You manage the email frequency queue using the Online Marketing Control Center, using the Email Frequency Queue Report page. From there, you can update the queue, delete all queued emails, and attempt to recover failed emails,

See Administering the Frequency Emailer Queue.

Testing Dialogs with Frequency Policies

When a dialog is placed in the Test state, all of its email tasks are created with Override Frequency Policy and Do Not Count selected. This means that staged emails will always be sent, and they will not affect the Live dialog execution. It also means that you will not need to remove queued emails when testing dialogs.