Hands-on: getting AI model output into Power BI, Looker or Streamlit, starting from a four-column table

Picture this: the model has finished running, the predictions are sitting in the warehouse, and three weeks later the head of sales still hasn’t opened them once. In a situation like that, the model isn’t what’s broken. The problem is that the results haven’t appeared on the screen decision-makers look at every day.

That screen usually belongs to a BI tool. IBM defines BI as the set of technology processes for collecting, managing and analysing an organisation’s data. IBM also stresses that BI is descriptive: it explains what has happened in order to support better decisions. AI output looks the other way.

In CareerFoundry’s classification, predictive analytics tries to forecast what is likely to happen in the future. So you are placing a number about the future in a tool built to tell stories about the past.

This guide walks through how to do that properly, step by step. The running example is a hypothetical one: customer churn risk scores at a telecoms company.

What will you build, and what do you need?

You will produce two things. The first is an AI output table that any BI tool can read. The second is a Streamlit app that reads that table, serving as a demo before the work moves into the client’s Power BI or Looker.

The demo app can be finished fairly quickly. Integration with the client’s BI needs its own plan, as Step 5 explains.

You need Python, pandas, a table of scores (you can start with a CSV exported from the warehouse; Streamlit’s tutorial uses BigQuery as its example) and read access to that table. Streamlit is an open-source Python framework built for data scientists and AI/ML engineers. If you already know pandas, you don’t need to learn any frontend.

Step 1: Why design the table before choosing a tool?

The first mistake, and the most expensive, is pouring notebook output straight into a dashboard. To last, a churn score table should have at least the four columns below. This is a design suggestion, not any vendor’s standard.

-- Simplified: suggested schema for the model output table
customer_id     STRING,
churn_score     FLOAT,     -- prediction, from 0 to 1
model_version   STRING,    -- e.g. 'churn-v3'
scored_at       TIMESTAMP  -- time of scoring

The last two columns are the ones data scientists tend to skip and BI people need most. Suppose the head of sales asks: “Why did customer A go from 0.2 to 0.8 this week?” Without model_version, you can’t tell whether the customer changed or the model did. Without scored_at, nobody knows how old the number is.

Check after this step: run a query counting rows by model_version. If you see only one version, you are overwriting history. Decide now whether to keep it.

Step 2: Build a Streamlit prototype showing high-risk customers

Before touching the client’s BI system, you should have a working demo. Credentials come first. Streamlit reads secrets from .streamlit/secrets.toml in the app’s root directory, so keys never have to live in the code.

mkdir -p .streamlit
touch .streamlit/secrets.toml
echo ".streamlit/secrets.toml" >> .gitignore

What goes in the secrets file depends on the connection guide for your warehouse. For BigQuery, Streamlit’s tutorial specifies exactly what to paste. Next comes a minimal app: read the score table, show the latest scoring time at the top of the page, then show the 20 highest-risk customers.

import pandas as pd
import streamlit as st

# Simplified: read from a CSV exported from the warehouse.
# When connecting to a real warehouse, replace pd.read_csv with a client as in the BigQuery tutorial.
@st.cache_data(ttl=600)
def load_scores(path):
    return pd.read_csv(path, parse_dates=["scored_at"])

df = load_scores("churn_scores.csv")

st.write("Predicted churn risk, scored at:", df["scored_at"].max())
top = df.sort_values("churn_score", ascending=False).head(20)
st.write(top[["customer_id", "churn_score", "model_version"]])

Run it with streamlit run app.py and you have a ranked table with a line showing when it was scored. The most important part is the st.cache_data decorator.

According to Streamlit’s documentation, with st.cache_data the query only reruns when the query changes or after 10 minutes, and ttl=600 (600 seconds) sets that interval.

Without caching, every filter a viewer clicks becomes a billable query against the warehouse.

Check after this step: temporarily add a print line inside load_scores, reload the page a few times and watch the terminal. If the line prints on every load, the cache isn’t working. Once you connect a real warehouse, check its query history as well.

Step 3: Tune ttl to the model’s run schedule

Don’t leave ttl=600 in place just because the tutorial uses it. Streamlit’s documentation is explicit: if the database updates more often, adjust ttl or drop the cache.

Applied to the churn example: if the model scores once a night, ttl=600 is more than enough and you can set it longer. For a fraud model that scores continuously, however, a 10-minute cache could mean operators see a suspicious transaction up to 10 minutes late.

So ask about the pipeline’s schedule first, then pick the number. The scored_at line at the top of the app helps here too: viewers can see for themselves how old the data is, and will ask you less often.

Step 4: Deploy to get a link

Streamlit offers Community Cloud, a free platform for deploying and sharing apps. If you are using real client data, you must check their security policy first. With synthetic or public data, it is the quickest way to get a link for your portfolio.

Step 5: When should you move to Power BI or Looker?

A Streamlit prototype gets the client to say yes. But the dashboard they use every day usually has to live in the BI tool they already pay for. The two common options work quite differently.

	Power BI	Looker	Streamlit
How the AI table gets in	Connect a cloud or on-premises data source	Describe the table in LookML	Write Python queries directly
Strength	Copilot builds reports from natural-language requests	APIs and many ways to embed data	Fast, suits AI/ML engineers
Ask first	Features depend on SKU and capacity	Who on the client side writes and reviews LookML	Is external hosting allowed?

For Power BI, Microsoft says the tool can connect to data from any source, cloud or on-premises, and Copilot lets you describe the report you need in natural language. But Microsoft also states plainly that feature availability depends on both SKU and capacity level. Don’t demo Copilot to a client before you know which licence they have.

Google describes Looker as a product for exploring, sharing and visualising company data. Modelling is done in LookML, a language for describing SQL data and options for users.

That means your churn score table can only be explored in Looker once it has been modelled in LookML. This belongs in the project plan; it is not a five-minute configuration task.

For Tableau or any other tool, the principle is the same: the cleaner the table from Step 1, the lighter the connection work.

What are the most common mistakes?

The most common is putting predictions next to actual revenue without a label, so viewers assume both are recorded figures. Use a title such as “Predicted churn risk, model churn-v3” rather than just “Churn”.

The second is committing secrets.toml to git. The third is caching for longer than the model’s run cycle and then wondering why the numbers never change. The last is promising a Power BI feature before checking the SKU.

How does this skill show up with clients and on a CV?

With clients, the first question to ask is not “which model?” but “which screen do you open on Monday morning?” The answer decides whether you build in Power BI, write LookML or put up a Streamlit app.

On a CV, a line such as “built a Streamlit app showing churn scores with model version and scoring time, cached to the pipeline schedule”, with a link, is far more convincing than the word “Streamlit” sitting alone in a skills list.

A good model that nobody opens might as well not be deployed. To get it opened, start with the small details: a four-column table, a ttl that matches the pipeline, and a label that says “prediction” in plain words.