Skip to main content

Why do I see different values for the same metric across the platform?

Updated

You may sometimes see one value for a metric in the Metrics or Reports section, and a very different value when you use the same metric inside an email node or a snippet (for example, in a scenario preview).

A typical situation looks like this: in the metric detail or in a report, the metric shows something like 2 500 000, but in the email node or snippet preview, it only shows 845.43. Because the difference is large, it is easy to assume that something is broken.

In most cases, however, this discrepancy is expected and stems from the way time zones and evaluation contexts work in Bloomreach Engagement.

Why it happens

The key point is that the same metric is being evaluated in two different time contexts:

  • Scenarios and previews (email nodes, snippets) always run in UTC‑0, regardless of your profile timezone.

  • Metrics and reports use the user timezone set under Settings → User Settings → Timezone.

When you use relative time filters such as “today”, “yesterday,” or “last X days”, those filters are interpreted differently in each place. In scenarios and previews, “today” means “today in UTC‑0”. In metrics and reports, “today” means “today in your user timezone”.

If your metric is based on a time‑filtered set of events (for example, a SUM, COUNT, AVERAGE, MIN/MAX, or EXISTS check), even a small shift in the time window (for example, local midnight vs. UTC midnight) can add or remove events from the calculation. This is why the results can be dramatically different even though the metric configuration itself is correct.

Example

Imagine your user timezone is set to Europe/Prague (UTC+2).

In Metrics/Reports, a “today” filter covers 00:00–23:59 in Prague time. In Scenarios and previews, the same “today” filter is evaluated as 00:00–23:59 in UTC-0.

Because Prague is two hours ahead of UTC, the mismatch is most noticeable at the start of the local day. For example, 00:30 on May 21 in Prague is 22:30 on May 20 in UTC-0. This means an event can already belong to “today” in Metrics/Reports, while still belonging to “yesterday” in a scenario or preview. As a result, the same metric can show different values even when its configuration is correct.

Metric example using a relative time filter (Today). Relative filters can return different values in reports vs. scenarios because they are evaluated in different time contexts.


A quick way to verify this is to build a report on the same event, drill it down by hour, and compare the hours included in the report with the UTC-0 time window used in the scenario or preview.

  • Create a report on the same event used by the metric.

  • Add timestamp to Rows and set the granularity to hour.

  • Keep the same relative or converted absolute time range you want to validate.

  • Compare the hours included in the report with the UTC-0 window used in the scenario or preview.

Validation report setup: build a report on the same event and drill it down by hour so you can compare which hours fall into the report’s local-time “today” window.
Hourly drilldown showing the day-boundary shift. Events just after midnight in Prague can still belong to the previous day in UTC-0, which explains why the scenario or preview may show a different value.
Comparing the same metric in a snippet preview and in a report helps confirm that the difference comes from the time window, not from a broken metric. The snippet displays results for UTC-0, therefore, an extra 100€ is counted in the snippet as well. 

How to verify it

  1. Check your user timezone.
    Go to Settings → User Settings → Timezone and confirm which timezone is set. If it is anything other than UTC‑0, timezone differences can affect your values.

  2. Make sure you are comparing the same metric.
    Open the metric definition and the report where you see the “expected” value. Then open the scenario and find the specific email node or snippet that uses this metric. Confirm that the metric name and filters are identical.

  3. Compare using an absolute time range.
    In the scenario, note which relative filter you use (for example, “today” or “last 7 days”). Translate that filter into a concrete date/time interval in UTC‑0, then go back to a report and temporarily switch the metric to a fixed absolute range matching that interval. If the metric value in the report now matches (or very closely matches) what you see in the email or snippet preview, the difference was caused by the mismatch between UTC‑0 and your local timezone.

  4. Look at rounding only after timezones.
    If the remaining difference is tiny and only affects decimals (for example, 845.43 versus 845.44), it is usually just rounding and formatting, not a data issue.

Different values usually mean the metric is being evaluated in different time windows, rather than indicating an issue with the metric itself. To verify this, compare the two views using the same absolute time range, or check the event distribution by hour in a report. If you still have doubts, contact Support.

Related articles