Üzgünüz, bu sayfa henüz tercüme edilmemiş bulunuyor. Emarsys ekibimizin tüm dökümanlarımızı sizin dilinizde sunmak için yoğun çalıştığından emin olmanızı isteriz.
The Automation Center is a powerful tool that lets you build programs of varied complexity. Here we have listed a number of suggestions as to how you can get the most out of it, as well as explaining some of the more complex functionality.
- Using attachments
- Send Time Optimization
- Opt-in for transactional emails
- Performance guidelines
- Program reporting
- Timezone management
- Pausing programs
- Launching programs
The use of attachments in emails is not supported by the Automation Center. However, since they are supported by Triggered Email, you can send the attachment using that feature and then use the same external event to add the contact to a program to follow it up.
Send Time Optimization
The Send Time Optimization feature in the Automation Center is currently in pilot phase. If you are interested in participating, please apply using our Pilot Sign-up form.
When STO is enabled for an email node, the incoming contacts are treated in the same way that STO treats ad hoc campaigns:
- A random control group of 10% is created and the launch times for the rest of the launch list are calculated.
- On the next even hour after calculation, the email is sent to the control group and the first STO launch group.
- The campaign is sent to the rest of the STO launch groups every two hours, over the next 24 hours.
The main difference in behavior is that all contacts are queued at the email node until the final launch has been sent, at which time they are all free to progress along the program once again.
The feature will only work for batch emails. If you enable it for transactional email it will simply be ignored (this behavior is a known issue for the pilot phase).
If you are interested in participating in this pilot project, please sign up for it using our Pilot Features Sign-up Form.
We are monitoring the effect that large numbers of STO launches on the same environment have on email sending. Until we are absolutely certain that there is no risk of performance loss, we will be limiting the total number of launches that can use STO at any given time. If this happens, you will receive a message in email node and in the Notification Center.
Opt-in for transactional emails
As a rule, all emails sent via the Automation Center will respect the opt-in status of the recipient. However, an exception has been made for the following entry points:
- Abandoned shopping cart
- External event
If you create a program that starts with one of these entry points, and follow the entry point immediately with an email node, the first email will be sent to all participating contacts regardless of their opt-in status (i.e. opt-in can be empty or FALSE).
This is to enable you to set up critical transactional programs such as support requests, order and shipping confirmation, etc.
- These emails may not contain any marketing content that is not directly related to the transaction that triggered them.
- Only the first email in the path will ignore the opt-in. All others will behave as normal emails.
- This will only work is there is no node, not even a Splitter or Wait node, between the entry point and the Email node.
It is particularly important to understand the cost of making a program more complex in terms of throughput.
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.
Please make sure to use a Filter switch when splitting paths, in order to avoid contact duplication when the paths are joined again later. For more information, see Automation Center - Best Practices & Examples.
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.
Simple new contact program
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
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
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.
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.
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.
Full program reporting, including goal definition and success criteria, is only available via the Smart Insight module. However, there are some easy ways to set up some simple reporting for yourself.
- Using filters
- If you add a Wait node and a Filter to the end of a path, you can measure the success of the path by whatever metrics you like. You can filter for straightforward responses, or measure specific database fields (such as total monthly revenue). For this reason many Blueprints already have filters at the end of their paths.
- Using the Trends page
- If you assign all the emails in a program to a category unique to that program, you can select that category in the Trends analysis and view the overall responses for the entire program. Since the emails are listed in chronological order according to their first launch, this will give a broad impression of contact participation through the workflow of the program.
The Automation Center program scheduling uses the account default timezone; please be aware that changing the timezone settings in the Administrators page will not affect this.
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.
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.