Forecasting FAQ

Documentation Index

Fetch the complete documentation index at: https://docs.cloudcapital.co/llms.txt

Use this file to discover all available pages before exploring further.

​

Correlation and Business Metrics

How does Cloud Capital calculate correlation? When you connect a Business Metric to a Cost Layer using the Metric - Auto projection type, Cloud Capital compares the historical values of that metric against the historical actual costs for that layer. Using the overlapping data, it derives a coefficient — a number that captures how much costs tend to move for each unit change in the metric. For example, if your Users count has grown alongside your Production costs over the past year, Cloud Capital quantifies that relationship: “For every 1 new User, costs increase by $7.83.” That coefficient is then applied forward using your forecast metric values to project future costs. This calculation requires at least 3 months of overlapping data — historical metric values and actual cost data for the same period. The more months of overlap, the more reliable the coefficient.

---

How do I know if the correlation has worked? Three signals tell you:

1. The label in the dropdown. When you open the Associated Business Metric dropdown in the Projection panel, each metric shows a correlation assessment. Strong Positive Correlation means the historical relationship is reliable and the metric is a good fit for this Cost Layer.
2. The plain-language description. After selecting a metric, Cloud Capital shows a sentence like “For every 1 unit Users increases, costs increase by $7.83.” Read it against your operational knowledge of how this Cost Layer scales. If the number feels roughly right — if losing one customer really does reduce costs by approximately that amount — the correlation is working. If it feels wildly off, consider whether a different metric or methodology is a better fit.
3. The Projection Preview. The chart and scenario table show exactly how the forecast would shift if you accept this metric. Compare the “Selected” line against the “Baseline” and sense-check the trajectory: does this match what you expect to happen as the metric grows?

---

What does “Strong Positive Correlation” mean? It means there is a consistent, statistically meaningful relationship (|r| ≥ 0.7) between the metric’s historical values and the Cost Layer’s historical costs — specifically, that as the metric increases, costs tend to increase as well. The stronger the correlation, the more confident Cloud Capital can be that changes in the metric will reliably predict changes in cost. Strong Positive Correlation is the best signal you can get — it means the metric is doing exactly the job a business metric is supposed to do.

---

Why does my metric show “Insufficient Data”? Cloud Capital needs at least 3 months of overlapping data — metric values and actual costs for the same calendar months — before it can calculate a reliable correlation coefficient. A newly created metric will show Insufficient Data until that threshold is met. Two options while you wait:

• Switch the Correlation Methodology to Direct: 1:1, which projects costs in exact proportion to metric changes without requiring historical overlap. Useful for new metrics or new Cost Layers where you have a strong operational reason to expect a proportional relationship.
• Import historical metric data via Google Sheets to backfill actuals. Once 3+ months of overlap exist, Cloud Capital will recalculate the correlation and Auto methodology will become available.

---

Can I use different metrics for different Cost Layers? Yes — each Cost Layer has its own projection setting, and each can be connected to a different business metric. This is intentional: the metric that drives your production workload (customer count) is probably not the same metric that drives your data infrastructure (data volume processed) or your internal tooling (seat count). Setting projections at the right granularity — different metrics for different layers — is where the forecast moves from a rough estimate to a model that genuinely reflects how your business works.

---

What if I don’t have any business metrics yet? Start with Flat or Trend projections while you set up your metrics. Those are valid starting points, and a forecast with good Cost Layer structure using Flat projections is still useful for Cloud Capital’s optimization work. Once you have even one well-defined metric — customer count is usually the easiest to start with — connect it to your most cost-significant production Cost Layer. Three months of overlapping data will unlock Auto correlation. From there, expand to additional metrics as your data matures.

---

​

Validating Your Forecast

How do I validate that my forecast is accurate? There is no single check — validation is a combination of sense-checks across the forecast inputs:

