The delivery dashboard is key to monitor your deliveries and eventual issues encountered during the sending of messages.
To view the information on a delivery, edit it, view the dashboard and click the available tabs.
Tab contents may no longer be changed once the delivery has been sent.
The Summary tab contains the characteristics of the delivery: delivery status, channel used, information about the sender, subject, information concerning execution. For more on this, refer to Number of messages sent.
The reports link lets you look at a set of reports concerning the delivery action: general delivery report, detailed report, delivery report, distribution of failed messages, opening rate, clicks and transactions, etc. The contents of this tab can be configured according to your requirements. For more information, refer to this section.
The Delivery tab gives a history of the occurrences in this delivery. It contains the delivery logs, i.e. the list of messages sent and their status and the associated messages.
For a delivery, you can display (for example) only recipients with a failed delivery or an address in quarantine. To do this, click the Filters button and select By state. Then select the state in the drop-down list.
Various statuses are listed on this page.
The Display the mirror page for this message… link lets you view the mirror page for the contents of the delivery selected from the list in a new window. The mirror page is available only for deliveries for which HTML content has been defined. For more on this, refer to Generating the mirror page.
The Tracking tab lists the tracking history for this delivery. This tab displays tracking data for the messages sent, i.e. all URLs subject to tracking by Adobe Campaign. The tracking data is updated hourly.
If tracking isn’t enabled for a delivery, this tab isn’t displayed.
Tracking configuration is performed at the appropriate stage in the delivery wizard. See How to configure tracked links.
Tracking data is interpreted in the delivery reports. See this section.
The Audit tab contains the delivery log and all the messages concerning the proofs. The Refresh button lets you update the data. Use the Filters button to define a filter on the data.
Special icons enable you to identify errors or warnings. See Analyzing the delivery.
The Proofs sub-tab lets you view the list of proofs that have been sent.
You can modify the information displayed in this window (and that of the Delivery and Tracking tabs) by selecting the columns to be displayed. To do this, click the Configure list icon located in the lower right-hand corner. For more on configuring list display, refer to this section.
From your delivery dashboard, you want to check the processed messages and delivery logs to be sure that your delivery was successfully sent.
Some indicators or status can be incorrect or not up-to-date, this may be resolved with the following solutions:
You can also track your deliveries with different reports via the delivery dashboard. For more on this, refer to this section.
If delivery performances are bad, you can check:
Platform and database maintenance can also affect delivery sending performances. For more on this, refer to this page.
After clicking the Send button, your delivery seems to take longer than usual. This may be caused by different elements:
Some email providers might have added your IP addresses to a denylist. In this case, check your broadlogs and consult this section.
Throttling might have occurred within the Adobe Campaign MTA. This is caused by:
A system issue can prevent servers from interacting together: this can slow down the whole sending process. Check the servers to ensure that there is no memory or resource issues which can impact Campaign in the process of getting the personalization data for example.
Do not keep deliveries in failed state on the instance, as this maintains temporary tables and impacts the performance.
Remove deliveries which are no longer needed.
Inactive recipients in the last 12 months to be removed from the database to maintain address quality.
Do no try to schedule large deliveries together. There is a gap of 5-10 minutes to spread the load uniformly over the system. Coordinate the scheduling of deliveries with the other members of your team to ensure the best performance. When the marketing server is handling many different tasks at the same time, it can slow down performance.
Keep the size of your emails as low as possible. The recommended maximum size of an email is about 35KB. The size of an email delivery generates a certain amount of volume in the sending servers.
Large deliveries, such as deliveries to over one million recipients, need space in the sending queues. This alone is not an issue for the server, but when combined with dozens of other large deliveries all going out at the same time, it can introduce a sending delay.
Personalization in emails pulls data out of the database for each recipient. If there are many personalization elements, that increases the amount of data needed to prepare the delivery.
Index addresses. To optimize the performance of the SQL queries used in the application, an index can be declared from the main element of the data schema.
ISPs would deactivate addresses after a period of inactivity. Bounced messages are sent to senders to inform them about this new status.
While sending a delivery, you may face the following status on your delivery dashboard:
|| Definitions and solutions
| Not applicable
|| The delivery was taken into account by the server (MTA) but not processed.
|| The delivery was not sent to the recipient because of an error with his address. It was either on denylist, quarantined, not provided or a duplicate.
|| The delivery was correctly sent to the message provider (but the recipient did not necessarily receive it).
|| The delivery could not reach the recipient because of an invalid address or a full inbox for example. It can also be linked to an issue with personalization blocks since they can generate errors when the schemas do not match the delivery mapping. See Failed status
| Taken into account by the service provider
|| The SMS service provider received the delivery.
| Received on mobile
|| The recipient received the SMS on their mobile device.
|| The delivery is ready to be sent and is going to be processed by the delivery server (MTA). See Pending status.
| Delivery canceled
|| The delivery was canceled by an operator.
|| Intermediary status used only for external connectors such as the mobile channel. It follows the 'Pending' status and is the external connector that will determine the following status.
| Sent to the service provider
|| The delivery was sent to the SMS service provider but not received yet.
After confirming your delivery, you can see that the status of your delivery is Pending. This status means that the execution process is waiting on the availability of some resources.
The Pending status can first mean that your delivery has been scheduled and is pending until the given date. For more on this, refer to the Delivery scheduling section.
If your delivery is not being sent and its status remains Pending, it can be the result of:
The MTA (Message Transfert Agent), that runs modules and processes on the delivery server and that manages email sending, may have not been started, or need to be restarted. To check this and to start the module if necessary, apply the following steps:
mta@<instance>modules are launched on your MTA servers.
nlserver pdump HH:MM:SS > Application server for Adobe Campaign Classic (X.Y.Z YY.R build nnnn@SHA1) of DD/MM/YYYY [...] mta@<INSTANCENAME> (9268) - 23.0 Mb [...]
nlserver start mta@<INSTANCENAME>
<INSTANCENAME> with the name of your instance (production, development, etc.). The instance name is identified via the configuration files:
[path of application]nl6/conf/config-<INSTANCENAME>.xml
The delivery may be using an affinity not configured on the sending server. In this case, check the configuration of the traffic management (IP affinity) and use the Managing affinities with IP addresses field to link deliveries to the MTA that manages the affinity. For more information on affinities, refer to this section.
When the delivery preparation is pending, there can be too many campaigns running, which blocked the status update of the delivery. To solve this, go to Options and increase the value of NmsOperation_LimitConcurrency (default is 10). Do not run more campaigns than the value assigned to this specific option.
If an email delivery’s status is Failed, it can be linked to an issue with personalization blocks. Personalization blocks in a delivery can generate errors when the schemas do not match the delivery mapping, for example.
Delivery logs are key to learn why a delivery failed. Here are possible errors that you can detect from delivery logs:
If recipient messages are failing with an “Unreachable” error stating: Error while compiling script ‘content htmlContent’ line X:
To correct this, the workflow and delivery content need to be reviewed to determine specifically what personalization is attempting to call the table in question and whether or not the table can be mapped. From there, either removing the call to this table in the HTML or fixing the mapping to the delivery would be the path to resolution.
In mid-sourcing deployment model, the following message can appear in the delivery logs: Error during the call of method ‘AppendDeliveryPart’ on the mid sourcing server: 'Communication error with the server: please check this one is correctly configured. Code HTTP 408 ‘Service temporarily unavailable’.
The cause is linked to performance issues. It means that the marketing instance spend too much time building data before sending it to the mid-sourcing server.
To solve this, we recommend performing a vacuum and reindex on the database. For more information on database maintenance, refer to this section.
You should also restart all workflows with a scheduled activity, and all workflows in failed status. Refer to this section.
When a delivery fails, the following error can appear in the delivery logs: DLV-XXXX The count of message prepared (123) is greater than the number of messages to send (111). Please contact support.
Usually, this error means that there is a personalization field or block within the email that has more than one values for the recipient. A personalization block is being used and it is fetching more than one record for a particular recipient.
To solve this, check the personalization data used, and then check the target for recipients that have more than one entry for any of those fields. You can also use a Deduplication activity in the targeting workflow prior to the delivery activity to check there is only one personalization field at a time. For more information on deduplication, refer to this page.
Some delivery can fail with an “Unreachable” error stating: "Inbound email bounce (rule ‘Auto_replies’ has matched this bounce). This means that the delivery succeeded but Adobe Campaign received an auto-reply from the recipient (e.g. an “Out of office” reply) that matched the ‘Auto_replies’ inbound email rules. The auto-reply email is ignored by Adobe Campaign, and the recipient’s address will not be sent to quarantines.
You can access deliveries from the delivery list, via the Campaign Management > Deliveries node of the tree.
By default, the list of deliveries contains the names and statuses of the deliveries created in the selected node. It also shows the number of messages to send, processed and sent with success.
The delivery dashboard lets you track the number of messages sent.
For large deliveries, you may wish to update these values. To do this, select the delivery in question and then right-click it. Select Action > Recompute delivery and tracking indicators… and then use the wizard to update this information.
If deliveries do not execute at exact scheduled date, it can be related to a difference between servers time zone. The mid-sourcing instance and the production instance can be in different time zones.
As an example, if the mid-sourcing instance is in Brisbane time zone and production instance is in Darwin time zone, both time zones are half an hour apart from each other, then in the audit log you would clearly see that if the delivery is scheduled for production at 11:56, the same delivery scheduled for mid would be at 12:26 which has a difference of half an hour.