Forum Discussion
PBI to data science
- A sales forecasting model is built in Python. How would you present the results in Power BI?
- A fraud detection model produces a fraud probability score. How would you design a dashboard for business users?
- Customer churn predictions are generated daily. How would you create an executive dashboard?
- How would you visualize SHAP values or feature importance in Power BI?
- A model's accuracy drops from 92% to 80%. How would you build a dashboard to help investigate the issue?
Hi powerbidev123 ,
I would separate the model-scoring layer from the reporting layer.
My general approach would be:
Python/Fabric model → prediction table in a Lakehouse or Warehouse → semantic model → Power BI report
I would write each prediction together with the business key, prediction timestamp, model version, probability or score, predicted class, and any explanation fields required by the report. Power BI can then consume that table like any other business dataset. In Fabric, batch scoring can be operationalised with PREDICT, and Direct Lake can make updated predictions available to Power BI without repeatedly importing the data.
1. Sales forecasting
I would store the forecast at the required business grain, for example:
Date | Product | Region | Forecast | Lower Bound | Upper Bound | Actual
In Power BI, I would use:
- a line chart comparing actual and forecast values,
- confidence bands for the upper and lower bounds,
- variance measures such as actual versus forecast,
- slicers for region, product and forecast horizon,
- forecast-accuracy metrics such as MAE, RMSE or MAPE
2. Fraud probability
I would avoid presenting only a single probability score. The dashboard should help the fraud team decide what requires attention.
I would include:
- transaction volume and value,
- high-risk transaction count,
- fraud probability distribution,
- a table of flagged transactions ranked by risk,
- geography, merchant, customer and time-based patterns,
- model threshold controls or threshold bands,
- the main contributing factors for each flagged transaction.
The operational threshold should be selected according to the cost of false positives and false negatives, rather than using 0.5 automatically.
3. Daily customer-churn predictions
I would build an executive page showing:
- customers currently at high risk,
- total revenue or account value at risk,
- changes in the high-risk population over time,
- churn risk by segment, product and region,
- the leading churn drivers,
- a prioritised customer-action table.
I would also preserve the daily prediction history rather than overwriting yesterday’s results. That makes it possible to show whether an individual customer’s risk is increasing or decreasing.
4. SHAP values and feature importance
I would calculate SHAP values in Python and persist the results in reporting-friendly tables.
For example:
Global explanation table
ModelVersion | Feature | MeanAbsoluteSHAP | Rank
Local explanation table
PredictionID | Feature | SHAPValue | FeatureValue
In Power BI, global importance can be shown with a sorted bar chart, while local explanations can use positive-versus-negative contribution bars for a selected prediction. SHAP estimates how individual features contribute to a prediction, and Microsoft Fabric also provides a tabular SHAP explainer for model interpretability.
Although Python visuals are available in Power BI, I would normally calculate and store the explanation data upstream and use native Power BI visuals for the final report. That generally gives the report better filtering, interaction and maintainability. Python visuals and Python-script imports remain useful for specialised visualisations or experimentation.
5. Investigating an accuracy drop from 92% to 80%
I would not show only the overall accuracy. I would create a model-monitoring page that compares the current evaluation period with the previous baseline.
I would include:
- accuracy, precision, recall, F1 and AUC over time,
- confusion matrices for both periods,
- performance by customer segment, region or product,
- prediction-score and feature-distribution changes,
- missing-value and data-quality trends,
- actual class balance versus the training period,
- model version and deployment date,
- feature-importance changes,
- examples of newly misclassified records.
This helps distinguish between:
- data drift,
- concept drift,
- a change in class balance,
- pipeline or feature-engineering problems,
- threshold changes,
- or poorer performance within one specific business segment.
The key principle is that Power BI should not merely display model output. It should help the business understand what was predicted, why it was predicted, what changed and what action should be taken.
1 Reply
- ShivekMaharajImpactful Individual
Hi powerbidev123 ,
I would separate the model-scoring layer from the reporting layer.
My general approach would be:
Python/Fabric model → prediction table in a Lakehouse or Warehouse → semantic model → Power BI report
I would write each prediction together with the business key, prediction timestamp, model version, probability or score, predicted class, and any explanation fields required by the report. Power BI can then consume that table like any other business dataset. In Fabric, batch scoring can be operationalised with PREDICT, and Direct Lake can make updated predictions available to Power BI without repeatedly importing the data.
1. Sales forecasting
I would store the forecast at the required business grain, for example:
Date | Product | Region | Forecast | Lower Bound | Upper Bound | Actual
In Power BI, I would use:
- a line chart comparing actual and forecast values,
- confidence bands for the upper and lower bounds,
- variance measures such as actual versus forecast,
- slicers for region, product and forecast horizon,
- forecast-accuracy metrics such as MAE, RMSE or MAPE
2. Fraud probability
I would avoid presenting only a single probability score. The dashboard should help the fraud team decide what requires attention.
I would include:
- transaction volume and value,
- high-risk transaction count,
- fraud probability distribution,
- a table of flagged transactions ranked by risk,
- geography, merchant, customer and time-based patterns,
- model threshold controls or threshold bands,
- the main contributing factors for each flagged transaction.
The operational threshold should be selected according to the cost of false positives and false negatives, rather than using 0.5 automatically.
3. Daily customer-churn predictions
I would build an executive page showing:
- customers currently at high risk,
- total revenue or account value at risk,
- changes in the high-risk population over time,
- churn risk by segment, product and region,
- the leading churn drivers,
- a prioritised customer-action table.
I would also preserve the daily prediction history rather than overwriting yesterday’s results. That makes it possible to show whether an individual customer’s risk is increasing or decreasing.
4. SHAP values and feature importance
I would calculate SHAP values in Python and persist the results in reporting-friendly tables.
For example:
Global explanation table
ModelVersion | Feature | MeanAbsoluteSHAP | Rank
Local explanation table
PredictionID | Feature | SHAPValue | FeatureValue
In Power BI, global importance can be shown with a sorted bar chart, while local explanations can use positive-versus-negative contribution bars for a selected prediction. SHAP estimates how individual features contribute to a prediction, and Microsoft Fabric also provides a tabular SHAP explainer for model interpretability.
Although Python visuals are available in Power BI, I would normally calculate and store the explanation data upstream and use native Power BI visuals for the final report. That generally gives the report better filtering, interaction and maintainability. Python visuals and Python-script imports remain useful for specialised visualisations or experimentation.
5. Investigating an accuracy drop from 92% to 80%
I would not show only the overall accuracy. I would create a model-monitoring page that compares the current evaluation period with the previous baseline.
I would include:
- accuracy, precision, recall, F1 and AUC over time,
- confusion matrices for both periods,
- performance by customer segment, region or product,
- prediction-score and feature-distribution changes,
- missing-value and data-quality trends,
- actual class balance versus the training period,
- model version and deployment date,
- feature-importance changes,
- examples of newly misclassified records.
This helps distinguish between:
- data drift,
- concept drift,
- a change in class balance,
- pipeline or feature-engineering problems,
- threshold changes,
- or poorer performance within one specific business segment.
The key principle is that Power BI should not merely display model output. It should help the business understand what was predicted, why it was predicted, what changed and what action should be taken.