What it does

Measures recalculate as part of the system refresh, and you can give individual measures their own slower cadence so the nightly run does not have to recompute everything. The custom schedule sits on top of the system refresh rather than replacing it.

Key facts

• Measures can run on the scheduled system refresh (the default), Weekly, Monthly, or On demand only.
• A system refresh has to be scheduled for any custom measure schedule to fire. A daily system refresh is the recommended baseline.
• Custom measure schedules must line up with the system refresh schedule. Change the system refresh date afterwards and the measures stop refreshing until the schedules realign.
• Set it under Insights > Measures, select the measures, then Schedule. In the pane, Schedule run is On for automatic or Off for manual, and Recurrence carries the frequency.
• When you schedule several measures at once you choose between Keep individual schedules and Define new schedule for all selected measures.
• The Schedule column in the measure list shows each measure's current cadence.
• System-wide scheduling lives under Settings > System > Schedule tab: Refresh schedule toggle, Daily or Weekly, a Time zone, and up to four refresh times per day via Add another time.
• Refresh order is fixed: data sources, then Match, then Merge. Measures, segments, enrichments, activities, profiles and search all depend on Merge. Insights depend on segments and on activities.
• Statuses you will see on Settings > System > Status: Not started, Queued, Processing, Refreshing, Successful, Failed, Failed (permanent), Canceled, and Skipped.
• Skipped means an upstream dependency failed or was skipped, not that the measure itself is broken. Deactivated measures also report Skipped on a scheduled run.
• Jobs run under fair scheduling on shared capacity, so queued work is not guaranteed to run in parallel.

When to use / skip

Leave everything on the system refresh until refresh duration becomes a problem, and it will. Once an environment has a few hundred measures the nightly window starts running into the morning, and that is when custom schedules earn their keep.

The split is usually obvious: measures over closed historical periods — last year's spend, prior-season revenue — do not need recomputing every night and belong on monthly. Measures that drive daily activation, recency and lifetime value, stay on the system refresh. On small environments with a handful of measures, custom schedules add administrative overhead for nothing; skip them and revisit when the refresh time starts creeping.

Configuration decisions

• The system refresh cadence and how many of the four daily slots you actually use, which sets the ceiling for everything downstream.
• Time zone for the system schedule, and whether the client's operational reporting expects data ready before a particular hour.
• Which measures move off the system refresh and onto weekly or monthly, and who signs off that slower data is acceptable.
• Whether any measures should be On demand only — usually the ones an analyst built for a one-off campaign.
• How schedule changes are governed, given that moving the system refresh date breaks alignment for every custom schedule beneath it.
• Whether the environment's export windows sit after measures and segments complete, since exports depend on segments finishing.

Gotchas

• Moving the system refresh date is the trap. Custom measure and segment schedules stop firing and nothing shouts about it — you find out when a downstream export goes stale.
• A measure showing Skipped repeatedly is usually a Merge failure upstream, not a measure problem. Go and look at Merge before touching the measure.
• Deactivated measures report Skipped too, so the status alone does not tell you whether something is broken or simply switched off.
• Segments that reference measures inherit the measure's staleness. Putting a measure on monthly quietly makes any segment built on it monthly in effect.
• Cancelling a refreshing job reverts to the last successful refresh state rather than leaving a partial result, which is safe but means the data is older than the timestamp suggests.
• Everything runs on shared capacity with fair scheduling, so a long-running measure on a large environment will not simply get more parallelism because you asked for more refreshes per day.

Consultant notes

• Set the system refresh schedule before you build measures, not after. Retrofitting alignment across dozens of custom schedules is tedious.
• Show the client the Status tab and the dependency chain early. It converts "the data is wrong" tickets into "Merge failed last night" tickets, which are far easier to handle.
• Agree a data freshness SLA in writing per measure family. Business users assume everything is real time until told otherwise.
• Before go-live, run a full system refresh end to end and time it. Note the finish time against the client's first-thing-in-the-morning expectations.
• Audit schedules quarterly alongside the measure register — cadences drift as people build new things and never revisit the old ones.

---

Worth another look if refresh frequency limits or the dependency chain change in a future release wave.