• Cost Layer structure. Does the structure reflect how Finance thinks about cloud spend? Are COGS and OpEx separated? Do the sub-layers match the products, teams, or service families that matter for reporting? A poorly structured forecast is hard to reason about, which makes it hard to validate.
• Business metric values. Are the Forecast row values in your business metrics aligned with what Finance is actually planning? Open each metric and compare the forecast numbers to your operating plan. If Finance is forecasting 500 customers by Q4 and your metric says 200, the forecast will be wrong regardless of how good the correlation is.
• Projection type choices. Does each Cost Layer have the right methodology? Production workloads with a connected metric should use Metric - Auto. Fixed infrastructure with no expected change should use Flat. A layer where you know the exact growth rate should use Fixed Percentage.
• Engineering Initiatives. Are upcoming infrastructure changes captured? A planned migration, a service deprecation, or a major new deployment all have real cost implications. If those are not in the forecast, the projection for the affected layers will be wrong.
• The Projection Preview. Before saving any change to a Cost Layer projection, check the Projection Preview. The scenario comparison table shows you the month-by-month impact. If a change produces a trajectory that surprises you, investigate before saving.

Your Cloud Capital team reviews the forecast with you in weekly, monthly, and quarterly sessions. Those reviews are the primary validation mechanism — bring questions, flag anomalies, and use the session to align Finance and Engineering on what the forecast is assuming.

---

How often should I update my business metrics? Metric actuals should be updated monthly — when real data from the previous month is available, enter it. This keeps the historical dataset growing, which improves correlation quality over time. Metric forecasts should be updated whenever your business plan changes. If Finance revises the growth plan at the end of a quarter, update the Forecast row to match. The forecast is only as forward-looking as the inputs that drive it. A practical rhythm: review and update metrics as part of your monthly Cloud Capital review. That cadence keeps the forecast current without requiring constant attention.

---

How often should I update my engineering initiatives? Update Engineering Initiatives as soon as plans firm up — not at the end of the quarter when the work is about to start. The earlier Cloud Capital knows about a planned infrastructure change, the earlier it can reflect that change in commitment sizing. This matters most for changes that will reduce committable spend — a migration off EC2, a service deprecation, a workload right-sizing project. If Cloud Capital purchases commitments sized against current spend and the reduction happens immediately after, the commitment may not have enough time in the optimized state to fully pay back. Leading with the initiative keeps the proposal well-timed. If a plan changes or is cancelled, remove or update the initiative immediately. The forecast should reflect what you actually expect to happen, not what you planned six months ago.

---

What if my forecast looks wrong? Work backwards through the inputs:

1. Check the metric values — are Actuals current, and do Forecast values match the business plan?
2. Check the projection type — is Metric - Auto applied to layers where you’d expect it? Is Flat applied where you’d expect costs to hold steady?
3. Check the Cost Layer structure — is spend allocated to the right layers? Misallocated spend produces projections that look correct in total but wrong at the layer level.
4. Check engineering initiatives — is a planned change already affecting actuals that hasn’t been captured as an initiative?

If something still looks off after those checks, raise it in your next Cloud Capital review. The team can look at the underlying data and help identify whether the issue is in the inputs, the correlation, or the structure.

---

​

Forecast and the Guaranteed Savings Rate

How does the forecast affect my Guaranteed Savings Rate? The GSR Cloud Capital guarantees is calculated from your forecast. Cloud Capital uses the forecast — your Cost Layer structure, your business metrics, your engineering initiatives — to determine how much spend is committable, over what term, and with what buffer. A more accurate forecast allows Cloud Capital to calculate the GSR more precisely and stand behind it more fully. A vague or stale forecast constrains what Cloud Capital can confidently guarantee, because the uncertainty in the inputs requires a larger safety margin in the rate. The practical consequence: keeping your forecast current is the single most direct action you can take to maximize your guaranteed savings. It is also a requirement of your agreement — Cloud Capital can only do its best work when the inputs are complete and up to date.

---

What happens if my actual spend diverges significantly from the forecast? Cloud Capital monitors actual vs forecast continuously. In your monthly and quarterly reviews, significant divergences will be surfaced and discussed. The response depends on the cause:

• The business metric moved differently than forecast. Update the Forecast row to reflect the revised expectation going forward. The historical data now includes the divergence, which may also improve the model’s accuracy over time.
• An engineering change happened that wasn’t captured as an initiative. Add a retroactive initiative or update Cost Layer projections to reflect the new baseline. Flag it in the next review so Cloud Capital can assess whether any commitments are affected.
• The divergence is unexplained. Investigate Cost Layer structure and resource mapping first — sometimes spend is being allocated to the wrong layer, which makes the forecast look wrong even when the total is accurate.

The GSR holds regardless of how actuals diverge from the forecast — that is the point of the guarantee. But keeping the forecast current reduces the likelihood that Cloud Capital has to absorb large true-up adjustments, which benefits both sides over time.

---

​

Related pages