The Automation Center is a powerful tool, but since it allows you to build workflows of arbitrary complexity it is important to understand the cost of that complexity in terms of throughput. This quick referrence guide will help you estimate the throughput of your program.

Contents

See also:

Guidelines for building programs

There are two different ways we handle contacts in a program: either one by one, or in batches. Both cases have different trade-offs when it comes to performance, but the rule of thumb is that large batches are a lot faster in most cases.

The Automation Center handles contacts as follows:

  • Program with entry points New Contact or Data change handle contacts singly, unless the program was triggered by an import.
  • Programs that are triggered by an import process contacts in batches. This affects the New contact, Data change and On Auto Import entry points.
  • Program with entry points Target segment, Recurring filter or Recurring batch email handle contacts in batches.

Opt-in considerations for transactional programs

Please see our Tips & Hints page for guidelines on managing opt-ins for transactional programs.

Performance considerations for batches

In most cases batches are extremely fast. Even millions of contacts can quickly progress through the program. The only exception is when the advanced participation settings are used. These are:

  • Contacts can enter this program immediately after exiting it.
  • Contacts can enter this program again X days and Y hours after exiting it.

These settings mean that we have to keep track of each contact individually to know when they leave the program. When these settings are used, the batches will therefore have a processing speed comparable to a bunch of single user events. If performance is an issue, and you expect batches in your program, please make sure not to use the advanced participation settings.

Performance considerations for single user events

If the contacts are handled one by one you need to keep in mind that each type of node has a maximum throughput per program.

  • Most nodes allow 500 contacts/minute/program to be processed.
  • Response nodes and Action nodes such as Segment, Exclude segment, Filter switch and Quick filter allow 300 contacts/minute/program.
    Please note that this throughput might be even lower for segment nodes if the segments are very complex. Segments that contain Behavior or Smart Insight criteria may run extremely slow compared to other segments.

Examples

Simple new contact program

ac-program-example-1

If the new contact entry is triggered by an import, even a million contacts will get their emails almost instantly. On the other hand, if contacts are created one by one (for example through the API) then the throughput of this program is 500 contacts/minute.

External event with filter

ac-program-example-2

Here the filter is the bottleneck, and the program has a throughput of 300 contacts/minute, regardless of the external event.

External event with multiple filters

ac-program-example-3

Now since we have two filters, and they have to share the same computational resources, the throughput drops to 150 contacts/minute. This is the same if the filters are in sequence or in parallel.

Wait nodes

ac-program-example-4

If you set your Wait node to delay each contact for a certain number of hours, your throughput will be the standard 500 contacts/minute, and as long as the incoming contacts do not greatly exceed this, your program should perform as expected.

If you set your Wait node to hold contacts back a number of days, or wait for a specific day, you also have to define the time of day to process them. This means that your throughput will be 500 contacts/minute from that moment on.

For example, if your program collects 30,000 contacts a day, and your Wait node is set to ‘Wait one day and send at 08:00’, those 30,000 contacts will be processed at a rate of 500 per minute and it will take an hour to send all the messages.

And naturally, if your timer is followed by filters that will also affect sending speed.

Exit criteria

Including exit criteria in your program can also affect performance. If you specify a segment as an exit criterion, that will essentially insert a segment node after every entry point and every timer. So when you have exit criteria defined you should only count on 300 contacts/minute to pass through the entry nodes and timer nodes.

Pausing programs

Our recommendation is never leave a program in paused mode for more than a couple of minutes or hours at most.

The paused mode was designed so that you can safely edit your programs without causing unexpected behavior for your contacts. Although paused programs are not running, entry events are still accepted and queued. When the program is resumed, all entry events that occurred while the program was paused will be executed singly, one after the other. This can have multiple undesired effects if the program was paused for days:

  • The messages that are sent to people who entered the program days earlier may not be relevant anymore. Think of a welcome program that is paused for a month. Customers who registered during that time period will receive the welcome email several days, possibly even weeks, after they registered.
  • A lot of messages can pile up in the queue, and once the program is resumed it may be unresponsive for hours while it catches up with the queue.

Launching programs

There are a number of reasons why you may run into trouble with user permissions when trying to launch a program. In most cases, the error message will give you detailed explanation of the reason.

For example, a common cause is when an account has many different user access levels, and a program contains an email which was created by a user who does not have permission to launch campaigns themselves. In this case, check who created the emails in the program and, if necessary, copy them and use the copy instead.