Note:For data views with a custom calendar, we do not support monthly granularity in the Alert Builder.

Important:The phone number must be preceded by a “+” and a country code.

The email that a user receives after an alert is triggered looks similar to this:

To account for this delay in ingestion time, alerts have a default delay of 9 hours before they are sent.

You can adjust the default delay of 9 hours to anywhere between 0 and 24 hours. However, decreasing the delay below 9 hours can mean that you are reporting on incomplete data, which results in inaccurate alert information.

Consider the following when decreasing the delay time:

• Understand data availability vs. data completeness: While some data might be available to report on sooner, all batch data is ingested into a Platform dataset only after a period of 3 to 9 hours. For alerts to be accurate, data ingestion must be complete, with all batch data available in the dataset.
• Determine how long it takes for your data to be complete and available in the dataset: Data ingestion times differ by organization. Make sure that the delay time you choose for alert delivery is the same or less frequent than the time it takes for the batch data to be available in the Platform dataset.

Tip: The most accurate way of knowing the time required for all batch data to be complete and ingested into the Platform dataset is to consult the data engineers in your organization.

Alternatively, you can get a general idea of how long it takes for the batch delivery in your organization to be available in the Platform dataset by creating the following freeform table in Analysis Workspace:

1. In a freeform table in Analysis Workspace, add an Events metric and a Day dimension.
2. Break down the Day dimension using an Hours dimension.

   Hours that have no data will show as 0.

• Account for errors in your calculations: If you decrease the default delay time, we recommend configuring the delay for at least an hour longer than the time it takes your organization for data ingestion completeness. For example, if there is a 3-hour delay before your data ingestion is complete, then you should set the delay to 4 hours.

For more information, see Data ingestion times vary in Customer Journey Analytics in the article Alerts feature comparison: Customer Journey Analytics and Adobe Analytics.

An “incompatible components” message appears if not all the metrics, dimensions, or segments in the alert are compatible with the currently selected data view.

Determine the threshold that the metric must exceed before an alert is set. You can set this value to a threshold and then to one of the following conditions:

• anomaly exists
• anomaly is above expected
• anomaly is below expected
• is above or equals
• is below or equals
• changes by
• You can set a threshold of 90%, 95%, 99%, 99.75%, and 99.9%.

With all of these filters: Drag and drop segments or dimensions to add filters. For example, adding a “Mobile Devices Only” segment would mean that the rule triggers only for mobile devices. You can add additional filters by using an AND statement. You can add AND or OR rules by clicking the gear icon.

See Alerts - use cases for example uses cases.

For example, if you set the time granularity to daily, the preview can tell you that the alert would have been triggered for a certain metric x times during the last 30 or 31 days.

If you find that too many alerts would have been triggered, you can adjust the threshold in the Manage alerts.