Based on the knowledge sources, when you configure

days_back

in both your

dbt_project.yml

and the CLI command, these are two different configurations that serve different purposes: ## What Each Configuration Does 1.

elementary.days_back = 60

in

dbt_project.yml

: This is a configuration for Elementary's anomaly detection tests. It determines the timeframe for collecting metrics and analyzing anomalies. As explained in [this Slack discussion](https://slack.com/archives/C02CTC89LAX/p1677183081530049), "The 'days_back' var on the dbt project is a configuration of the Elementary anomaly detection tests." 2.

-d 10

(or

--days-back 10

) in the CLI: This determines how far back the CLI should look when generating the report. According to the [CLI documentation](https://docs.elementary-data.com/oss/cli-commands#cli-options), this option "Set[s] a limit to how far back Elementary should collect dbt and Elementary results while generating alerts/report." ## What Will Happen When you run `edr send-report --update-bucket-website true -d 10`: - Your Elementary tests will collect and analyze data from the last 60 days (based on your

dbt_project.yml

configuration) - However, the report generated will only display results from the last 10 days (based on your CLI flag) As noted in [this Slack conversation](https://slack.com/archives/C02CTC89LAX/p1669159603059669), you can use different

days_back

settings for different purposes. For example, you could run tests with a longer lookback period while generating reports with a shorter timeframe. Important Note: If you change the

days_back

variable in your

dbt_project.yml

after already running Elementary tests, you'll need to [full refresh the metrics](https://docs.elementary-data.com/oss/general/troubleshooting) by running

dbt run --select data_monitoring_metrics --full-refresh

and then running the Elementary tests again.

Based on the knowledge sources, here's what you need to know about full-refresh and changing the

days_back

parameter: ## Drawbacks of Full-Refresh The main drawback of running a full-refresh on Elementary models is data loss. As explained in [this Slack discussion](https://slack.com/archives/C02CTC89LAX/p1674823249739599): > "if you run a full refresh you will lose the history because it's not a regular model - there is no other place to read the history from" Specifically, you will lose: - Historical test results - Historical model run information - Previously collected metrics This is why Elementary's incremental models are [not full-refreshed by default](https://docs.elementary-data.com/guides/modules-overview/dbt-package#package-full-refresh) - "these models contain information such as historical runs and test results, which typically you'd want to maintain." ## What Happens If You Don't Do Full-Refresh If you change the

days_back

parameter in your

dbt_project.yml

without running a full-refresh, the results will remain the same. According to the [troubleshooting documentation](https://docs.elementary-data.com/oss/general/troubleshooting): > "If you change it after executing elementary tests, you will need to run a full refresh to the metrics collected. This will make the next tests collect data for the new

training_period

timeframe." Without the full-refresh, Elementary will continue to use the previously collected metrics based on the old

days_back

setting, and won't recalculate metrics for the new timeframe. ## Alternative Approach If you want to avoid losing historical data, you can: 1. Simply upgrade and keep the history - new data will use the new

days_back

setting while old data remains unchanged 2. Use the

--days-back

parameter in the CLI to control what appears in reports without affecting the underlying data collection As mentioned in [this Slack conversation](https://slack.com/archives/C02CTC89LAX/p1668519863054579), you can also exclude Elementary from full-refresh commands:

dbt run --exclude elementary --full-refresh

You're absolutely right to call out that confusion - I apologize for the unclear explanation. Let me clarify based on the knowledge sources: ## The Reality You are correct: if you want to change the

days_back

(now called

training_period

in newer versions) parameter to increase your training period for anomaly detection tests, you must do a full-refresh for it to take effect. As stated in the [troubleshooting documentation](https://docs.elementary-data.com/oss/general/troubleshooting): > "If you change it after executing elementary tests, you will need to run a full refresh to the metrics collected. This will make the next tests collect data for the new

training_period

timeframe." And yes, this means you will lose historical data, as confirmed in [this Slack discussion](https://slack.com/archives/C02CTC89LAX/p1674823249739599). ## Why the CLI

--days-back

Won't Help You're also correct that using only the CLI

--days-back

parameter won't solve your problem. As explained in [this Slack conversation](https://slack.com/archives/C02CTC89LAX/p1677183081530049): - The

days_back

var in

dbt_project.yml

is a configuration of the Elementary anomaly detection tests (affects how tests calculate anomalies) - The CLI

--days-back

flag only determines the time span of data presented in the report (doesn't affect test calculations) ## The Trade-off Unfortunately, based on the knowledge sources, there's no way to increase your training period for standard deviation calculations without doing a full-refresh and losing historical data. You'll need to decide whether the improved anomaly detection from a longer training period is worth losing the historical test results and metrics.

Yes, this is expected behavior with Elementary. When you run a full-refresh on the Elementary models using the standard

--full-refresh

flag, it does not automatically truncate or wipe the incremental Elementary tables. This is by design, so that historical data (such as test results and metrics) is preserved even when you perform a full-refresh on your main dbt models. Elementary's incremental models are not affected by the standard

--full-refresh

flag. To actually wipe and refresh the Elementary tables, you need to use the special variable `elementary_full_refresh`:

bash dbt run -s elementary --vars '{"elementary_full_refresh": "true"}'

This command will refresh all the Elementary incremental tables and remove the historical data, which would then be reflected in your dashboard. If you only use

--full-refresh

without the

elementary_full_refresh

variable, your dashboard will still show the previous data, as you observed. This behavior is confirmed in the documentation and multiple Slack threads, for example: > "Elementary’s incremental models aren’t truncated by the standard full refresh flag. This is because generally you wouldn’t want those models to truncate. To run full-refresh, use the

elementary_full_refresh

var..." [FAQ: How to run full-refresh / truncate Elementary's incremental models?](https://docs.elementary-data.com/oss/general/faq) So, what you are seeing is normal and expected. If you want to actually reset the data, use the

elementary_full_refresh

variable as shown above.

Yes, based on the knowledge sources, after you have: 1. Changed the

days_back

parameter to 60 days in your

dbt_project.yml

. 2. Run a full refresh of the metrics by executing:

dbt run -s elementary --profile elementary --full-refresh -t elementary-prod

You have completed the required steps for Elementary to start collecting and analyzing data using the new 60-day training period. This process ensures that the next runs of your Elementary tests will use the updated timeframe for anomaly detection and metrics calculations, as described in the troubleshooting and configuration documentation: > "If you change it after executing elementary tests, you will need to run a full refresh to the metrics collected. This will make the next tests collect data for the new

training_period

timeframe." [Anomaly Tests Troubleshooting](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/Anomaly-troubleshooting-guide) No further action is required unless you want to also refresh the dashboard display period, in which case you can use the CLI

--days-back

flag when generating reports, but this does not affect the underlying test calculations. If you see the expected data in your dashboard and your tests are running as intended, you are done.

Yes, after changing your test to use weekly buckets instead of daily buckets, and performing a full-refresh as you described, your new configuration should be live. The knowledge sources confirm that the

time_bucket

parameter (e.g.,

period: week, count: 1

) controls how data is grouped for anomaly detection, and changes to this parameter will take effect after a full-refresh and rerunning the tests. This ensures that Elementary will now analyze your data in weekly intervals as specified in your updated test configuration [time_bucket documentation](https://docs.elementary-data.com/data-tests/anomaly-detection-configuration/time-bucket). If you have completed the full-refresh and rerun the tests, your dashboard and reports should now reflect the new weekly bucket configuration. If you do not see the expected results, double-check your test configuration and ensure the full-refresh was applied to the correct models.