Alert not triggering when using "Any of these metrics" with calculated metrics | Community
Skip to main content
D
dvgomeza
Level 2
August 3, 2026
Solved

Alert not triggering when using "Any of these metrics" with calculated metrics

  • August 3, 2026
  • 6 replies
  • 167 views

Hi!

I'm trying to understand why one of my Adobe Analytics alerts isn't triggering.

My configuration is:

  • "Any of these metrics" with 2 calculated metrics.
  • An additional AND condition with a minimum number of visits.
  • Segments applied to all the alert rules.
  • Rolling time window and hourly alert

The alert works when I create two separate alerts—one for each calculated metric—while keeping all the other conditions exactly the same. However, it doesn't trigger when both metrics are included under "Any of these metrics", even when one of them clearly exceeds the threshold.

Has anyone experienced something similar? Is there any limitation or known issue with using calculated metrics together with "Any of these metrics"?

Thanks!

Best answer by PrasanthV

Hi ​@dvgomeza 

 

What you are observing is a known limitation in the Adobe Analytics Intelligent Alerts engine when combining Calculated Metrics, "Any of these metrics" (OR logic), and Global Segment Filters / Minimum Thresholds.

The behavior isn't intuitive, but here is why the alert engine is evaluating your rule as an AND condition instead of an OR condition:

The Technical Root Cause

1. Contextual Evaluation of Calculated Metrics

Calculated metrics are evaluated dynamically at alert-processing time rather than pre-aggregated in the report suite. When multiple calculated metrics are placed under the "Any of these metrics" block:

  • The alert engine builds a unified query context.

  • If global segments or additional AND conditions (such as Visits >= X) are applied to the alert container, the query processor applies those filters across the entire calculation block simultaneously.

  • During execution, if one of the calculated metrics evaluates to a non-triggering state (or produces an un-evaluable/zero result within that segmented hourly slice), the alert engine evaluates the combined calculation vector as incomplete or false, effectively causing the rule to collapse into an AND requirement across all calculated fields.

2. Hourly Time Granularity & Latency Gaps

With hourly alerts, data completeness latency plays a major role:

  • Calculated metrics that rely on segmented ratios, hit-level logic, or distinct counts often take longer to settle during hourly batch processing.

  • If Metric A reaches the threshold during Hour 10, but Metric B's underlying raw components have not fully processed or settled, the alert evaluation engine fails the outer filter condition (AND Visits >= X) against the entire metric block.

  • When both metrics exceed the threshold, their shared raw events cross the filter barrier together, which is why the alert only fired in that specific scenario.

Recommended Workarounds & Solutions

Solution 1: Use Two Separate Alerts (Best Practice)

As you discovered, keeping them as separate alerts is the most reliable method in Adobe Analytics. Because each alert evaluates its calculated metric in its own query execution context:

  • Each metric gets an independent baseline evaluation.

  • Global segment filters and minimum visit counts evaluate isolated from other metrics.

  • Processing latency on one calculated metric will not block the alert execution of the other.

Solution 2: Combine the Logic Inside a Single Calculated Metric

If you must receive only one alert notification when either threshold is crossed, move the OR logic into the Calculated Metrics Builder instead of the Alert Builder:

  1. Create a new Calculated Metric using the If function or standard boolean addition:

    Plaintext

     

    (Calculated Metric A >= Threshold_A) OR (Calculated Metric B >= Threshold_B)

  2. In the Alert Builder, monitor this single calculated metric for a value >= 1.

  3. Applying your segment and minimum visit filters to this single metric in the Alert Builder will process cleanly without trigger evaluation collisions.

6 replies

D
dvgomezaAuthor
Level 2
August 4, 2026

Update: I noticed something interesting. The alert was triggered yesterday, but only because both calculated metrics exceeded their thresholds at the same time. When only one of the metrics exceeds its threshold (while all other conditions are met), the alert doesn't trigger. Since the alert is configured with "Any of these metrics", I would expect it to behave as an OR condition. Has anyone else observed this behavior?

