IPM Insights + Auto Predict + Advanced Predictions: Cube Design Tips That Help Me!
If you’ve tried to roll out IPM Insights, Auto Predict, or Advanced Predictions and thought, “This should be easy… what am I doing wrong?”
In my experience, most of the pain isn’t the algorithms. It’s the cube design decisions we made years ago (optimized for fast planning, fast reporting, maximum flexibility) colliding with what predictive workflows actually want: clean signals, consistent grain, not-crazy sparsity, and repeatable slices.
Oracle gives us a ton of freedom... you can define slices, run analyses across intersections, and even handle Dynamic Calc members in more advanced setups. But “possible” and “pleasant” are not the same thing.
Here are four tips that consistently make these features behave better.
Tip 1: Normalize the dataset (even if the app isn’t “perfectly modeled”)
Predictive features work best when I stop making the model clever and start making it predictable.
What “normalize” means in real life:
Pick one clear target measure to predict (not five versions of the same metric spread across accounts/measures)
Reduce “special cases” that create discontinuities (exception accounts, one-off rollups, overrides everywhere)
Keep drivers explicit if you’re doing multivariate work (Advanced Predictions is literally built for that)
If your model is messy (most are), I’ve had good luck creating a predictive-friendly measure layer: a small, standardized set of measures the predictive engine uses… while the reporting layer stays as fancy as it needs to be.
Tip 2: Pick the grain first, then design around it
I see this constantly:
Actuals: daily / transactional-ish
Plan: monthly
Reporting: wants everything
Predictions: “Can we just… predict it all?”
You’ll have a much better time if you pick one training grain (usually monthly at the intersection that matters) and stick to it.
Rule of thumb:
If I can’t describe the prediction grain in one sentence, it’s going to be hard to operationalize.
Why it matters:
IPM Insights is slice-driven. Repeatability depends on stable slices and consistent intersections.
Tip 3: Keep the predictive slice small, stable, and repeatable
Auto Predict and Insights aren’t asking for “every dimension all the time.” They want clean, consistent time series across a reasonable set of intersections.
So I try hard not to throw the kitchen sink into the slice.
Practical guidance:
Include only the dimensions needed to explain the business signal
Avoid attributes/dimensions that explode sparsity without real analytical value
Keep the historical and forecast windows consistent so you can run it every cycle without redesigning it
This lines up with how Oracle frames predictive setup: slices + settings + repeatable configuration.
Tip 4: When in doubt, I separate “Planning Operations” from a purpose-built prediction sub-cube
This is my favorite “stop the bleeding” move.
If the production planning cube is:
huge,
highly dimensional,
full of planning-specific logic,
and basically sacred (nobody wants structure changes)
…then I build a purpose-built prediction sub-cube (often a smaller plan type or FreeForm-style model) that’s:
shaped specifically for predictive slices
fed by a controlled integration
safe to iterate without breaking production forms
Source and Target data is at the same grain
Optimized for calculation performance
Why it works:
Cleaner, repeatable slices for Insights/Predictions
Less risk turning production into an experiment
Easier to validate drivers, grain, and results before pushing anything back into the operational model
Quick “Do this / Avoid this” cheat sheet
Quick suggestions to improve Auto Predict and IPM Insights effectiveness.
Closing thoughts!
If predictive features feel flaky, I don’t immediately blame the tool. I start by asking: “Is my data shaped like something that wants to be predicted?”
Most teams get better results by doing less: fewer measures, fewer intersections, consistent grain, stable slices. Then the fun stuff (Insights, Auto Predict, Advanced Predictions) gets easy!
--David