Hello! I was today stumbling over using multiple date dimensions in 2 cases and was wondering if what I tried to do is possible. Data Model: One “Rewards” Fact table with two Dates associated to it: “Confirmed At” and “Paid At”. a) I have a table view that shows Reward counts by those two dates on a monthly basis. Can I define a running sum along one of the two time dimensions? b) I wanted to define a “Payout Ratio” that basically calculates: Number of Rewards paid out at a certain date divided by number of rewards confirmed in the 4 weeks before that date. Then I wanted to show that in a table that is grouped by “Paid At (Month”

a) You can use

RUNSUM

, but only over one date dimension. Running-total functions work on a single date dimension and can be further scoped with

WITHIN

(e.g. month, quarter). They can’t run simultaneously over both “Confirmed At” and “Paid At” in the same metric. [[Running totals core](https://www.gooddata.com/docs/cloud/create-metrics/maql/runing-totals/running-totals-for-core-functions/); [Running totals intro](https://www.gooddata.com/docs/cloud/create-metrics/maql/runing-totals/)] So in your table that has both dates, you can: - Pick one of them (say

Confirmed At

) as the running-total axis:

maql   SELECT RUNSUM({metric/reward_count})

- Optionally reset within a higher date grain:

maql   SELECT RUNSUM({metric/reward_count}) WITHIN ({label/confirmed_at.month})

- You may still include

Paid At

in the insight, but the running logic will follow only the date dimension used as the context for the metric. Running totals support breakdown by additional date attributes from the same date dimension, but not by another date dimension. [[Running totals core](https://www.gooddata.com/docs/cloud/create-metrics/maql/runing-totals/running-totals-for-core-functions/)] b) Your “Payout Ratio” depends on two different date dimensions and a lookback window, which runs into current MAQL limitations: - Running-total functions (like

RUNSUM

) work only over a single date dimension. [[Running totals core](https://www.gooddata.com/docs/cloud/create-metrics/maql/runing-totals/running-totals-for-core-functions/)] - Similar limitations have appeared in other multi-date use cases (cohorts, received/updated dates, claim timelines); support has confirmed that these patterns are not directly expressible with a single MAQL metric and often require additional modeling (e.g., a new snapshot/derived date dimension or a “days since X” helper) or multiple metrics. [[Cohort & RUNSUM Slack](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1709738618806549?thread_ts=1709738618.806549&cid=C04S1MSLEAW); [Rewards modeling Slack](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1744733651521469?thread_ts=1744733651.521469&cid=C04S1MSLEAW)] The knowledge sources do not provide a concrete MAQL pattern that: - takes “Rewards paid at date D” (using

Paid At

), and - divides by “Rewards confirmed in the 4 weeks prior to D” (using

Confirmed At

), - while presenting this as a single ratio metric grouped by

Paid At (Month)

. Instead, the documented guidance for similar problems is: - Introduce an additional modeling construct (e.g. snapshot date or “days since confirmation”) to represent the analysis time axis. [[Rewards modeling Slack](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1744733651521469?thread_ts=1744733651.521469&cid=C04S1MSLEAW)] - Or use multiple metrics, each tied to a single date dimension, and combine them at the visualization level (e.g. as separate metrics or calculated metrics in the insight), while accepting some limitations—especially where the denominator needs a rolling “4 weeks before paid date” window across another date dimension. [[Cohort & RUNSUM Slack](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1709738618806549?thread_ts=1709738618.806549&cid=C04S1MSLEAW)] Because of these constraints, I’m not able to give you a fully working single-MAQL definition for that payout ratio based solely on the provided sources; the documented material indicates this is a non-trivial multi-date use case that likely needs data-model changes or multiple helper metrics rather than one straightforward expression.

as a follow up to the RUNSUM question @kapa.ai: When I have a table with 2 date dimensions, can I specify in the metric which of those dimensions to use? It seems to be a quite natural use case to use running sums in those kind of tables.

A message from kapa.ai

@kapa.ai can you please create a product request to enable this in the future?

A message from kapa.ai

Hi Thomas, I will proceed with creating the product feedback as requested. Please note that we are unable to provide an ETA at this time, as our engineering team is currently focused on higher-priority tasks. Thank you for understanding.

🎉 New note created.

A message from kapa.ai