P
PrasanthVAccepted solution
Level 4
August 5, 2026

Hi ​@dvgomeza 

 

What you are observing is a known limitation in the Adobe Analytics Intelligent Alerts engine when combining Calculated Metrics, "Any of these metrics" (OR logic), and Global Segment Filters / Minimum Thresholds.

The behavior isn't intuitive, but here is why the alert engine is evaluating your rule as an AND condition instead of an OR condition:

The Technical Root Cause

1. Contextual Evaluation of Calculated Metrics

Calculated metrics are evaluated dynamically at alert-processing time rather than pre-aggregated in the report suite. When multiple calculated metrics are placed under the "Any of these metrics" block:

  • The alert engine builds a unified query context.

  • If global segments or additional AND conditions (such as Visits >= X) are applied to the alert container, the query processor applies those filters across the entire calculation block simultaneously.

  • During execution, if one of the calculated metrics evaluates to a non-triggering state (or produces an un-evaluable/zero result within that segmented hourly slice), the alert engine evaluates the combined calculation vector as incomplete or false, effectively causing the rule to collapse into an AND requirement across all calculated fields.

2. Hourly Time Granularity & Latency Gaps

With hourly alerts, data completeness latency plays a major role:

  • Calculated metrics that rely on segmented ratios, hit-level logic, or distinct counts often take longer to settle during hourly batch processing.

  • If Metric A reaches the threshold during Hour 10, but Metric B's underlying raw components have not fully processed or settled, the alert evaluation engine fails the outer filter condition (AND Visits >= X) against the entire metric block.

  • When both metrics exceed the threshold, their shared raw events cross the filter barrier together, which is why the alert only fired in that specific scenario.

Recommended Workarounds & Solutions

Solution 1: Use Two Separate Alerts (Best Practice)

As you discovered, keeping them as separate alerts is the most reliable method in Adobe Analytics. Because each alert evaluates its calculated metric in its own query execution context:

  • Each metric gets an independent baseline evaluation.

  • Global segment filters and minimum visit counts evaluate isolated from other metrics.

  • Processing latency on one calculated metric will not block the alert execution of the other.

Solution 2: Combine the Logic Inside a Single Calculated Metric

If you must receive only one alert notification when either threshold is crossed, move the OR logic into the Calculated Metrics Builder instead of the Alert Builder:

  1. Create a new Calculated Metric using the If function or standard boolean addition:

    Plaintext

     

    (Calculated Metric A >= Threshold_A) OR (Calculated Metric B >= Threshold_B)

  2. In the Alert Builder, monitor this single calculated metric for a value >= 1.

  3. Applying your segment and minimum visit filters to this single metric in the Alert Builder will process cleanly without trigger evaluation collisions.

D
dvgomezaAuthor
Level 2
August 5, 2026

 

 Hi ​@PrasanthV 

Thanks for the detailed explanation.

Is there any Adobe documentation, release note, or known issue article that describes this limitation? I haven't been able to find any official reference stating that "Any of these metrics" behaves differently when calculated metrics, segments, and additional conditions are combined.


Also, I'm not sure Solution 2 fits our use case.

Our calculated metrics are intentionally generic and reusable across multiple products and operations.

Both the product scope and the thresholds are configured at the alert level:

  • Product scope is applied through alert-level segments.
  • Thresholds are defined directly in the alert conditions.

If we move the logic into a calculated metric such as:

IF(Technical Error % >= 15,1,0)
+
IF(Conversion Rate <= 1,1,0)

then the thresholds become hardcoded inside the metric and can no longer be configured independently for different alerts.

In our current design, the same metrics are reused across multiple alerts, while thresholds and segments vary depending on the product and use case.

How would you implement Solution 2 while keeping both the product scope and the thresholds configurable at the alert level?

Regarding Solution 1, as you've already seen, I was able to confirm that using separate alerts works as expected. However, given the number of products, teams, and alert types involved, that approach does not scale well. Ideally, we'd like to leverage the stacked alert functionality and maintain a reusable alert framework.

