docs: Elaborate on refresh_key with every

Author: paveltiunov

docs/pages/product/data-modeling/reference/cube.mdx

@@ -482,9 +482,9 @@ that it will be executed **at most** once. The refresh key may be checked more
 frequently.
 
 When using `every` with `sql`, the purpose is to reduce the load from running
-the refresh key query itself, not to minimize the number of pre-aggregation
+the refresh key query itself, not to minimize the number of cache
 refreshes. The refresh key SQL should be designed to return consistent results
-and only change when the underlying data actually changes, ensuring minimal
+and only change when the underlying data needs to be updated, ensuring minimal
 refreshes even if the query is executed multiple times.
 
 </WarningBox>
@@ -666,4 +666,4 @@ The `access_policy` parameter is used to configure [data access policies][ref-re
 [ref-calendar-cubes-time-shifts]: /product/data-modeling/concepts/calendar-cubes#time-shifts
 [ref-calendar-cubes-granularities]: /product/data-modeling/concepts/calendar-cubes#granularities
 [ref-time-dimensions]: /product/data-modeling/concepts#time-dimensions
-[ref-time-shift]: /product/data-modeling/concepts/multi-stage-calculations#time-shift
+[ref-time-shift]: /product/data-modeling/concepts/multi-stage-calculations#time-shift

docs/pages/product/data-modeling/reference/pre-aggregations.mdx

@@ -974,7 +974,7 @@ frequently.
 When using `every` with `sql`, the purpose is to reduce the load from running
 the refresh key query itself, not to minimize the number of pre-aggregation
 refreshes. The refresh key SQL should be designed to return consistent results
-and only change when the underlying data actually changes, ensuring minimal
+and only change when the underlying data needs to be updated, ensuring minimal
 refreshes even if the query is executed multiple times.
 
 </WarningBox>