Custom metrics vs standard metrics in analytics reporting API: performance and flexibility trade-offs

CRM Adobe Experience Cloud
, , , , , , , ,
1

Building executive dashboards that pull data from AEC 2021 Reporting API. We need some metrics that aren’t available as standard (like “pipeline velocity by region” and “weighted opportunity value by product line”). I can calculate these as custom metrics in the API queries, but I’m concerned about performance.

Standard metrics like “total opportunities” and “win rate” return in under 2 seconds for large datasets. My custom metric queries that do aggregations and calculations are taking 15-20 seconds for the same date ranges. This makes the dashboards feel sluggish.

Is this the expected trade-off? Do custom metrics inherently perform worse because they’re calculated on-the-fly? Or am I doing something wrong in how I’m structuring the API queries? Would love to hear how others balance the need for custom business metrics against query performance requirements.

system 2

The 15–20 second delta you’re seeing isn’t purely a standard vs. custom metric distinction — it’s primarily about where and when the computation happens.

Why standard metrics are faster

Standard metrics (total opportunities, win rate, etc.) are pre-aggregated at ingestion time and stored as materialized values in Adobe’s reporting layer. The API is essentially doing a lookup with filters, not a calculation. Custom metrics that require multi-level aggregation, cross-dimensional joins, or weighted calculations are computed at query time against raw or partially rolled-up data. That’s the architectural reason for the gap.

Criteria Comparison

Criteria Standard Metrics Custom Metrics (Query-time) Pre-computed Custom (ETL/Workspace)
Response time <2 sec (pre-aggregated) 10–25 sec typical Near-standard, depends on refresh cadence
Flexibility Fixed definitions Fully customizable Customizable at build time
Maintenance overhead None Low High (pipeline ownership)
Data freshness Near real-time Near real-time Lag = ETL frequency
Complex logic support Limited High High
API payload complexity Simple High (segment stacking, inline calc) Simple (reads pre-built metric)

Structural issues to investigate first

Before accepting the performance hit as inevitable, check your query structure:

  • Segment stacking: Each nested segment in a custom metric compounds processing. Flatten where possible.
  • Date granularity: Pulling day-level granularity when the dashboard only needs month-level forces unnecessary row expansion before aggregation — verify in your version whether granularity parameter affects calc scope.
  • Metric dependencies: If “pipeline velocity” references another calculated metric, you may be triggering chained resolution. Decompose into atomic components and combine at the application layer instead.
  • limit and page parameters: Large result sets without pagination force full computation before response. Paginate aggressively.
// Example: paginate to reduce compute surface per call
{
  "globalFilters": [...],
  "metricContainer": { "metrics": [...] },
  "settings": {
    "limit": 50,
    "page": 0
  }
}

Architectural alternatives

Option 1 — Application-layer calculation: Pull atomic standard metrics via API, compute “pipeline velocity” and “weighted opportunity value” in your dashboard backend. Keeps API calls fast; shifts CPU to your infrastructure.

Option 2 — Scheduled export + cache: Use the Reporting API on a scheduled job (hourly/nightly), store results in a lightweight data store (Redis, Postgres), and serve dashboards from cache. Eliminates user-facing latency entirely at the cost of freshness lag.

Option 3 — Adobe Customer Journey Analytics (if licensed): CJA’s architecture handles complex calculated metrics more efficiently through its columnar store — verify in your version whether this applies to your specific calculation types.

The right balance depends on context / your requirements — specifically your tolerance for data latency vs. dashboard interactivity, and whether you own the infrastructure to support an application-layer or caching approach.

This draft is based on general Adobe Experience Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

Yes, custom metrics perform worse by design. Standard metrics are pre-aggregated in AEC’s data warehouse - they’re calculated during nightly batch jobs and stored as materialized values. When you query them, you’re reading pre-computed results. Custom metrics require on-the-fly calculation across raw data, which means full table scans and runtime aggregations. For large datasets, this is always going to be slower. The 15-20 second response times you’re seeing are actually pretty normal for complex custom calculations.

4

You can improve custom metric performance by narrowing your query scope. Instead of calculating pipeline velocity across all time, limit to specific date ranges or regions in the API request. Use the API’s filter parameters aggressively - pre-filter by stage, product line, or owner before doing custom calculations. This reduces the dataset size before aggregation happens. We cut our custom metric query times from 18 seconds to 6 seconds just by adding proper filters. Also, consider if you really need real-time data or if hourly/daily refresh is acceptable for cached results.

5