Thanks again for taking the time to explain this and for your help.

Regards

P
PrasanthV
Level 4
August 10, 2026

Hi ​@dvgomeza,

1. Regarding Official Documentation & Documentation Gaps

There is no official Adobe documentation, release note, or known issue article that explicitly states "When 'Any of these metrics' contains multiple calculated metrics combined with alert-level segments and minimum threshold conditions, the evaluation logic defaults to an AND operation."

This is a recognized documentation gap within Experience League. The official Experience League guide on the Alert Builder defines "Any of these metrics" purely as a logical OR trigger.

However, this behavior stems from how the Anomaly Detection and Intelligent Alerts processing service compiles backend queries:

  • When an alert uses raw metrics (e.g., Orders OR Visits), the alert service evaluates two distinct, isolated threshold queries.

  • When an alert uses calculated metrics combined with alert-level segments and additional AND thresholds (e.g., Visits >= X), the system wraps the metrics into a single calculated context. During execution on hourly time windows, if one calculated metric evaluates as null or fails to satisfy the global AND segment filter for that hourly slice, the entire payload context returns false, effectively collapsing the OR logic into an AND requirement.

2. Solving Solution 2 (Keeping Metrics Standardized & Thresholds Dynamic)

Dynamic, alert-level threshold configuration can be preserved without hardcoding thresholds inside the calculated metric or relying on separate, non-scalable alerts.

Instead of writing threshold numbers into the calculated metric, the threshold values can be abstracted into standalone, baseline Calculated Metrics or Event parameters.

Pattern A: Normalized Index / Ratio Thresholds (Recommended)

Rather than hardcoding absolute values (like 15% or 1%), normalize your calculated metrics so that 1.0 (or 100%) represents the universal trigger line for every alert.

  1. The Reusable Base Metrics:

    • Metric A Normalized = $\frac{\text{Technical Error \%}}{\text{Target Error Threshold}}$

    • Metric B Normalized = $\frac{\text{Target Conversion Rate}}{\text{Conversion Rate}}$

  2. The Dynamic Input:

    Instead of hardcoding 15% in the alert, pass the product-specific threshold as an event or calculated parameter per product/scope.

  3. The Multi-Goal Metric:

    Create one standardized metric called Unified Alert Trigger:

    $$\text{Max}\left( \text{Metric A Normalized}, \text{Metric B Normalized} \right)$$

  4. The Alert Configuration:

    In your Alert Builder, you monitor Unified Alert Trigger $\ge 1.0$.

    • If Technical Error % reaches $15\%$, the ratio becomes $\frac{15}{15} = 1.0$ $\rightarrow$ Alert Fires.

    • If Conversion Rate drops to $1\%$, its ratio becomes $1.0$ $\rightarrow$ Alert Fires.

Why this scales: The calculated metric remains universal across all teams. The product-specific variations are driven by the baseline metrics or segment filters applied at the alert layer.

Pattern B: Boolean Switch via Segmented Calculated Metrics

If the product scope is driven by alert-level segments, build a generic "Flag" metric that evaluates boolean states using Greater Than / Less Than functions without locking in strict values:

Plaintext

 

// Calculated Metric Name: "System Alert State"
IF ( Metric_A > 0 AND Metric_A_Anomaly_Score > 1.96 , 1 , 0 )
+
IF ( Metric_B > 0 AND Metric_B_Anomaly_Score > 1.96 , 1 , 0 )

  • In the Alert Builder, monitor System Alert State >= 1.

  • The Product Scope is still applied dynamically via your Alert-Level Segment.

  • The sensitivity (Anomaly Score or Percentage Variance) is handled mathematically at runtime, allowing the single metric to be stacked across all your alerts without duplicating formulas per product team.

manpreetkaur27
Adobe Support
manpreetkaur27Adobe Support
Adobe Support
August 11, 2026

Hi ​@dvgomeza If your query has been addressed, kindly consider marking the response as the best answer. This will help others who may have a similar concern in the future.

Terms & ConditionsAccessibility statement

Loading footer...