Why is my message sending slow or stalled?

Sometimes a message may take longer than expected to get out the door. Here are some common reasons why a message may be delayed.

Delays from Segmentation

Cordial's Audience builder provides a very powerful way to segment your contacts using a combination of include and exclude audience rules. It's important to note that messages are queued up and sent to contacts only after all audience rules have been calculated. A message send can be delayed if audience rules are not calculated in a timely manner. Below are some recommendations to help speed up message sends.

Simplify Complex or Redundant Audience Rules

The more audience rules you use for segmentation, the more time it takes to calculate the audience. For best performance, try reducing the amount of rules being used.

For example, look for redundant audience rules such as: Have been sent "Message123" in conjunction with Have opened "Message123". If a contact has opened Message123 you can deduce that they've been sent the message, so you can achieve the same result with only one of the above rules.

Adding unnecessary exclude rules should also be avoided.  For example, excluding contacts with a subscribe status of "none" is unnecessary as these contacts are excluded automatically from promotional message sends.

Refrain from Using "Contains" or "End With" Email Address Rules (select accounts only)

When using the Channel - Email Address rule, some Cordial accounts may have options for Contains or End With to identify specific addresses and domains. While this may be a great way to identify problematic emails for a suppression list, it weighs heavily on audience rule calculation and may delay sending for a message. A more performant way to achieve the same result is to use the Has Domain rule instead.

Another option to suppress problematic email addresses is to use a recommended 3rd party data validation vendor, or use the methods outlined in our article: Creating an Internal Suppression List.

Delays from Personalization

While Cordial provides a very powerful way to personalize message content using Smarty, sometimes this can slow the sending process if not used correctly. Keep in mind that each message is compiled uniquely for each contact, and if you are sending to 3 million contacts, each with unique content, the time to send may take longer than expected. It's important to be smart when using Smarty! Here are a few suggestions to speed up the processing.

Use the cacheMinutes Parameter When Rendering External Data

Using the getJSON and getSimpleXML, you are able to pull data from an external source and render it in a message for each contact. It's important to note that each time a message is compiled for a contact there will be a call to the external source storing the data. If that source is slow to respond, or not responding at all, the message sending time will suffer. You can reduce the load on the external source by taking advantage of the cacheMinutes parameter. This will instruct the system to store the external data in memory for a set time period and greatly speed up the rendering process. Plus your IT team will thank you!

Use the newerThan Parameter When Rendering Event Data

When rendering event data in a message, such as a contact's browse behavior, you would use the getEventRecords method. Depending on the traffic to your website, you may have millions of event records in your account, or possibly even one billion. Querying them all for each contact may slow processing time. To make this more performant, take advantage of the newerThan parameter when calling the getEventRecord method. This will allow the system to only query event records newer than a certain date (such as 30 days in the past) and ultimately reduce the processing time.

Use the query Parameter When Rendering Supplement Data

Supplements are a great way to take advantage of additional data for message personalization. However, if your supplement contains a very large amount of data, message sending may slow if the system is forced to query the entire supplement for each message. One way to alleviate this is to use the query parameter to limit the amount of data that is being queried for each message.