For frequently-used custom metrics, create them as calculated fields in AEC’s data model rather than computing them in API queries. Navigate to Analytics > Calculated Fields and define your metrics there. AEC will pre-compute them during data processing cycles and they’ll perform like standard metrics. The limitation is they’re static definitions - you can’t parameterize them per API call. But for core business metrics that don’t change (like weighted pipeline value), this is the right approach. Save dynamic custom calculations for ad-hoc analysis only.

6

Dashboard performance isn’t just about API query speed - it’s also about how you’re fetching data. Are you making separate API calls for each custom metric? That’s a common mistake. Use the Reporting API’s batch query feature to request multiple metrics in a single call. We consolidated 8 separate API requests into one batch query and reduced total dashboard load time from 45 seconds to 12 seconds. The API can parallelize internal calculations when metrics are requested together, which is way more efficient than sequential individual queries.

7

Consider a hybrid caching strategy. For executive dashboards that don’t need real-time data, cache custom metric results in your application layer (Redis, database, etc.) and refresh on a schedule. We cache our complex custom metrics every 4 hours and serve dashboard requests from cache. This gives us the flexibility of custom calculations without the performance hit on every page load. Only trigger live API queries when users explicitly request fresh data. This pattern is especially effective for metrics that involve historical trend calculations where the underlying data rarely changes.

8

Look at your custom metric logic - some calculations are inherently more expensive than others. Weighted averages and percentile calculations (like median deal size) require sorting and multiple passes over the data, which kills performance. If possible, approximate complex calculations with simpler alternatives. For example, instead of calculating exact pipeline velocity (time-based movement tracking), approximate it using stage transition counts divided by average deal age. It’s not perfect but it’s 5x faster and often close enough for executive reporting where trends matter more than precision.

9

Having optimized numerous reporting implementations, here’s a comprehensive framework for balancing custom metrics and performance:

Custom Metric Flexibility: Custom metrics provide essential business-specific calculations that standard metrics can’t deliver. In AEC 2021, the Reporting API supports custom metric definitions through calculated expressions in query payloads. You can create metrics like pipeline velocity (average days between stage transitions), weighted opportunity value (probability × amount), conversion rates by segment, and complex ratios. The flexibility is powerful - you can parameterize calculations per API call, combine multiple standard metrics, apply conditional logic, and aggregate across custom dimensions. This enables dashboards tailored to your exact business KPIs without being constrained by AEC’s predefined metric catalog. However, this flexibility comes with performance costs because these calculations execute at query time against raw or minimally aggregated data.

Standard Metric Optimization: Standard metrics in AEC are pre-aggregated during nightly ETL processes and stored as materialized values in the analytics data warehouse. When you query metrics like “total opportunities,” “win rate,” or “average deal size,” you’re reading pre-computed results from optimized tables with proper indexing. Query execution is essentially a table lookup with filtering, which is why you see sub-2-second response times even for large datasets. Standard metrics also benefit from incremental updates - only changed data is reprocessed, not full historical recalculation. The trade-off is inflexibility - you’re limited to the metrics AEC provides, and you can’t modify calculation logic or add business-specific nuances. For core sales metrics that align with standard definitions, this performance advantage is substantial.

API Query Performance: Your 15-20 second response times for custom metrics are expected for complex calculations over large datasets. Performance factors include: dataset size (number of opportunities/records being aggregated), calculation complexity (simple sums vs weighted averages vs time-series analysis), join operations (if custom metrics span multiple entities like opportunities + accounts + contacts), and API server load. Optimization strategies: (1) Use aggressive filtering - apply date ranges, stage filters, region filters BEFORE calculation happens. The API’s filter parameters push down to the database query, reducing rows processed. (2) Batch multiple metrics in single API calls using the batch query endpoint. The API can parallelize internal calculations and reuse intermediate results. (3) Simplify calculation logic - replace multi-pass algorithms (medians, percentiles) with single-pass approximations. (4) For frequently-used custom metrics, define them as Calculated Fields in AEC Admin Console. These get pre-computed like standard metrics. (5) Implement application-layer caching for dashboard metrics that don’t require real-time data. Cache results for 1-4 hours and serve from memory/Redis.

For your specific metrics - “pipeline velocity by region” and “weighted opportunity value by product line” - here’s the recommended approach: Define weighted opportunity value as a Calculated Field in AEC (Analytics > Calculated Fields > Create: value × probability, grouped by product line). This will be pre-aggregated and perform like standard metrics. For pipeline velocity, implement a hybrid approach: calculate stage transition deltas in your application layer using cached opportunity history data, then aggregate by region. This avoids expensive time-series calculations in the API query. Update the velocity calculations every 4 hours via scheduled job. For real-time dashboards, display the cached values with a timestamp showing last refresh. This architecture gives you the custom metrics you need with performance comparable to standard metrics, at the cost of slightly delayed data freshness which is typically acceptable for executive dashboards.