|Table of Contents|
This part of the document describes the different ways through which an external system can use MailUp to send email messages with dynamic contents: this way, it is possible to take advantage of the MailUp reputation and sending infrastructure to avoid spam filters and check both send status and the archive of sent messages.
The dynamic fields allow to send single email messages containing some personalized content, through the same process MailUp uses for confirmation request emails and subscription confirmation emails. These messages - also called transactional emails - have a fixed structure with some personalized fields: for example, they can be used to send the user a password, a notice, an order confirmation, and so on.
- messages are sent very quickly, thanks to an oversized infrastructure that guarantees immediate sending (except in case of grey listing on destination servers). There are no bandwidth restrictions here and a dedicated channel is used for sending (no queue-related delay). Anyway, this functionality should not be overused, not to lose these benefits
- automatic processes can be activated following actions that users might have performed.
- MailUp sends a confirmation message to subscribers through an automatic procedure. Subscription can take place in two ways:
- Standard APIs (subscribe.asp, subscribe.aspx, xmlsubscribe.aspx)
- Import Web Service (WS_MailupImport)
- A web service allow the immediate sending of a single message. This procedure is much more flexible, but it is paramount to follow the instructions provided in the section describing this function.
The method SendSingleNewsletter() allows to send an email message with the indication of subject, recipients and contents.
When using SendSingleNewsletter(), the best practice is to use predefined messages with dynamic sections, and not to create a brand new newsletter for each call. In this case MailUp would keep on using space to store the new contents, thus making performance worse
Email messages sent to groups of users
This section describes the different ways through which MailUp can be used to send email messages to groups and lists of users without accessing the administration console. The methods described above suit to small automations, but if the goal is to send huge amounts of newsletters or DEMs the best practice to be followed is described below.
Standard Web Services
Some possible scenarios are presented here - with the indication of the web services to be used - as examples of frequent cases. This is not an exhaustive view of all the possibilities anyway.
- If the message has to be sent to all the recipients in a list the suggested method is SendNewsletter(). Parameters "send_to = ALL" , list ID, message ID and time and date of sending must be specified. Message and list IDs can be found at the page Settings > Table codes in the MailUp console, or using GetLists() and GetNewsletters() methods.
- If the recipients are just some groups in a list, when calling the SendNewsletter() method group IDs must be specified as well.
- If the users share data that can be extracted using one of MailUp filters (personal data, activity and geolocation filters, available in the Marketing+ package) when calling the SendNewsletter() method the filter to be applied must be indicated as well. Filters can be used in addition or as an alternative to groups. The great advantage of using them lies in the fact that all the users matching a certain condition are automatically included in the filter results, whereas a user must be inserted into a group for group membership.
Do not use SendSingleNewsletter() in place of SendNewsletter(): the first one has to be used only for transactional emails, as described above
- Through WS_MailUpImport methods a new temporary group is created (CreateGroup(groupName)) and a group of recipients is imported to it (StartImportProcess(groupID, recipients,…)). This operation may last several minutes, depending on how huge this group is, and it can be monitored using GetProcessDetails(). Once the import is finished, SendNewsletter(groupID) method can be used to perform the sending. At the end of the process the group which was created for the purpose must be deleted using DeleteGroup().
- The procedure described at (1) is less effective when there are huge amounts of data to be imported, so it may be useful to use an alternative procedure that provides for a "bulk" import from a file following an input via web service. SendMessageNL(fileName, listId, messageId, timeDateSending, …) method allows to schedule a sending for the desired time and date, then asynchronously executes the following operations
- Creation of a temporary group
- Import to this of the recipients indicated in the file
- Sending of the message at the scheduled time and date
- Deletion of the temporary group
The procedure described here can be used to send the imported recipients messages using the email channel only
Methods creating a new message instead of using an existing one should not be overused. A large number of messages created by the web services (e.g. dozens of messages a day) might cause a system overload and worse performances on the long term
When using web service it is not possible to manage the import of external campaign codes, an operation that requires an import via batch.
Batch FTP ZIP
Batch FTP ZIP mode is a special integration allowing to import via batch a zip folder containing several files with the recipients list, the html message to be sent and the sending details (date, time and so on).
This procedure allows to use MailUp to send messages without accessing the administration console.
Batch FTP ZIP integration is available with an extra charge; for technical details see Special integrations
Web Service for massive mailings
The MailUp console can be configured to perform massive mailings with highly personalized contents, through the use of web services. A special web service method is called, while parameters such as the recipient's email address and the body of the message are passed; then the MailUp console stores these calls and intermittently sends the stored messages in blocks. This procedure is suitable for high-volume mailings where sending all the emails within a certain deadline is paramount.
- Higher performance than traditional web services (speed depends on the bandwidth anyway);
- Ability to manage millions of requests per day, and to respect a deadline of delivery, as long as the bandwidth of the console is consistent with the size of the messages, the desired delivery time and the mailing volumes;
- Avoids issues that afflict traditional web services, when every request involves the creation of a new message;
- Sends completely different messages for each recipient
- Allows to specify a text version of the message, different from the html version.
- Designed for cases in which there is no or little need to access the MailUp console, so some features regarding sending or statistics may not be available;
- The console for massive mailings is a spin-off of MailUp 7.3 (released in late 2010), but does not follow the same path of development, so it may not support the latest features added to the new releases of the console;
- Sent messages are stored as belonging to the same newsletter. As a consequence, the statistics include just message-level reports filtered by date;
- Not suitable for single messages sent in real time (appropriate configurations can reduce latency to just one minute, although our experience shows that ideal configurations have a latency of 15-30 minutes)
- In order to guarantee the highest level of performance, a periodic removal of unnecessary data is required. For this reason, this system is not suitable for an intensive 24x7 usage, unless the calls to the web services are spread across two or more MailUp consoles.
I. Plan your integration
Start choosing the use cases that better fit your needs and then select a technical solution that covers your requirements. You can use a mix of different solutions.
For each use case listed on Use Cases and recommended methods, there may be more than one technical solution available: each one is slightly different from the others in terms of features, scalability, or something else.