Running an A/B test sounds straightforward. Split your test data, measure an outcome, and pick a winner. Yet assumptions in the most common A/B tests can break down in ways that are easy to miss and costly to ignore. Luckily, there are alternative approaches that treat belief as something to be updated as evidence arrives, rather than a mere threshold to be crossed. In this post, we’ll build our knowledge on the Bayesian statistical framework and examine what it really costs to get decisions wrong.

The Issue with Frequentist Probability

The Frequentist definition of probability is the most widely known in statistics. It states that probability measures the long-run frequency of an event occurring over many repeated trials. A classic example is the coin flip. Flipping a coin millions of times, the proportion of heads gradually stabilizes near 0.5 as an estimate of the true underlying probability. That true probability is always unknown, but with enough repeated trials, we can get reasonably close.

Frequentist A/B Testing is an experiment we run to see if two processes behave significantly differently from one another. Consider a pharmaceutical company testing a new treatment to relieve headaches. Patients are randomly assigned to receive treatment A (an existing medication) or treatment B (the new medication). After exposure to the treatment, each patient reports whether their headache was relieved within one hour. The goal of this test is to determine whether treatment B produces a meaningfully higher relief rate than treatment A. The null hypothesis for this A/B test is: Treatments A and B produce identical relief rates. We’d then define a fixed number of patients, each receiving exactly one of the two treatments. Then, we’d use the test results to compute a single p-value answering the question: What’s the probability of observing data as extreme as ours if the null hypothesis is true? If this probability is very unlikely (< 0.05), we’d reject the null hypothesis and claim that the two treatments produce meaningfully different relief rates, resulting in a winner.

Key takeaways on the Frequentist A/B approach:

• The p-value from this test is the probability of observing our collected data given the null hypothesis is true.
• Frequentist probability treats the true relief rates of treatments A and B as fixed, unknown constants (probabilities that do not change).
• The false positive rate (0.05) is only controlled if we commit to our sample size in advance and look at the results exactly once.

Let’s say we decide a reasonable sample size for this experiment to be 500 patients. As we carry out this experiment, stakeholders behind the scenes are eager to monitor the results in real time. After the first 50 sessions, the resulting p-value dips to 0.03, indicating we should reject the null hypothesis and favor treatment B. The issue is, every time we glance at the accumulating results before reaching our defined sample size of 500, we risk rejecting the null hypothesis by chance alone. This is known as p-hacking by peeking, which can actually inflate the 0.05 false positive rate we thought we were controlling. Research suggests that peeking at live results just ten times can balloon a 0.05 false positive rate to upwards of 0.25 (Miller, 2010). So why peek at all? Interim results can be tempting to those who have incentive to act on promising data early, even when the data isn’t fully conclusive. Frequentist A/B testing is meant for a world where we resist that pressure, but that’s not always the case in practice.

After 100 sessions, treatment B has a relief rate of 68% and treatment A has a relief rate of 61%. Is treatment B truly better yet? If we’re playing by the frequentist rules, we’re in a tough spot. We’ve been monitoring the number of collected sessions, but we still haven’t reached our pre-defined sample size of 500 (and frankly, we’re questioning whether 100 independent patient sessions could have been a sufficient sample size to begin with). At this point, the p-value still cannot tell us: Given the data, how confident should we be that treatment B is genuinely better? Lucky for us, Bayesian inference can help us answer this question.

What is Bayesian Statistics?

The Bayesian definition of probability is a measurement of belief. It represents a value of uncertainty about an event, whether it happens once or many times. Our belief in the outcome of an event can change as we observe new evidence. Instead of committing to a single fixed estimate, we maintain a full distribution of beliefs across all possible parameter values, updating these beliefs as new evidence arrives.

Let’s revisit the coin flip for a moment. Under frequentist thinking, we flip a coin millions of times, and the probability of landing on heads will converge to a fixed value around 0.5. With Bayesian probability, we start with a belief about the coin’s bias, like “I expect the true probability of landing on heads to fall between 0.4 and 0.6.” We might suspect the coin is fair, but we’re not certain. Well, we can revise that belief with every flip. After 10 flips, our distribution is wide and uncertain. After 10,000 flips, it has narrowed considerably. While both Frequentist and Bayesian estimates in this example might lead to the same result, the Bayesian approach allows us to carry a full picture of our estimates and uncertainty along the way.

We’ll use this same approach now for the clinical drug experiment. Instead of asking whether the relief rate of treatment B is significantly different than treatment A at some fixed sample size, we’ll construct a distribution of beliefs around both treatments’ true relief rates, updating both in real time as patient sessions are recorded. To understand how that updating works, we need Bayes’ Theorem. Let’s recall our favorite conditional probability formula:

In our experiment, we’re not talking about abstract events A and B. We care about parameters and data. Let’s rewrite this formula as:

Where θ is the unknown parameter we want to learn (the true relief rate for a particular treatment) and X is the observed data (the recorded outcomes of relieved and not relieved from real patient sessions).

Next, we need to define a few new terms:

The posterior is always what we’re after. It reflects our updated belief about θ given everything observed so far.

Let’s put this knowledge to the test with a famous example in Bayesian probability.

Consider a disease that affects 1% of the population. A diagnostic test for this disease is 95% accurate: if you have the disease, the test returns positive 95% of the time. If you don’t have the disease, the test returns negative 95% of the time (a 5% false positive rate). You test positive. What is the probability you actually have the disease?

Here’s how we go about answering this question using the formulas above.

Drumroll…

There’s actually only a 16% chance you have the disease despite a 95% accurate test. Many people (my initial self included) assume the answer is closer to 95%. The disease is so rare that false positives outnumber true positives across the full population. Our prior belief (only 1% of people have this disease) is powerful enough to override a test that is 95% accurate. Thus, the posterior is a balance between prior belief and observed evidence. If you were to test positive twice in a row, that posterior of 16% becomes your new prior going into the next update. Each result reshapes your belief, which becomes the starting point for the next posterior.

A side note on the likelihood P(X)

Notice P(X) sits in the denominator of the posterior formula above. Its only job is to ensure the posterior sums to 1 across all possible values of θ. It has no dependence on θ and is a constant regardless of the parameter value we’re evaluating. Since we’ll be focused on identifying the shape of the posterior distribution, a constant that scales everything uniformly doesn’t meaningfully change anything. We can drop the denominator and write:

Again, the shape of the posterior is determined entirely by the numerator, so we’ll refer to this formula from here on out.

Recall Frequentist probability views the true relief rate of treatment B as a fixed, unknown constant. We can only estimate this true relief rate by collecting data, running a test, and arriving at a single value like 68%. We can add a confidence interval around our estimate, but we’re ultimately left with a single estimate and a range. There’s no formal way for us to say we believe the true rate is probably around 68% with a reasonable chance it’s as high as 75%. We can’t update that estimate fluidly as new sessions arrive either. The Bayesian play is to represent θ (the true relief rate) as a probability distribution. Instead of committing to a single estimate, we capture a full distribution of our uncertainty across every possible value between 0 and 1. The mean of the distribution is where we think the true θ value most likely falls. The width of the distribution reflects how certain or uncertain we are. Whenever new data arrives and we update our prior, the entire distribution updates.

A Beta Distribution Beta(α, β) is a common probability distribution in Bayesian statistics defined on the interval [0,1]. The distribution uses two parameters, α (alpha) and β (beta), to represent pseudo-counts of successes and failures measuring θ. We can use this distribution to model our prior belief of θ. For example, think of α as the number of relieved outcomes (successes) and β as the number of non-relieved outcomes (failures) before the clinical drug experiment begins. A Beta(1, 1) prior represents starting as if we’ve seen exactly one success and one failure (essentially no prior bias). A Beta(10, 30) represents having already observed 10 successes from 40 sessions, suggesting a prior belief of roughly 25% relief rate with moderate confidence.

If we have no prior beliefs on the true relief rates of treatments A or B at the start of the A/B test, we can use the neutral Beta(1,1) as the prior for both treatments. This is a flat, uninformative prior telling the model we have no strong belief about the effectiveness of either treatment before the experiment. After 500 sessions are collected for each treatment, each success and failure to relieve a headache would update the corresponding Beta posterior distributions (one for θ_A , one for θ_B). We’d then ask what the probability is that a sample drawn from B’s posterior exceeds a sample drawn from A’s posterior.

The probability density function for the Beta distribution is:

Where B(α, β) is the normalizing constant ensuring the distribution integrates to 1 over [0,1]. This is analogous to P(X) in Bayes’ theorem. When we plot the Beta distribution, θ sits on the x-axis. We’re never claiming we know θ. Instead, we’re asking how likely each possible value of θ is given our current beliefs. We’ll take a look at a few of these plots below. Try thinking of them as pictures of uncertainty around the true value of θ.

Here are some examples of a prior Beta distribution for the relief rate of treatment B. The peak location is always α/(α+β). The width tells us how much volatility is behind that belief.

Beta(1, 1) — An uninformative prior

This is a completely flat distribution. Every possible relief rate from 0 to 1 is equally likely. We’re essentially expressing no prior belief about what to expect.

Beta(13, 7) — A weak prior belief

Equivalent to observing 13 relieved outcomes from 20 sessions. Soft belief that treatment B’s relief rate is around 65%.

Beta(204, 96) — A strong prior belief

Equivalent to 204 relieved outcomes from 300 sessions. High confidence that treatment B’s relief rate is near 68%.

Now, here’s where the math gets exciting. If we pair the right prior P(θ) distribution with the right likelihood P(X∣θ) distribution, the posterior comes out as the same family of distributions as the prior. This is called Conjugacy, and it’s what makes our update rule clean enough to derive by hand. In the clinical drug experiment, our likelihood comes from a binomial distribution (relieved or not relieved being the binary outcome), and the prior comes from a Beta distribution (defined on the closed [0,1] interval for probability). Together, their combination forms a Beta-Binomial conjugate pair, which can be used to update the prior.

Let’s break down how this works. Consider the likelihood P(X|θ). If we observe n patient sessions for a particular treatment with k successful relief outcomes, the likelihood of this data given a particular value of θ is:

This is the Binomial distribution. It answers the question of how probable it is to observe exactly k relief outcomes from n sessions, given a true relief rate of θ. Notice that (n choose k), the binomial coefficient, is only a constant with no dependence on θ. Just like P(X) in Bayes’ theorem, we can drop it when reasoning about the shape of the posterior. So, the likelihood simplifies to:

To determine the Posterior P(θ|X), we must multiply the likelihood above with our Beta prior. Recall this prior takes the form:

Multiplying the likelihood by the prior:

Collecting exponents:

Upon simplifying, this looks exactly like our Beta distribution, just with updated parameters:

That’s the entire update rule! For a specific treatment in the experiment, our prior was B(α, β). We observe k relieved outcomes from n sessions for that treatment. So, our final posterior is B(α+k, β+n-k).

Here’s an example of how our belief in the true relief rate of treatment B can change as we accumulate data and update our prior with the latest posterior.

Notice that the mean of the posterior after each data collection converges to the true relief rate as we accumulate more and more patient sessions. Each row’s posterior becomes the prior for the next update. Notice also that the first prior’s influence pulling the mean towards 0.5 fades away quickly as real data accumulates. By session 500, the data has taken over to shape the mean. In the clinical drug experiment, we can run this update simultaneously for both treatments, maintaining Beta(α_A, β_A) and Beta(α_B, β_B) in parallel. Every session that arrives updates one of the two distributions depending on which treatment was prescribed. We are never forced to wait for a pre-defined sample size, and the posteriors simply reflect whatever evidence we’ve seen so far.

Making Decisions Under Uncertainty

At any point in the clinical drug trial, we’ll have two posterior distributions.

Either distribution represents our full belief about that treatment’s true relief rate at that point in the experiment. However, these distributions aren’t enough to guide decisions yet. When a stakeholder asks if treatment B is truly better than treatment A, we must answer two questions first.

1. Given the latest data, how likely is it that treatment B is truly better than A?
2. What would a wrong decision in the experiment cost us?

To answer question 1…

A Frequentist 95% confidence interval built around an estimated relief rate won’t tell us there’s a 95% probability the true rate lives inside it. It means that across many repeated experiments, 95% of the constructed intervals would contain the true rate. The true relief rate is always fixed in this lens. A specific confidence interval has it or it doesn’t, and frequentist statistics doesn’t allow us to assign a probability to that.

A Bayesian 95% credible interval is exactly what it sounds like. Given the data observed, there is a 95% probability that the true relief rate lies within this range. In the clinical drug trial, by the time treatment B’s posterior is Beta(341,161), we can hand a stakeholder a credible interval and say with confidence exactly where the true relief rate most likely falls.

With two independent Beta posterior distributions, we want to know how often a sample drawn from B’s posterior would exceed a sample drawn from A’s posterior. This can be denoted:

Analytically, this is computed by integrating over all possible values of θ_A​ and θ_B​:

The double integral may look intimidating, but the intuition is straightforward. If treatment B’s posterior is almost entirely to the right of treatment A’s on the relief rate axis, P(B>A) approaches 1. If the two distributions heavily overlap, P(B>A) hovers near 0.5, meaning the data hasn’t separated them yet. P(B>A) is useful, but it is not quite the right number to make a final decision on.

To answer question 2…

P(B>A) = 0.95 might sound compelling, but what if treatment B is only 0.1% better than treatment A in the scenarios where it wins and 5% worse in the scenarios where it loses? Calling treatment B better might still be the wrong call. This is where expected loss comes in. What is the average cost of making the wrong decision?

We can define a loss function for each possible decision (choosing treatment A or B as superior). In either case, the loss measures how much effectiveness we leave on the table by promoting the inferior treatment. If we promote treatment B and it turns out to be worse, the loss is how much A exceeded B. If we promote treatment A and it turns out to be better, the loss evaluates to zero.

If we were to promote treatment B:

Similarly, if we were to promote treatment A:

We would only decide to promote Treatment B if the expected loss falls below some acceptable threshold ε:

For simplicity, we use a shared threshold ε since treatment A is already the incumbent treatment. We could technically introduce a separate ε for promoting an alternative depending on the experiment.

Remember that Frequentist A/B testing should never allow early stopping in an experiment. The moment we break our commitment to the sample size, our false positive rate inflates and the results become unreliable. Under a Bayesian A/B test, we can stop as soon as the expected loss drops below ε. Whether it takes 100 or 1,000 sessions in the clinical drug experiment, the data will tell us once we’ve collected enough of it.

Tying It All Together

Let’s close with one last scenario. Imagine you’re a data scientist working for a video streaming platform. The platform recommends new content to viewers as soon as they finish watching a video. You’ve built a new recommendation model and want to know if it drives more clicks than the existing one.

Model A is the existing model. It recommends content based on what similar viewers have watched. Model B is your new model. It factors in how long the viewer watched their last video for and whether they’ve rewatched content before. Both models show a ranked list of recommendations at the end of every video. The metric is simple enough. Did the viewer click on at least one recommended video?

We can carry out a simulation exposing 500 viewer sessions to each model. The key unknown in this experiment is the click-through rate (CTR) generated by each model’s recommendation. For our purposes, we’ll set the ground truth CTR for Models A and B at 25% and 28% respectively. This is a modest lift, but reasonable in practice. A 3% difference is meaningful at scale, but subtle enough to go undetected in the early stages of an experiment. That’s what will make this an interesting test case.

Let’s fire up our Python IDE to get started. We’ll first need to simulate viewer session outcomes from the ground truth Binomial distributions of each model.

# Import libraries
import numpy as np
from scipy import stats
import matplotlib.pyplot as plt
from scipy.special import betaln
from scipy.stats import chi2_contingency

# Set seed
np.random.seed(100)

# Pre-defined click through rates for simulation (unknown during experiments)
true_ctr_a = 0.25
true_ctr_b = 0.28

# Number of viewer sessions exposed to each model
n_sessions = 500

# Simulate binary outcomes for each model
clicks_a = np.random.binomial(1, true_ctr_a, n_sessions)
clicks_b = np.random.binomial(1, true_ctr_b, n_sessions)

# Print results
print(f"Model A: {clicks_a.sum()} clicks from {n_sessions} sessions "
      f"(observed CTR: {clicks_a.mean():.3f})")
      
print(f"Model B: {clicks_b.sum()} clicks from {n_sessions} sessions "
      f"(observed CTR: {clicks_b.mean():.3f})")

Model A: 124 clicks from 500 sessions (observed CTR: 0.248)

Model B: 132 clicks from 500 sessions (observed CTR: 0.264)

We’ll now define a few functions to call later in the script. These pull from everything we’ve covered about Bayesian inference so far.

# Create a function to update priors from observed data
def update_posterior(alpha, beta, click):
    """
    Update a Beta posterior given a single binary outcome.
    click = 1 (clicked) increments alpha (successes)
    click = 0 (no click) increments beta (failures)
    """
    alpha += click
    beta += 1 - click
    return alpha, beta

# Create a function to calculate the mean of a posterior distribution
def posterior_mean(alpha, beta):
    return alpha / (alpha + beta)

# Create a function to calculate the variance of a posterior distribution
def posterior_variance(alpha, beta):
    return (alpha * beta) / ((alpha + beta) ** 2 * (alpha + beta + 1))

# Create a function to return a credible interval containing 95% of the posterior distribution's belief about theta
def credible_interval(alpha, beta, credibility=0.95):
    lower = (1 - credibility) / 2
    upper = 1 - lower
    return stats.beta.ppf([lower, upper], alpha, beta)

# Create a function to sample n theta values from a Beta posterior distribution
def sample_posterior(alpha, beta, n=100_000):
    return np.random.beta(alpha, beta, n)

# Create a function to compute P(theta_B > theta_A) for two Beta distributions
def prob_b_beats_a(alpha_a, beta_a, alpha_b, beta_b):
    total = 0.0
    """
    Sum over each possible success count in B's posterior
    Given i successes for B, how much of A's distribution falls below that probability?
    betaln computes log Beta function values to keep numbers stable at large alpha/betas
    """
    for i in range(alpha_b):
        total += np.exp(
            betaln(alpha_a + i, beta_a + beta_b) -
            np.log(beta_b + i) -
            betaln(1 + i, beta_b) -
            betaln(alpha_a, beta_a)
        )
    return total

Unlike the last P(B > A) function above, the expected loss integral doesn’t have a clean closed-form solution. We’ll use Monte Carlo sampling to draw a large number of θ (CTR) values from both posteriors, comparing them element-wise to simulate the joint distribution of (θ_A, θ_B) and estimate expected loss directly. The law of large numbers guarantees this estimate converges to the true expectation quickly. 100,000 samples will be plenty!

def expected_loss(alpha_a, beta_a, alpha_b, beta_b, n_samples=100_000):
    """
    Estimate expected loss for promoting B and promoting A
    via Monte Carlo sampling over the joint posterior.
    """
    samples_a = sample_posterior(alpha_a, beta_a, n_samples)
    samples_b = sample_posterior(alpha_b, beta_b, n_samples)

    # Cost of promoting B: how much does A exceed B when A is better?
    loss_promote_b = np.mean(np.maximum(samples_a - samples_b, 0))

    # Cost of promoting A: how much does B exceed A when B is better?
    loss_promote_a = np.mean(np.maximum(samples_b - samples_a, 0))

    return loss_promote_b, loss_promote_a

The result of this expected loss function is only useful when paired with a threshold. Recall from earlier that we define an acceptable threshold ε and only promote Model B if the expected loss of shipping Model B is less than ε. We’ll set ε equal to 0.5%, meaning we’re willing to accept a 0.5% hit to our clickthrough rate if we accidentally promote the wrong model.

# Maximum acceptable CTR loss
epsilon = 0.005

Assuming we have no prior beliefs about the effectiveness of Model B, we’ll initialize its prior distribution as Beta(1,1). For Model A, its prior performance in production will help construct our prior belief. Let’s represent this belief in Model A’s CTR with a Beta(1,3) distribution.

# Initialize Beta(1,3) prior for Model A (estimating a 25% CTR)
alpha_a, beta_a = 1, 3

# Initialize Beta(1,1) prior for Model B (flat, unbiased)
alpha_b, beta_b = 1, 1

Next, let’s create a dictionary that logs the evolution of each posterior distribution as data accumulates.

# Track experiment history session by session
history = {
    "sessions": [],
    "mean_a": [],
    "mean_b": [],
    "prob_b_beats_a": [],
    "loss_promote_b": [],
    "loss_promote_a": [],
    "decision_made": None
}

# Record initial priors before any data arrives
history["sessions"].append(0)
history["mean_a"].append(posterior_mean(alpha_a, beta_a))
history["mean_b"].append(posterior_mean(alpha_b, beta_b))
history["prob_b_beats_a"].append(prob_b_beats_a(alpha_a, beta_a, alpha_b, beta_b))
history["loss_promote_b"].append(0.0)
history["loss_promote_a"].append(0.0)

As you and I know at this point, Model B is the superior model, so we’ve shaped some of our functions and simulation results around capturing when we’ve confidently observed this outcome.

Let’s run our first simulation to see when Model B proves victorious in the A/B test!

for t in range(1, n_sessions + 1):

    # Update each posterior with the current session outcome
    alpha_a, beta_a = update_posterior(alpha_a, beta_a, clicks_a[t-1])
    alpha_b, beta_b = update_posterior(alpha_b, beta_b, clicks_b[t-1])

    # Compute P(B > A) and expected loss at this point in the experiment
    p_b_wins = prob_b_beats_a(alpha_a, beta_a, alpha_b, beta_b)
    loss_b, loss_a = expected_loss(alpha_a, beta_a, alpha_b, beta_b)

    # Record metrics for the current session
    history["sessions"].append(t)
    history["mean_a"].append(posterior_mean(alpha_a, beta_a))
    history["mean_b"].append(posterior_mean(alpha_b, beta_b))
    history["prob_b_beats_a"].append(p_b_wins)
    history["loss_promote_b"].append(loss_b)
    history["loss_promote_a"].append(loss_a)

    # Promote Model B when expected loss clears epsilon
    if history["decision_made"] is None and loss_b < epsilon:
        history["decision_made"] = t
        print(f"Decision at session {t}: Promote Model B")
        print(f"P(B > A):          {p_b_wins:.4f}")
        print(f"Expected loss:     {loss_b:.5f}")
        print(f"Posterior mean A:  {posterior_mean(alpha_a, beta_a):.4f}")
        print(f"Posterior mean B:  {posterior_mean(alpha_b, beta_b):.4f}")

Decision at session 169: Promote Model B

P(B > A): 0.8267

Expected loss: 0.00429

Posterior mean A: 0.2254

Posterior mean B: 0.2690

By session 169, the expected loss drops below ε, triggering an early decision in favor of Model B. As you can see above, the posterior means didn’t converge to their true CTR values yet. We’re only stating the scenarios sampled from both posteriors produced an acceptably low cost of being wrong about promoting Model B. The Bayesian framework didn’t wait for certainty around the CTR estimates. Instead, the test stopped when the risk of a wrong decision became tolerable.

To put the Bayesian approach in context, let’s run the same simulation as a Frequentist A/B test. We’ll use a Chi-square test to evaluate results at exactly 169 sessions, with a fixed sample size of 500 viewer sessions per model. Stopping here (peeking early) will highlight just how differently the two frameworks interpret the same underlying data.

# Run frequentist chi-square test on data up to the Bayesian decision point
t_decision = history["decision_made"]

# Build a contingency table to run the chi-square test on
contingency = np.array([
    [clicks_a[:t_decision].sum(), t_decision - clicks_a[:t_decision].sum()],
    [clicks_b[:t_decision].sum(), t_decision - clicks_b[:t_decision].sum()]
])

# Results
chi2, p_value, _, _ = chi2_contingency(contingency)
print(f"Frequentist test at session {t_decision} (Peeking Early):")
print(f"Chi-square statistic: {chi2:.4f}")
print(f"p-value:              {p_value:.4f}")
print(f"Significant at 0.05:  {p_value < 0.05}")

Frequentist test at session 169 (Peeking Early):

Chi-square statistic: 0.5749

p-value: 0.4483

Significant at 0.05: False

By session 169 in the Frequentist test, a p-value of 0.45 is nowhere near a 0.05 threshold. The test can’t reject the null hypothesis at this point. It demands more data before drawing any meaningful conclusion.

The Bayesian framework reached a decision at that same session without violating a single assumption. It’s worth noting again: P(B > A) never crossed 0.95 across the entire experiment. The decision wasn’t driven by confidence in the direction of the result. It came down to the expected cost of promoting the wrong model falling below what we were willing to accept. Here’s how that played out across all 500 sessions.

Plot 1 shows both posterior means converging toward the true CTR values over time. Increasing the number of viewer sessions from 500 to 1,000 would get us even closer to 0.25 and 0.28.

In plot 2, P(B > A) spends a long stretch below 0.5 early on. The data briefly favored Model A before enough evidence accumulated to separate the two models. You’ll notice it never crosses 0.95, highlighting why expected loss is the better decision criterion.

Plot 3 tells the clearest story. Expected loss starts high and noisy, then steadily falls as the posteriors sharpen. It crosses epsilon at session 169 and lands us at our answer to promote Model B.

Bayesian statistics gives us a principled way to make decisions under uncertainty without the constraints of frequentist testing. We maintain a full distribution of beliefs about unknown parameters and update them continuously as new evidence arrives. This lets us answer questions that actually matter in practice. The expected loss framework takes it one step further, replacing an arbitrary significance threshold with a concrete measure of what being wrong actually costs. Next time you’re tempted to peek at that p-value, maybe just let the posterior do the talking.

Have you ever inherited a workbook that needs updating and found yourself swimming in hundreds of calculated fields with no clear direction? Or maybe it’s your own old workbook that you’re revisiting, and you have absolutely no interest in dissecting it because it has grown into a monster.

Fortunately, about a year ago, Ana Rey de Castro built a solution for exactly this problem with her Tableau Calculation Extractor. The code is available for free on GitHub and runs locally on your machine, so there is no risk to your files. If you want a walkthrough of the tool, you can also check out a video from Tableau Tim in October 2024 where he discusses the release.

I first heard about this tool directly from Ana and used it shortly after to work through a few messy .twbx files. It was incredibly helpful at the time.

Recently, I ran into another use case for the tool, but this time I was working on a Mac instead of a Windows machine. One limitation of Ana’s original version was that a few of the required packages were Windows-specific, which made the code unusable on macOS.

With the help of Claude Code, I was able to port Ana’s project over to Mac and successfully run the tool locally on my machine. I’m excited to walk through that process and share it with you today.

Where Can I Find the Code?

You can find both Ana’s Windows version and the new Mac version here:

Windows: https://github.com/scinana/tableauCalculationExport

Mac: https://github.com/blakefeiza/Tableau-Calculation-Extractor-Mac

How Does it Work?

The first step is to download the code to your local machine and open the project directory in your IDE of choice. For this walkthrough, I’ll be using Visual Studio Code, but any editor will work just fine.

Since I’m on a Mac, this writeup reflects a macOS setup. If you’re working on Windows, I recommend checking out the Tableau Tim video mentioned above, along with Ana’s original walkthrough.

After downloading the repository, create two folders in the root directory: one called inputs and one called outputs. The inputs folder is where you’ll place the .twbx file you want to analyze. The outputs folder is where the generated PDF, XLSX, or HTML files will appear after running the notebook.

For this demo, I’ll be using my 365 Days of Play workbook. I downloaded the packaged workbook from Tableau Public and dropped the .twbx file into the inputs folder we just created.

Now we’re ready to open the notebook.

In the top cell, review the required packages and confirm that everything is installed on your machine. I left the most common dependencies listed in that first cell for convenience. If anything is missing, go ahead and install it before running the rest of the notebook.

Once the dependencies are handled, the notebook should run in just a few seconds. After it completes, check your outputs folder. You should see the generated artifacts waiting for you.

Both the PDF and Excel outputs provide a comprehensive table listing all field names, field types, calculation logic, and associated data sources for the entire workbook.

One difference you may notice on the Mac version is that instead of the static Mermaid diagram used in the Windows version, this implementation renders a dynamic Cytoscape diagram. The result is an interactive view of your calculation lineage.

I found this especially helpful when working with larger workbooks. You can drill into individual calculations, isolate the lineage for a specific field, and quickly collapse or expand sections as needed. You can also drag and reposition the nodes to structure the diagram in whatever way makes the most sense to you.

This was a shorter post, but I hope some of you find value in this community-built tool. If it makes your life a little easier the next time you need to retrace steps in a complex work project (or a Workout Wednesday challenge), then it has done its job.

This is more of a proof of concept than a fully polished application. If you have ideas on how to improve it, I’d love to hear them. And once again, a huge thank you to Ana Rey de Castro for building the original version and sharing it with the Tableau Community!

If you’ve spent some time scrolling on Tableau Public or observed enough data visualizations across the broader internet, odds are you’ve run into a Trellis Chart. Trellis Charts are useful because they segment a visual into small, repeated views. These views often share the same scales, and make patterns or differences easy to spot. They let viewers compare categories side-by-side without requiring much brain power.

Where Does the Name “Trellis” Come From?

Trellis Charts (also sometimes referred to as small multiples, lattice or panel charts) arrange the views in a grid-like layout. When built tall, these charts resemble a garden trellis.

Building a Trellis Chart

For this blog post, we will visualize the trend of wins per season for every NFL team. The data used for this analysis comes from the GitHub repo nflreadpy. Credit to my brother Ethan Feiza for curating the dataset used in this analysis. You can find a copy of the final dataset here.

While we could certainly plot all of these teams on a single-axis line chart and use a highlight action/color palette to select one or many teams to compare, that approach requires either a pre-baked insight or an end user’s appetite to explore the visualization.

If we use a Trellis Chart instead, we can enable the user to make their own comparisons much easier with a static image.

In order to create this chart, there are only two primary calculations to split up the view, one called “Rows” and one called “Cols”. After we walk through the initial two calculations, I’ll cover a few of the map layers tricks I chose to add on this viz but note that they are optional additions.

I’ll start by adding our [Season] to Columns, [Wins] to Rows, [Team] to Detail, and change the mark type to Area.

Now in order to turn this mess into a trellis chart, we need to add two calculated fields that are each tied to a parameter I like to call [pCols].

Once you’ve created this parameter, create the following two calculated fields:

// Cols
(INDEX()-1)%[pCols]

// Rows
INT((INDEX()-1)/[pCols])

Using some modular arithmetic and rounding, these calculations and our parameter give us the ability to specify how many columns we’d like in our trellis chart and the rows will update dynamically.

Add [Cols] to the Columns and [Rows] to the Rows. You should see something like this:

The next thing we need to do is configure our table calculations for [Cols] and [Rows]. It doesn’t matter which one we start with because the steps are identical for both.

Right click the blue pill and select “Edit Table Calculation”. Select “Specific Dimensions”, make sure both your [Season] and [Team] are checked. Drag the [Team] field to the top.

By default, our sort order will be alphabetical. If we wanted to do something like order the teams by total wins, we can configure that in the “Sort order” option as follows:

Follow these steps for both [Cols] and [Rows] and you should see something like this:

From here, we can uncheck “Show Header” for our [Rows] and [Cols] fields (and optionally clean up [Season] and [Wins]), add some color or additional formatting clean-up, and get something like this:

There are some traditional approaches to add labels and additional formatting to our chart from here, but I’ll leave that as an exercise to the reader. Instead, I’d like to dive into the “Map Layers alternate solution” instead to do as much custom formatting as our hearts desire :)

Optional: Using Map Layers with Trellis Chart Calculations

Okay, I know I said we’d only use two calculations, but this is the bonus section. There are a few more calculations that we’ll need to make in order to turn the above chart into a grid of maps. If you’d like to learn more about these calculations, the in-line comments will prove useful.

// Normalized Season
// Using the traditional "(Number - Min) / (Max - Min) normalization
// This gives us a value between 0 and 1 for every season.
// For a map, we need to stay between (-180,180). Staying between 0 and 1 makes the math easier later on.
([Season] - {MIN([Season])})
/
({MAX([Season])} - {MIN([Season])})

// Wins per Season Makepoint
// This plots a point on our map at 
// Remember MAKEPOINT() uses (Latitude, Longitude) -> backwards from (X,Y)
// I like to think of it as MAKEPOINT(Rise, Run)
MAKEPOINT(SUM([Wins]), MIN([Normalized Season]))

On a new sheet, double click [Wins per Season Makepoint], change your Mark Type to Line, drag [Team] to Detail, and [Season] to Path. You should see something like this:

Next, add the fields [Rows] to Rows and [Cols] to Columns. This time, we’ll do a slightly different table calc configuration, but it will be the same again for both fields.

Right click the blue pill and select “Edit Table Calculation”. Select “Specific Dimensions”, make sure both your [Season] and [Team] are checked. Drag the [Team] field to the top and ensure “At the level” is also on [Team].

Again, feel free to add a custom sort in the “Sort order” control if you’d like. Just make sure to apply the same sort logic to both [Rows] and [Cols]. Once you’re done, you should see something like this:

Take [Wins per Season Makepoint] and again drag it into the view to add another marks layer. This time, change your Mark Type to Area, drag [Team] to Detail, and [Season] to Detail.

Now that we have 2 map layers, we can go in the top toolbar and select Map → Background Maps → None. You should see something like this:

For the final calculation, I chose to add the team label in the top center of each team’s view.

// Team Name Makepoint
// We're just plotting a single dot in space to write our label on
// I used 18 because it sits above the tallest wins
// I used 0.5 because we normalized our seasons between 0 and 1.
MAKEPOINT(18, 0.5)

Add [Team Name Makepoint] as another map layer, change the Mark Type to Circle, under Color lower the opacity to 0%, add [Team] to Label, and change the text alignment to middle center. You should now see something like this:

The only thing left to do is clean-up! For layers like [Team Name Makepoint], make sure to click the dropdown and select “Disable Selection”. This prevents annoying hover effects from impacting your users.

Then, touch up your axes, lines, headers, colors, and fonts as you wish. My final sheet looks like this:

Wrapping It Up

See, that wasn’t so bad! Of all the calculations that I think are worth bookmarking and referring back to, [Rows] and [Cols] are 100% my top 2. In fact, I’m going to write them in once more at the bottom of this blog for my own future reference:

// Cols
(INDEX()-1)%[pCols]

// Rows
INT((INDEX()-1)/[pCols])

I hope this tutorial is easy to follow and you learned a new trick to elevate your Tableau visualizations. See you next month!

As I reflect on 2025, it has been a pretty busy year. A lot changed, there were many wins along the way, and the year truly flew by. Since time isn’t going to slow down anytime soon, I think it’s important to pause and reflect every once in a while, and the new year feels like the best time to do that.

This post will not look like most of my blog content. Instead, I want to take a moment to reflect on a few things from the past year: my favorite vizzes I created in 2025, some of the vizzes from other authors that inspired me, a few of my biggest personal and professional wins, and finally a look ahead at my goals for 2026.

10 Vizzes I’m Most Proud Of

Idle Visual Album Poster (January 10, 2025)

In 2024, my best friend achieved a huge milestone by releasing his first album on streaming platforms. To commemorate this, I created a data-backed poster visualizing the notes played across each song. This viz was a fun passion project to work on and ended up being one of my favorite pieces I published in 2025.

South Park #DataPlusMovies (January 20, 2025)

As part of the #DataPlusMovies community project between IMDb and Tableau, I wanted to create a South Park-themed viz to participate and explore a show I genuinely enjoy. I spent way too much time in Figma designing the background image (probably longer than the analysis), but the end result made it worth it.

Impact of Industrialization by Income Group (March 10, 2025)

While this viz isn’t particularly flashy, it’s built on a connected scatterplot that helped surface an interesting insight. By using size along each line to represent time, the x-axis is freed up to focus on the relationship between urban and rural populations across income groups. It‘s a fairly simple approach, but one that’s seldom used.

Work Productivity Benchmarks (March 25, 2025)

Map layers were clearly on my mind in March. I spent way too long trying to architect these striped bars (see my tutorial blog post here if you’re curious), but the battery-style effect ended up working really well for this productivity dashboard.

Top Migration Destinations (April 6, 2025)

Map layers again? Yes, but this time the technique actually made things easier. I used map layers to build the radar charts, combined them with a trellis layout to create the country grid, and added custom icons for each dimension to better communicate what each section represents. I had a lot of fun with this one.

#GamesNightViz Pokédex (May 9, 2025)

I created this viz as my submission for the #GamesNightViz “Gotta Viz ’Em All” challenge. I knew I wanted to build something creative for this project, and Tableau animations had been top of mind at the time. By using map layers and manually tracing artwork for 20 different Pokémon, I was able to create a fun animated effect that really brought the dashboard to life. Definitely one of the more enjoyable builds from the year.

Cycles of Joblessness (August 20, 2025)

When this Makeover Monday dataset was released, I wasn’t particularly excited. I didn’t know much about UK history, and at first glance the unemployment trend just looked like a random line chart. With some help from ChatGPT, I dug into the historical context and found anecdotes that helped explain why unemployment was rising or falling at different points in time. Combined with some Figma magic, the final result came together better than I expected.

365 Days of Play (August 27, 2025)

So… map layers, again! This viz was inspired by a TikTok, and I took it as a challenge to recreate it in Tableau. I also wrote a blog post on this one, check it out here if you’re curious. Overall, this was one of the hardest things I built all year, but easily one of the most rewarding.

Drug Harm in the UK (September 12, 2025)

Once again, this chart type was not found on the “Show Me” shelf… Playing on the idea of getting “high,” I used a sigmoid function to create a droopy balloon-style chart for some of the most common drug types in the Makeover Monday dataset. This one was a fun experiment that panned out pretty well!

F1’s Fiercest Rivalry (September 17, 2025)

For a long-form viz, this one came together fairly quickly. As part of a case study, I had the opportunity to showcase my Tableau skills through a data project. I built out a narrative using a handful of chart types to tell the story of a rivalry between two F1 drivers, and it ultimately played a role in helping me land a new job.

10 Vizzes That Inspired Me

There’s no community that shares work quite like the Tableau community. I wanted to take a moment to highlight a handful of vizzes from 2025 that inspired me throughout the year, whether through their design choices, storytelling, or technical execution.

Kings of Confection by Brian Moore (January 24, 2025)

This viz makes me salivate a bit. Brian Moore does a fantastic job telling the story of candy in America through a long-form viz, and the design completely blew me away. I really enjoyed reading through this dashboard and learned a few things along the way too!

The Lions Prey by Chris Westlake (June 16, 2025)

When Chris Westlake publishes a new viz, you already know it’s going to be worth your time. This rugby dashboard caught my eye immediately and does an excellent job encoding a ton of information into a single shape. The spirals are especially fascinating to me, and I’d love to use this as inspiration for a future viz.

Super Mario Kart by Matt Huff (June 28, 2025)

I really enjoyed Matt’s approach to this #GamesNightViz Mario project. His use of map layers to build these charts is clever and works really well in this dashboard. Combined with a strong themed design, this dashboard stands out as one of my favorites from the year.

Corruption Perceptions Index by Zyad Wael (August 7, 2025)

Week over week, Zyad is one of the creators I most look forward to seeing participate in Makeover Monday. I liked this dashboard so much that I actually tried to recreate the design the following week with a similar dataset. A great example of a clean, effective dashboard.

Satisfying the appetite for sustainable seafood by Brittany Roseneau (August 23, 2025)

Brittany’s long-form viz is one of my favorite examples of storytelling from 2025. I love the natural progression of the narrative, and the design and chart choices complement the story perfectly from start to finish.

Stock Performance by Seun Adeyemo (September 28, 2025)

I’m still impressed that Seun took the time to learn the algorithm Tableau uses to render its default tree chart. With that knowledge, he was able to build a fully custom tree diagram with rounded corners, custom labels, and beautiful animations when filters are toggled. So cool!

Pawnee Parks and Recreation by Lisa Trescott (October 4, 2025)

I’ve never seen a Tableau dashboard that feels so much like a real website. Once again, Lisa completely blows me away with her Tableau skills and delivers an incredibly well-designed exploratory dashboard that feels so unique.

Mastering Tableau Series (#17) by Rubén Martínez (November 10, 2025)

Rubén has over 20 dashboards in his “Mastering Tableau” series, and each one is chef’s kiss. They aren’t only beautifully designed, but they also include clear explanations for advanced techniques, chart types, and core fundamentals. Every time he posts a new one, I’m excited to see what he’s sharing next!

Playing with Food by Louis Yu (November 18, 2025)

No matter the topic, Louis always finds a way to tie the Iron Viz theme back to video games. This dashboard is another great example of that! I really enjoyed the interactivity and design choices throughout this dashboard and found myself clicking around all the knobs and buttons.

Nutrition, Energy Sources, and Ingredients of Dim Sum by Kevin Wee (November 21, 2025)

When Iron Viz season came around, Kevin was one of the artists I was most excited to see. After last year’s Broadway-themed qualifier submission, I was really curious to see what he would come up with this year. The design and chart choices in this dashboard are a true masterclass!

Reflection: Wins in 2025

I had some big wins and checked off some goals this year. One of those goals was to publish a blog post every month in 2025. If you are reading this, I’m so thankful for your time. It makes the whole writing experience worth it.

As I reflected on the year, a few other themes stood out:

TC25

I attended my second Tableau Conference this year in San Diego and had the opportunity to speak for the first time alongside Matt Huff. It was an incredible experience, and seeing a standing-room turnout was something I will never forget. We also led an in-person meetup for the Retail and Consumer Goods Tableau User Group with Ojoswi Basu. It was a great experience all around, and I am already looking forward to building on this momentum at TC26.

Community Involvement

2025 was the first full year of the #RetailTUG. We hosted 6 events this year with some incredible guest speakers, including one hybrid session. The user group continues to trend upward, and I am excited to keep delivering strong, relevant content in the year ahead.

Toward the end of the year, I also announced that I will be joining the #MakeoverMonday team. As a frequent participant in this project over the past few years, I am incredibly grateful for the opportunity and excited to help curate datasets each week that could use a “makeover”.

Lastly, I am proud to share that I was named both a 2025 DataFam Rising Star and a 2025 Tableau Ambassador. Both of these are community-nominated recognitions, and it means a lot to be acknowledged by a group I have looked up to for years. I plan to keep giving back in 2026!

Professional Development

I am incredibly happy with the progress I’ve made with Tableau, and a large part of that growth is thanks to Next-Level Tableau. I have been training with Andy Kriebel for the past two years and am excited to continue that journey in 2026. His mentorship has been invaluable as I’ve grown technically and expanded my network.

This year also marked a major career transition for me, as I moved from HEB to a role at Apple as a Senior Data Visualization Engineer. It has been an exciting next step, and I’m grateful for the experiences that led me here.

Goals Going Into 2026

Even though there is some well-documented psychological research suggesting that sharing your goals can actually make you less likely to achieve them (the short version being that our brains release a sense of “success” just by saying them out loud), there are still a few things I want to call out as I look ahead to 2026.

Continuing to Blog Monthly on FeizaData

I’ve found that publishing one blog post a month is a pretty healthy cadence. It gives me enough time to be thoughtful about each post while still staying consistent. I still have plenty of ideas I want to explore here and have not run out of gas yet. :)

Progressing as a Community Leader

Through blogging, creating vizzes, speaking at TC26, and continuing to lead community user groups and projects, I hope to keep growing as a community leader in the Tableau and data visualization space. More than anything, I want to stay engaged, keep learning, and help create spaces where others feel encouraged to share their work as well.

Trying Something New?

I have a tendency to sign myself up for more than I can chew (I even signed up to run a 50K in May…) At some point in 2026, I would like to try my hand at livestreaming some viz sessions. Makeover Monday feels like a natural place to experiment with this, using a timeboxed format to build something each week. It would be similar in spirit to Andy Kriebel’s old “Watch Me Viz” series on YouTube. We’ll see if I actually commit to the idea now that it’s in writing…

To wrap up the year and this post, I just want to say thank you if you’re reading this. As much as it makes me happy to write posts about topics that excite me, it means the world to know there are people on the other end that are consuming it. I hope you stick with me in 2026!

-Blake Feiza

I remember early in my Tableau journey hearing about Dynamic Zone Visibility (DZV) and thinking it must be some pretty advanced stuff.

I’m writing to prove to you it’s actually one of the easiest interactivity features in Tableau.

I’ll break the process into 3 easy steps and mention some common misconceptions along the way. If you’re already familiar with DZV, I’ll also add an advanced technique that might solve that “impossible” problem you’ve been stuck on.

DZV in 3 (Simple Steps)

1. Create a Parameter

In all DZV use cases, the first step is to create a parameter. The type doesn’t matter here, because step 2 will reference this parameter inside a calculation.

2. Create a Calculated Field

A parameter behaves like a light switch with no wiring by itself. It doesn’t control anything until we pair it with a calculation. For DZV to work, we need a calculated field that evaluates to exactly TRUE or FALSE across the entire workbook.

The key idea is that parameters always return a single value globally. That makes them perfect for DZV. Filters do not work here because they can vary row by row or sheet by sheet.

In this example, I create a simple calculated field like this:

// DZV. Show Chart
[DZV Parameter] = 'Show'

Observe that this calculation will always evaluate to either TRUE or FALSE. Also, because parameters always have one global value, this calculation’s result will always be ONLY TRUE or ONLY FALSE at any time.

Note that in this example, my [DZV Parameter] has 3 values; “Show”, “Hide”, and “Etc”. The calculation I’m using will show the chart when the parameter is “Show” and hide for all other values. We can modify the logic here in a couple ways depending on the goal:

// Only Show the Chart on "Show"
[DZV Parameter] = "Show"

// Only Hide the Chart on "Hide"
[DZV Parameter] != "Hide"

// Show the chart for a specific set of options
[DZV Parameter] IN ("Show", "Etc")

3. Edit on Dashboard

Now that our calculation from Step 2 exists, we don’t even need to add it anywhere. Tableau simply stores it in the workbook and recognizes it as a “DZV-eligible” field. We can head to our dashboard and reference it directly.

DZV is a property you can apply to any dashboard object. To modify this property, select an object, then go to Layout > Control visibility using value.

If your calculated field was set up correctly, it will appear in the DZV drop-down. If it does not appear, revisit the calculation; this is usually because the logic doesn’t resolve to either TRUE or FALSE across the entire workbook.

If everything works correctly, you’re done! You can add as many calculations as you need to cover different user experience scenarios, and you can apply the same calculation to any number of objects or dashboards.

One final note: if you are using a Boolean parameter, you can actually connect DZV directly to the parameter without creating a calculated field. This only applies to true Boolean parameter types, but it is a helpful technical shortcut to know.

Bonus Technique: When “Easy DZV” Won’t Cut It

Sometimes, it can be surprisingly difficult to create a calculation that is globally TRUE or FALSE and still meet the requirements for your DZV use case. To show what I mean, here is an example from Superstore:

Suppose I want to look at the number of yearly orders by ship mode for a selected manufacturer. The dashboard below shows the result for AT&T, and everything looks fine because there are orders in every ship mode.

When I switch my [Manufacturer Parameter] to Ativa, there are no First Class orders. This leaves an empty space in the layout where that bar would have been, and I would prefer that First Class disappear entirely so the remaining ship modes have more room.

This is where DZV becomes a bit trickier.

To control visibility for each ship mode independently, we need calculated fields (one for each ship mode) that always resolve to TRUE or FALSE across the entire workbook. These calculations need to understand whether the selected manufacturer has at least one qualifying record.

The key is using fixed LODs.

I created the following calculations (one for each of my four ship modes):

// DZV. First Class Orders?
{ COUNTD(
    IF [Manufacturer] = [Manufacturer Parameter] AND [Ship Mode] = 'First Class'
    THEN [Order ID] 
    END
  ) > 0 
}

// DZV. Same Day Orders?
{ COUNTD(
    IF [Manufacturer] = [Manufacturer Parameter] AND [Ship Mode] = 'Same Day'
    THEN [Order ID] 
    END
  ) > 0 
}

// DZV. Second Class Orders?
{ COUNTD(
    IF [Manufacturer] = [Manufacturer Parameter] AND [Ship Mode] = 'Second Class'
    THEN [Order ID] 
    END
  ) > 0 
}

// DZV. Standard Class Orders?
{ COUNTD(
    IF [Manufacturer] = [Manufacturer Parameter] AND [Ship Mode] = 'Standard Class'
    THEN [Order ID] 
    END
  ) > 0 
}

Each ship mode chart gets its own calculation that checks whether there is at least one [Order ID] matching both the manufacturer and the ship mode requirements. If there is at least one match, the calculation returns TRUE. If not, it returns FALSE.

By wrapping the logic in a FIXED LOD, the outcome becomes global and stable, which is exactly what DZV requires.

Variations of this pattern have solved several otherwise challenging layout problems for me, and I hope it helps you with yours.

For this month’s blog post, I’m excited to revisit the Trail Tips mini-series and share another set of my favorite Tableau tips. I always enjoy this type of content because it’s always those small, simple tips that end up making a huge difference in my workflow. Hopefully, one of the ten below does the same for you!

Before we begin, a special thanks to Paul Albert for contributing several of these tips following the first edition. If you have any tips of your own, feel free to share in the comments or reach out via LinkedIn!

Tip #1: Edit Default Properties on Your Fields in Tableau

There’s nothing better than inheriting a workbook full of acronyms and unfamiliar field names only the original developer could decode. Did you know Tableau gives us a way to leave field-level documentation for whoever explores that workbook next?

Right-click any field in the data pane and go to Default Properties → Comment. Here, you can notes or logic tied to the data. When someone hovers over that field, your comment will appear as a tooltip to help explain what’s going on.

As we move towards an increasingly agentic, AI-assisted future, these small acts of documentation provide semantics for both human and model-based developers.

Tip #2: Editing Default Aggregation for Measures

Tableau also lets you control the default aggregation type it applies when you drag a measure into the view. By default, Tableau assumes SUM is the appropriate aggregation.

Right-click your field and select Default Properties → Aggregation to change it. For example, setting AVG as the default for the [Discount] field makes more sense than summing those values.

Tip #3: Edit Default Fiscal Year Start for Date Fields

Here’s another awesome default property that applies specifically to date fields. By default, Tableau assumes your fiscal year runs from January to December, but that’s often not the case. Did you know you can edit the Fiscal Year Start month from the same menu?

Right-click a date field and select Default Properties → Fiscal Year Start to align your fiscal calendar correctly. Once updated, Tableau will automatically respect your fiscal year setting.

Tip #4: Using Describe to Fetch Field Values

There’s nothing worse than manually typing long string values into an IF or CASE statement in Tableau. You’re prone to typos and the task can take a pretty long time.

Right-click your field and select Describe… to open a summary window. Copy the domain of values and paste them directly into your calculation. You’ll still need to format them in your calculation, but the copy/paste approach feels much easier than typing them from scratch.

Tip #5: Quickly Select Aggregation When Dragging a Field into the View

When you drag a measure into the view, Tableau automatically applies its default aggregation. There is a nice trick to specify the aggregation while dragging the pill out.

On Mac, hold Option and drag the field into the view. On Windows, use Right-click + Drag. Tableau will pop up a small menu letting you pick from the list of aggregations before you drop the field.

Tip #6: Using Colored Tabs to Categorize Sheets and Stay Organized

As workbooks grow, keeping track of all your sheets can quickly get overwhelming. A helpful way to stay organized is by assigning colors to your sheet tabs.

Right-click a sheet tab at the bottom of the workbook and select Color. You can use consistent colors to group worksheets, dashboards, or stories with related content. I find this makes navigating complex workbooks much easier.

Tip #7: Control How Sheets Are Displayed

Did you know Tableau gives three different options to navigate your workbook? In the bottom-right corner of the workspace, you can toggle between tabs, filmstrip, or sheet sorter views. The filmstrip is great for quick thumbnail scanning, and the sheet sorter gives you a nice, visual overview of the entire workbook.

Combine this with colored tabs from Tip #6 to keep your workflow quick and organized.

Tip #8: Check/Uncheck Multiple Items at Once

When working with dropdown filters or parameters, you don’t need to click each value one by one.

Select the first item, hold Shift, and click the last item in the list to highlight a range. Then, either click one checkbox or press Spacebar to check or uncheck all the options at once.

Tip #9: Remove the Grey Highlight from a Dropdown

Have you ever battled with a filter or parameter dropdown because you wanted users to start with a clean, fresh, untouched list? The grey highlight can make it look like a choice has already been made.

To remove it, hold CMD (Mac) or CTRL (Windows) and click the highlighted item. The selection will clear and leave your dropdown clean.

Tip #10: Rename a Field by Clicking and Holding

Instead of right-clicking a field and selecting Rename, try just clicking and holding on the field name. After a moment, Tableau will let you edit it directly.

I actually discovered this one by accident and now it’s my preferred way to rename fields.

And that wraps up Tableau Trail Tips #2. I hope that at least one of these time-savers can find its way into your personal Tableau workflow. Also, let me know your favorite Tableau tricks in the comments! I’d love to hear it, and/or feature it in the next post.

Happy Vizzing!

If you’ve been around the DataFam for any length of time, you’ve probably heard of Makeover Monday. It’s a weekly challenge that provides a new dataset every week and invites you to reimagine the story it tells. For the last 2 years, I’ve used this community project as a commitment device to hold me accountable to practicing Tableau. Over time, those quick projects start to stack up into a portfolio of ideas I can share or revisit myself later.

For a recent challenge (2025 Week 37), the dataset focused on AI’s impact on the job market. The topic felt immediately relevant, and I was excited to boot up Tableau and dig into the data.

That excitement didn’t last long, though. While initially exploring the records, a few things stuck out to me.

• An economist with an associate’s degree earning $150K? In the retail industry? Apparently, I picked the wrong career path…
• A dentist categorized in the entertainment industry? That sounds like an Impractical Jokers bit.
• I’m still not sure what kind of fitness manager belongs in the transportation industry.

The more I explored, the harder it was to trust any patterns I saw. I even went back to the Kaggle dataset to see what the author (and others) had to say.

…I think we might have a slightly different perspective on how far from “factual” a synthetic dataset should deviate. Nevertheless, I was stuck. I didn’t want to create and share something misleading, especially with a topic I felt passionate about.

What if I used this dataset as a starting point and rebuilt the fields myself? Not by hand, of course, but with help from our good pal AI.

Rebuilding the Dataset with Databricks Community

A few weeks ago, I heard some updates had been made to Databricks’ Free Edition and offered daily free compute to users. I knew they had some AI features baked into their ecosystem, and I’ve been wanting to give them a shot. This project became the perfect opportunity. Here’s how I got started:

Importing the Dataset

• On the left side of the Databricks workspace, go to Data Ingestion > Create or modify table.

• Drag and drop your CSV (in this case, the Makeover Monday data). I created a schema called tableau and named my table ai_job_trends.

Column renaming is an option here, but I left that for later. The goal was just to get the data staged and ready.

Setting Up the Notebook

I created a new notebook and ran my standard boilerplate imports.

# Set up Spark and Python Environment
from pyspark.sql.functions import *
from pyspark.sql.types import *
from pyspark.sql import Window
from datetime import date, datetime, timedelta

For context, I tend to work more regularly in PySpark, so this blog post mixes PySpark and SQL quite a bit. It’s not the only way to transform your data, but this rhythm helps me move quickly.

To create the foundation for my new dataset, I first wanted to know how many job titles were actually in the data.

After removing duplicates, I landed on 639 unique job titles (compared to the nearly 30,000 records in the original dataset). This single-column dataframe became the spine for my AI prompts to follow.

Using AI to Rebuild the Metadata

The goal was to generate accurate fields for each job title, including the correct industry, the required education level, and other context from the original dataset. I wanted to turn the simple list of jobs into a structured table that conceptually matched the original Kaggle data, but told the accurate story that we were missing.

With the isolated 639 job titles, it was time to explore Databricks’ ai_query() function. After a few iterations, I found an approach that would generate all the fields I wanted (i.e., industry, education, AI impact level) in a single column. The structured output would run quickly and yield data that I could easily split in a subsequent step.

The final prompt I landed on consists of a few key learnings and decisions I made along the way:

• Use numbered/bulleted instructions: LLMs tend to perform better with structured steps, so I used them wherever possible.
• Provide strict formatting rules and examples: This reduced noise in the responses and ensured results were predictable and usable.
• Separate attributes with pipes (|): Condensing all the attributes into a single pipe-delimited column significantly improved runtime compared to running a separate ai_query() for each attribute.
• Constrain industry categories: Confining “Industry” to a fixed set of eight kept categories consistent, but some jobs stretched those boundaries. There’s no perfect approach here, but I opted to stay close to the original dataset.

Here’s the query (including the prompt) that I used to generate my new data:

%sql
SELECT 
    job, 
    ai_query(
        "databricks-meta-llama-3-3-70b-instruct",
        CONCAT(
            "You are a structured data generator.
            Given a job title in the United States, return exactly 6 attributes separated by the pipe character (|). 
            The output must contain no explanations, labels, or extra words — only the 6 attributes in order. 
            
            Attributes (always return in this order):
            1. Industry → choose ONE from {Retail, Education, Manufacturing, IT, Finance, Transportation, Entertainment, Healthcare}.
            2. Job Status → choose ONE from {Increasing, Decreasing}. Base this on whether demand is rising or falling due to AI expansion.
            3. AI Impact Level → choose ONE from {High, Medium, Low}. Reflect the degree of AI disruption on this role.
            4. Median Salary (numeric USD, no symbols or commas, e.g., 55000).
            5. Experience Required (integer years, e.g., 5).
            6. Required Education → choose ONE from {High School, Associate, Bachelor Degree, Master Degree, PhD}.

            Formatting rules:
            - Separate attributes ONLY with '|'.
            - Do NOT include units, words like 'USD' or 'years'.
            - Do NOT add any commentary, explanation, or text before/after the output.
            - Output must be exactly one line.

            Example valid output:
            Entertainment|Increasing|Medium|55000|5|Bachelor Degree

            Job Title: ",
            CAST(`job` AS STRING)
        )
    ) AS ai_metadata
FROM jobs

And the code I used to split the pipe-delimited output column into something easier to work with:

improved_df = (
    _sqldf
    .withColumn('industry', split(col('ai_metadata'), '\|').getItem(0))
    .withColumn('job_status', split(col('ai_metadata'), '\|').getItem(1))
    .withColumn('ai_impact_level', split(col('ai_metadata'), '\|').getItem(2))
    .withColumn('median_salary', split(col('ai_metadata'), '\|').getItem(3))
    .withColumn('experience_required', split(col('ai_metadata'), '\|').getItem(4))
    .withColumn('required_education', split(col('ai_metadata'), '\|').getItem(5))
    .drop('ai_metadata')
)

This output was solid, but I didn’t want to stop here. How could I be so sure that these new records were accurate? I couldn’t trust the original synthetic data. Why should I blindly trust this newly generated table?

To strengthen confidence, I created a second ai_query() to serve as a validation agent. This step checked every row’s results and flagged any anomalies based on rules I outlined. There are a few things I found especially helpful when writing the validation prompt:

• Forcing a simple output: Being explicit about returning exactly one character (“1” or “0”) ensured the output was easy to use.
• General validation rules: These caught obvious issues like invalid categories or bad data type formatting.
• Contextual Rules: Grounding the model with real-world expectations (e.g., a dentist belonging in Healthcare, not Entertainment) helped surface edge cases that might otherwise slip through (see Validation Rules #7 below).

%sql
SELECT
  ai_query(
    "databricks-meta-llama-3-3-70b-instruct",
    CONCAT(
      "You are a validator for structured US job metadata. Input is one record with fields in this order, pipe-delimited: 
      
      Job Title | Industry | Job Status | AI Impact Level | Median Salary | Experience Years | Required Education. 
      
      Return exactly one character: '1' if the record is plausible and consistent, or '0' if it is not. No explanations. No spaces. No extra text. One character only.
      
      Validation rules (if any fail, return '0'):
        1) Industry must be in Retail, Education, Manufacturing, IT, Finance, Transportation, Entertainment, or Healthcare. 
        2) Job Status must be in Increasing or Decreasing. 
        3) AI Impact Level must be in High, Medium, or Low. 
        4) Median Salary must be an integer only and directionally plausible for the job. 
        5) Experience Years must be an integer only.
        6) Required Education must be in High School, Associate, Bachelor Degree, Master Degree, or PhD. 
        7) Context checks: 
          a) Education cannot undershoot obvious professional requirements. Examples: 
            - Dentist, Physician, Pharmacist, Psychologist require at least Master Degree or PhD. 
            - Lawyer requires at least Bachelor Degree. 
            - Registered Nurse requires at least Associate. 
            - Engineer, Accountant, Auditor require at least Bachelor Degree. 
          b) Industry must be a reasonable fit for the job. Example: Dentist must be in Healthcare, not Entertainment. 
          c) Salary must be plausible for the seniority and education level. Example: Economist with Associate and salary over 100000 is implausible. 
          d) If Required Education is Associate and Median Salary is greater than 100000, return '0' unless the job is a known high-wage exception such as Pilot, Air Traffic Controller, Elevator Mechanic, Power Lineworker, or Radiation Therapist. 
          e) Senior titles (Senior, Lead, Principal, Director, VP, Chief) normally require at least 3 years of experience. → Junior or Intern titles normally require 0 to 2 years of experience and salaries should not be executive-level. 
          f) No field may be empty or null. 
          g) If the job title is extremely ambiguous or contradicts other fields, return '0'. → If all rules pass, return '1'. 
          
      Record: ",
      CAST(job AS STRING), "|",
      CAST(industry AS STRING), "|",
      CAST(job_status AS STRING), "|",
      CAST(ai_impact_level AS STRING), "|",
      CAST(median_salary AS STRING), "|",
      CAST(experience_required AS STRING), "|",
      CAST(required_education AS STRING)
    )
  ) AS qa_flag,
  *
FROM improved_df

It’s worth noting that I iterated quite a bit on the two prompts above. I actually asked ChatGPT to act as an expert prompt engineer, reviewing my “junior” prompts and suggesting improvements. That feedback loop made these prompts significantly more robust.

The outcome of this QA prompt: 94% of the rows passed our test. It’s not a perfect 100%, but from a practical standpoint, I wouldn’t trust a human to be 100% accurate in labeling hundreds of jobs either.

I took the ~5% of jobs that failed our QA test and filtered them out in Tableau. The remaining job records felt much more trustworthy and ready to be visualized.

I aggregated the jobs by industry and AI impact level (low/medium/high). Now I had a clear insight that felt grounded, rather than questionable.

Wrapping Up

This Makeover Monday dataset wasn’t what I expected, but I’m happy that it pushed me into a new workflow. Databricks Community offered me a way to both reassemble a messy dataset and rethink my approach to validation.

There are plenty of ways to iterate and refine this process, but I found it encouraging that AI can serve as a builder and validator inside a single notebook. I’d love to hear how you would push this further. What would you try? What would you change?

Thank you for reading, I’ll see you back here next month with another project!

Making Over “Makeover Monday” was originally published in DataAI on Medium, where people are continuing the conversation by highlighting and responding to this story.

I recently published a Tableau dashboard visualizing the different sports seasons throughout the year. I have always found myself more passionate about data art, and this visualization showcased that. However, I can’t take full credit for the idea and topic. Throughout this post, I’ll walk you through the inspiration for this dashboard, the data preparation process, and the actual build inside Tableau. Hopefully, you’ll learn something applicable to your workflow or be inspired in your own way.

In this post, I’ve referenced several resources along the way. You can find them all here:

• SportsBall Inspiration Post
• Published Viz on Tableau Public
• Initial Data from ChatGPT and Manual Tweaking
• Prep Flow
• Data Output from Prep Flow

Source of Inspiration

I recently came across an awesome account on TikTok called SportsBall, which features hand-drawn data visualizations and storytelling. The narration adds an engaging layer to the content as the drawing slowly comes to life. I’ve been obsessed with his content style, and this video, in particular, really caught my eye:

While I’ve seen (and built) many radial charts in the past, I’d never encountered one that collapses on itself like this one does. Additionally, combining many polygon marks in the middle and lines on the outside makes this visualization a great candidate for map layers. I had to try to build this chart in Tableau.

Wrangling & Preparing the Data

Starting with AI

I knew from the start that I wanted 365 rows of data (one for each day of the year) and one column per sports league indicating whether the team is in-season, in the playoffs, or off at that time. While I could’ve scavenged the internet to find the dates I needed and built this in Excel, I also love a good generative AI use case. I prompted ChatGPT for the expected start and end dates for the 2025–26 season for the 14 leagues (NFL, NBA, MLB, NHL, MLS, NWSL, WNBA, PWHL, PGA, ATP/WTA, NASCAR, F1, CFB, and NCAAB). I also requested the dates for the golf and tennis majors/championships.

An unexpected challenge arose with seasons that ran through the end of the calendar year, like the NFL (season runs from September to February). ChatGPT struggled with the continuity between the years because I was trying to return only 365 rows.

I got 90% of the way there with AI, and the data was small enough that I just made the final adjustments to the records by hand. Once the data was pulled into a table, I was ready to pull it into Tableau Prep to continue this pre-Tableau data journey.

Tableau Prep

I’ll spare you from walking through every step of the flow, but you can find the whole flow, ready to download, here. In a nutshell, these were the transformation steps I performed in Prep to finalize the data construction:

1. Pivoted all the leagues to one column called “League”.

2. Based on the date column in the CSV, a “Day of Year” calculation (numbers 1–365) and an “Angle” calculation based on the day of the year were created to help with the trigonometry in Tableau.

3. To indicate the start and end of every season, especially when the season runs through December 31, a series of calculations/steps was required:

• Using DATEADD() functions, the previous value and upcoming value for every date per league were calculated.
• Based on these previous and upcoming values, created LOD calculations to indicate the start date and end date of every league (e.g., the start date for a league should have a current value of “Regular” and a previous value of “Off”; the end date for a league should have a current value of “Regular” or “Playoffs” and a next value of “Off”).

4. Based on every league’s start/end dates, created a Point ID column, where one starts on the first day of the season.

5. The target visualization requires polygon marks rather than lines for the five primary leagues in the middle (NFL, NBA, MLB, NHL, MLS). Therefore, I needed to densify my data for these leagues by two so we have enough points to complete the whole polygon (outside layer of points and inside layer of points).

Building in Tableau

Heads up, as we get into this section, if you’re trying to replicate this process yourself, I’d recommend downloading the workbook from Tableau Public and dissecting it for your use case. I’ll explain the calculations conceptually here and provide a few examples to model afterward. Still, nearly 60 map layer calculations in the sheet would be very messy to copy/paste here.

The “Inner Ring” Polygons

Starting with the regular season, we have five “<League> Makepoint” calculations to build the lighter-colored polygons in the middle. I’ll use the NBA league calculation as an example:

// NBA Makepoint
IF 
    [League] = 'NBA' AND 
    NOT ISNULL([Point ID])
THEN
    IF [Point ID] > [Max Point ID per League] 
    THEN
        MAKEPOINT(
        SIN([Angle]) * (4-[NFL Offseason Deduction]+[pInnerPadding]),
        COS([Angle]) * (4-[NFL Offseason Deduction]+[pInnerPadding])
        )
    ELSE 
        MAKEPOINT(
        SIN([Angle]) * (5-[NFL Offseason Deduction]),
        COS([Angle]) * (5-[NFL Offseason Deduction])
        )
    END
END

Conceptually, here’s what this calculation is doing:

• Filtering to only the NBA league and removing any null Point IDs (representing the off-season).
• Because a polygon needs points on the shape's inner and outer edges, we use [Max Point ID per League] to determine when we switch from the outer edge to the inner edge. If you squint, everything else is just MAKEPOINT( SIN(Angle), COS(Angle) ), multiplied by a scalar to determine the radius.
• For the radius value, I’m using a parameter for padding and subtracting a radius value of 1 if a more central sport is in the off-season. This creates the collapsing effect. Since the only sport more central than the NBA is the NFL, I’m only subtracting one off-season deduction. You would see an NFL and NBA subtraction if this were the MLB. Each off-season deduction looks like:

// NFL Offseason Deduction
{ FIXED [DayofYear]: MAX(
INT([League] = 'NFL' AND [Value] = 'Off'))}

…giving a value of 1 or 0 that we deduct from the radius.

There are also five “<League> Playoffs Makepoint” calculations. These will follow the same behavior as the previous calculations, with one additional filter: Value = “Playoffs”:

// NBA Playoffs Makepoint
IF 
    [League] = 'NBA' AND 
    NOT ISNULL([Point ID]) AND
    [Value] = 'Playoffs'
THEN
    IF [Point ID] > [Max Point ID per League] 
    THEN
        MAKEPOINT(
        SIN([Angle]) * (4-[NFL Offseason Deduction]+[pInnerPadding]),
        COS([Angle]) * (4-[NFL Offseason Deduction]+[pInnerPadding])
        )
    ELSE 
        MAKEPOINT(
        SIN([Angle]) * (5-[NFL Offseason Deduction]),
        COS([Angle]) * (5-[NFL Offseason Deduction])
        )
    END
END

Add them to the sheet independently as new map layers for all ten of these calculations. Change the mark type to Polygon, and add Point ID to Path.

The “Outer Ring” Lines

We follow a similar pattern for each of the women’s leagues, golf, tennis, racing, and college sports, but the calculations are a bit simpler since we aren’t making polygons; just single lines. As an example, here is the calculation for the National Women’s Soccer League Makepoint:

// NWSL Makepoint
IF [League] = 'NWSL' AND NOT ISNULL([Point ID])
THEN
MAKEPOINT(
9 * SIN([Angle]),
9 * COS([Angle])
)
END

Conceptually, we are filtering to the correct league and non-null Point IDs. Then, we create our MAKEPOINT() calculation with SIN/COS of an angle, multiplied by a radius.

The pattern continues with the playoffs MAKEPOINT(), again adding a filter; Value = “Playoffs”:

// NWSL Playoffs Makepoint
IF [League] = 'NWSL' AND NOT ISNULL([Point ID]) AND [Value] = 'Playoffs'
THEN
MAKEPOINT(
9 * SIN([Angle]),
9 * COS([Angle])
)
END

The map layers for these 18 calculated fields are each line mark type, with Point ID on path. I adjusted the size of the playoff lines to be slightly larger than the regular season.

Dots for Majors and Championships

I opted to make a unique calculation for every point on the golf and tennis rings, mainly because there are only eight that I’m including, and the calculation volume was manageable. Here’s an example of what these calculations look like for the Masters beginning:

// (4/10) The Masters Begins Makepoint
IF [League] = 'PGA' AND [Date] = DATE('2025-04-10')
THEN
MAKEPOINT(
10.5 * SIN([Angle]),
10.5 * COS([Angle])
)
END

For these map layers, the mark type is just a circle, and no path shelf is required.

Month Tick Lines & Labels

To create the dashed lines running from the circle's center to the outside, I use MAKEPOINT() calculations with two Point ID values, 1 and 2 (the start and the end of each line). For February, the calculation looks like this:

// 02. Feb Tick Mark
// Inside of RADIANS(): 
// [Days before 1st of the Month] / [Days in a Year] * [Degrees in a Circle]
MAKEPOINT(
CASE [Point ID]
WHEN 1 THEN SIN(RADIANS(31/365*360)) * 2
WHEN 2 THEN SIN(RADIANS(31/365*360)) * 14
END
,
CASE [Point ID]
WHEN 1 THEN COS(RADIANS(31/365*360)) * 2
WHEN 2 THEN COS(RADIANS(31/365*360)) * 14
END
)

As noted in the calculation documentation, we are calculating the angle in degrees for the line based on the number of days into the year that we are plotting. That degree value is then converted to radians and used in our SIN/COS functions. With some testing, I decided that radius values of 2 and 14 gave me the line length I sought.

This took a bit of fiddling for the line labels in the center. I finally aligned on adding half the number of days into each month by the day of the year that the month starts. The radius that felt right for this label was 2.7.

Here’s an example for February, where 31 days have passed in the year by February 1st, and 59 days will mark the end of February:

// 02. Feb Label
MAKEPOINT(
SIN(RADIANS(
    (31-((31-59)/2))/365*360
    )) * 2.7
,
COS(RADIANS(
    (31-((31-59)/2))/365*360
    )) * 2.7
)

I add these map layers as a shape (default), lower the opacity to 0%, and manually type a single letter representing the month abbreviation.

With all of that, and quite a bit of formatting (left as an exercise for the reader), we end up with the final product for the visualization all in a single Tableau worksheet:

Wrapping Things Up with Figma

Other than some quick sheets to create custom legends (just square marks and League groups on the Rows shelf), the only thing left to build was a background image in Figma.

Based on some inspiration from Nike’s motivational ad campaigns, I opted for a greyscale background with white text to maximize the color contrast for the chart elements.

I found a copyright-free image of a chain-link fence, removed the saturation, and added some layer blur to reduce distraction from the chart. I added a dark circle behind the chart to increase the contrast further. Besides the image, title text, and dark circle, every element on the dashboard was created natively in Tableau.

Importing this image, adding some text objects, and including our charts gives us our final product:

In all honesty, this was the most fun project that I saw through from start to finish. Is it perfect? Nope. Does it represent what I saw in my head before I started? Yes, it does.

If you made it this far, I hope you’ve learned something you can apply to your work. Let me know your thoughts on this dashboard, and share feedback on this write-up. Was it useful? Any insight helps inform what I’ll write about next. Until then, Happy Vizzing! 👋

Behind the Build: Sports Radial Calendar was originally published in DataAI on Medium, where people are continuing the conversation by highlighting and responding to this story.

For any Tableau developer, tooltips are one of the easiest features to forget about when building a dashboard. For many dashboard users, tooltips are one of the first forms of interactivity discovered. A bit ironic, no? Tooltips that provide a good UX are effortless to use, but getting there requires intention from the developer.

In this post, I’ve compiled five core tips to help you enhance your Tableau dashboards with effective tooltips and keep users coming back.

#1: Use Tooltips with Intention, or Don’t Use Them at All

What Good Looks Like

While researching this blog post, I came across Beth Kairys’ post describing what makes a good tooltip. Her perspective resonated with me, so I will echo the same advice here.

A good tooltip should accomplish at least one of three goals for the user:

• Provide Clarity
• Offer Additional Context
• Invite Additional Exploration

Tooltips that provide clarity give the user additional information beyond the dashboard itself. Examples include information about the data (source, disclaimers, notes), instructions on interpreting the chart, or citing the inspiration for your analysis.

The above dashboard by Shreya Arya takes top-performing video games and provides additional context about each game through the tooltip.

Tooltips that offer additional context supply the user with more data points supporting what is in the view. Examples include further mark context (i.e., rank, percent change, percent of total) or introducing more granularity (i.e., drill-down, percentage breakout, different visuals to further understanding).

This tooltip in a dashboard by Chimdi Nwosu provides additional data points like rank and growth trends that are not initially accessible in the dashboard.

Tooltips that invite additional exploration offer the user ways to go beyond the dashboard. The tooltip may yield an option to navigate to another dashboard or leverage a URL action, taking the user to the data source or reference to learn more.

At the bottom of John Johansson’s tooltip, a URL action is provided to navigate to the data source for any user seeking additional information.

Hiding the Junk

After discussing the intent behind an effective tooltip, it’s time to air the dirty laundry — there are way too many tooltips that fail to accomplish anything (I’m guilty of this myself). However, I feel this is less of the developer's fault and more of a result of Tableau’s default behavior with tooltips. There are two simple ways to add quick polish to a dashboard once it’s been built.

Uncheck “Include in Tooltip” on the Fields you want to hide

By default, Tableau will add the data for every pill you add to your sheet in your tooltip. While this might be helpful to the developer when building the dashboard, there are a lot of techniques used under the hood of Tableau that a user does not care about. We can right-click these pills and uncheck “Include in Tooltip”. The row will disappear from the tooltip.

Note that this technique only works if you haven’t manually edited your tooltip. If you’d like to revert, enter the tooltip box and click the “Reset” button in the bottom left. I always recommend starting with this technique and polishing the tooltip manually at the end.

Disable tooltips on sheets where there is no additional context to reveal

Going back to our best practices, there will usually be some sheets on a dashboard that fail to accomplish any of the objectives mentioned above (BAN sheets can fall victim to this). This is one of the first things I look for when reviewing a dashboard. Don’t overthink it, turn off the tooltips for these sheets. In the Tooltip card, you can either uncheck the “Show tooltips” option or delete all the text inside the textbox.

#2: Formatting Your Tooltip in the Edit Menu

Over the last couple years, I’ve gradually learned how to format the text and components inside a tooltip’s edit menu. Here is a summary of the most important takeaways.

Use Tabs Instead of Spaces to Align Text

By breaking text with a tab instead of a space, you can align everything to the right of the tab across lines. This is how Tableau’s default tooltip behaves, and is why we see all our values aligned to the right of the field names.

You can add more than one tab as well, increasing the spacing between the end of the text on the left and the start on the right. Use the alignment ruler at the top of the tooltip textbox if you can’t get the spacing right with one or many tabs. Moving this ruler left or right will increase or decrease each tab's size.

Responsive Tooltips vs. “On Hover”

By default, Tableau will make all tooltips responsive. This means the end user will see a tooltip when their mouse lands on top of a mark. This can provide a clean, responsive UX, assuming there aren’t too many marks in the view. With a more computationally intense dashboard, this responsiveness can cause lag for the user.

Changing the drop-down to “On Hover” forces the user to be slightly more intentional when a tooltip is desired, but saves their CPU from over-exertion.

Include Command Buttons

Another default setting enabled by Tableau is “Include command buttons.” This feature allows the user to manually adjust the number of marks in the view (keep only/exclude values). While sometimes a helpful tool, this poses a significant risk for users who do not understand what this feature does. In the GIF below, observe how we can change the apparent story for 2021 Q4 by removing the marks for Furniture and Office Supplies.

Also bundled into this setting is the ability for the end user to view the sheet’s underlying data. While sometimes helpful for a quick, ad-hoc data pull, this approach will often surface all the fields in the sheet’s backend (including ones that might not be intended for your user).

Allow Selection by Category

I’m pretty confident that 90% of people do not know this setting exists. Did you know that if you select a mark on your sheet and click on a dimensional value, you can select all the marks from the same category? This is also a toggle in the tooltip menu that we can deselect. See the GIF below for a visual example.

#3: Conditional Formatting in a Tooltip

Have you ever tried to color-encode a value in a sheet’s tooltip? I bet you’ve encountered some difficulties configuring the conditional formatting if you have. Luckily, there is an approach to solve this problem using a couple of calculated fields.

For example, I’d like to display profit for a given quarter/category in my tooltip. I want the value to be blue if the profit exceeds zero. If the value is negative (or zero), I’d like the value to be red. We can create the following calculations:

// Tooltip: Profit is Positive
IIF(SUM([Profit]) > 0, SUM([Profit]), NULL)

// Tooltip: Profit is Negative
IIF(SUM([Profit]) <= 0, SUM([Profit]), NULL)

These two calculated fields will never display SUM(Profit) simultaneously, so we can add them both to the tooltip and color them both independently.

This approach can benefit year-over-year calculations and increase complexity by adding more calculated fields.

#4: Understanding Viz-in-Tooltips

Viz-in-tooltips (VIT) allow developers to embed another workbook sheet into the tooltip. This feature can be a great way to offer additional context to the chart or drill-down capabilities to benefit the user’s dashboard experience.

Decomposing a Viz-in-Tooltip (VIT)

Four components combine to create a viz-in-tooltip: Sheet Name, Max Height, Max Width, and Filter.

• The Sheet Name tells Tableau which sheet to render inside your tooltip.
• If you want a taller chart, reduce your Max Width or increase your Max Height.
• If you want a wider chart, increase your Max Width or reduce your Max Height.
• Filter defaults to “All Fields, " meaning every shared dimension between the primary and tooltip sheets.

Viz-in-Tooltip Example: Bar Charts Inside Line Chart Tooltip

I’ve created two charts inside my Tableau workbook: one line chart showing quarterly sales by category, and one bar chart showing quarterly sales by category.

On the first sheet, edit the tooltip. Using the toolbar, select Insert → Sheets → Sheet 2. By default, our tooltip will show a single bar (for the quarter and category we’re hovering over).

To show all category bars for the mark’s Quarter, we need to edit the Filter. Since we don’t want to filter to the Category (only the Quarter), we can replace <All Fields> with <Quarter>. Now we see three bars in the tooltip, one for each Category for the Quarter we’re looking at.

As mentioned above, viz-in-tooltips can only filter fields shared between the primary and VIT sheets. Observe how the tooltip behaves if we add Segment to our VIT sheet. Even with our filter set to <All Fields>, we still see all three segments in the tooltip because it is not a shared field (so Tableau cannot filter on it).

Adding Images to Tooltips

If you can build it on a sheet, you can put it in a tooltip — that includes images too! I first learned this technique using custom shapes from my Tableau repository, but that requires a little more prep than this approach, I learned from Jeff Shaffer: background maps!

• Add 1 to Columns and 1 to Dimensions
• Turn your mark opacity to 0%
• Go to Map > Background Images > Select your Data Source.
• Select “Add Image”, find your image, and specify X and Y Ranges (both 0 to 2)
• On your sheet, uncheck the show header for your axes and turn off the axis rulers.

Add this sheet to your tooltip and configure your max height/width — pretty cool!

If using Image Role properties to pull in an image from a URL path, you can configure the sheet like you would a bar chart. The viz-in-tooltip filters will allow you to pull a single image in from a sheet with all the images.

Creating Divider Lines in Tooltips

This is another tip I inherited from Jeff Shaffer. We can also use a VIT to create nice, thick divider lines within a tooltip. Create a new blank sheet, and go to your row divider lines. Customize your divider here.

Now add this sheet to your tooltip with maxheight=9 and voila! You can use the same sheet as often as you’d like by copying/pasting.

#5. Editing Tooltips From the Dashboard

This final nugget is a small one that I picked up from Lisa Trescott’s presentation at TC24. Since, commonly, tooltips are one of the final touches on a dashboard, I find this tip particularly valuable. Instead of navigating to every sheet one by one to configure your tooltips, you can edit them directly from the dashboard page.

While on your dashboard, click on the sheet with the tooltip you’d like to edit. Use the top navigation bar to select Worksheet → Tooltip. Surprise! We’re greeted by our friendly edit tooltip menu, available directly from the dashboard screen. 🙂

On Windows, a shortcut is Alt + W + O (Worksheet → TOoltip).

Great Additional Resources

While we’ve reached the end of the content I gathered for this blog post, there is always more to test and explore with Tableau. Tooltips are no exception. If you’re interested in reading more, here are some great resources I’d recommend checking out:

• Dynamic Viz-in-Tooltip (Chart Swap) — Angus Eady
• Organizing Multiple Charts in a Tooltip — Angus Eady
• On/Off Tooltip Toggles — Angus Eady
• Formatting Tooltip Background colors — Angus Eady
• How to Ensure Your Tooltip Adds Value — Beth Kairys
• Tooltips From a UX Perspective — Tim Ngwena
• 10 Tips for Viz-in-Tooltips — Jeff Shaffer
• Another 10 Tips for Viz-in-Tooltips — Jeff Shaffer

As always, thank you for reading this blog post. Leave a comment and a clap if you learned something new (I read them all, and it’s nice to know someone is out there). See you next month! 👋

Tableau Tool-“Tips” was originally published in DataAI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Initial Inspiration

For a recent Makeover Monday challenge, I used map layers to create stripes on my bar chart to represent battery charge for a work energy-related dataset.

With several people interested in using the technique themselves, I decided it would be worth creating a tutorial for the approach. To keep this tutorial easy to follow, I’ll be using the Superstore dataset instead.

Calculations Used

For copy/paste convenience, I’ll list all of the calculations here before explaining their purpose and applications below:

// Normalized Sales per Region
{ FIXED [Region]: SUM([Sales])}
 / 
{ MAX({ FIXED [Region]: SUM([Sales]) }) }


// Total Sales Bars
MAKEPOINT(
CASE [Point ID]
WHEN 1 THEN 0
WHEN 2 THEN 1
WHEN 3 THEN 1
WHEN 4 THEN 0
WHEN 5 THEN 0
END
,
CASE [Point ID]
WHEN 1 THEN 0
WHEN 2 THEN 0
WHEN 3 THEN [Normalized Sales per Region]
WHEN 4 THEN [Normalized Sales per Region]
WHEN 5 THEN 0
END
)


// Dummy Map Layer
MAKEPOINT(0,0)


// Y-Value
// Using Modulo functions to handle all 4 corners of each stripe
IF [Point ID] % 4 = 2
THEN 1
ELSEIF [Point ID] % 4 = 3
THEN 1
ELSEIF [Point ID] % 4 = 1
THEN 0
ELSEIF [Point ID] % 4 = 0
THEN 0
END


// X-Value
// Using Modulo functions to handle all 4 corners of each stripe
IF [Point ID] = 1
THEN 0
ELSEIF [Point ID] > [pSlashes]*4
THEN NULL
ELSEIF ([Point ID] - 2) % 4 = 0
THEN (2 * FLOOR(([Point ID] - 2) / 4) + 1)/[pSlashes]/2
ELSEIF ([Point ID] - 2) % 4 = 2
THEN (2 * FLOOR(([Point ID] - 2) / 4) + 1)/[pSlashes]/2
ELSEIF ([Point ID] - 2) % 4 = 1
THEN (2 * FLOOR(([Point ID] - 2) / 4) + 2)/[pSlashes]/2
ELSEIF ([Point ID] - 2) % 4 = 3
THEN (2 * FLOOR(([Point ID] - 2) / 4) + 2)/[pSlashes]/2
END


// Striped Bars
MAKEPOINT([Y-Value], [X-Value])


// Bar Label
MAKEPOINT(0.5, [Normalized Sales per Region])

Without further ado, let’s begin!

Densify your Data

As with most map layers techniques, we start by densifying our data. I will join to a dataset with a single column, [Point ID], with values ranging from 1 to 1000. You can create this single-column dataset in Excel yourself, or download it here.

By creating a relationship calculation for both sides of the equation, I input 1 into both sides (1=1). Since 1 will always equal 1, Tableau is able to connect all 1000 points to every row in the Superstore dataset. This will be useful when we build our map layers with points and coordinates.

Creating the Total Sales Bars

Calculation: Normalized Sales per Region

The first step will be to normalize our sales value for every region, to get values between 0 and 1 for each region’s sales.

This normalization step removes any issues related to the max and min values on a map for latitude and longitude. It also makes subsequent calculations significantly easier when adding the striped map layer.

Calculation: Total Sales Bars

Now that we have our data densified and our sales normalized, we are ready to start building our map layers. We will use our [Point ID] values (specifically Point IDs 1–5) to create each of our base rectangles. The following diagram should help you understand how we will connect our points to create a rectangle.

Note that Point IDs 1 and 5 should always have the same position to complete the shape.

A less intuitive attribute of the MAKEPOINT() function is that when thinking in an X, Y coordinate plane, we actually list our Y-value first. This is likely because Tableau users are primarily using Latitude and Longitude values in this function, but it always helps me remember this pattern by thinking MAKEPOINT( [Rise], [Run] ).

With those two diagrams in mind, here is our calculated field for our [Total Sales Bars].

Double-click the [Total Sales Bars] calculation to add it to our sheet as our first map layer.

• Change the Mark Type to Line.
• Add [Point ID] to Path.

Things look weird because we’re on a map, zoomed in really close off the west coast of Africa. In order to move to an X, Y plane, we need at least two map layers in the view. We can add a [Dummy Map Layer] for now.

Drag [Dummy Map Layer] to the top left corner of the view to add a marks layer, giving us two map layers on the pane.

Now, go to the top control bar and select Map > Background Maps > None. This gives us our first rectangle, sitting within a coordinate plane in the view.

If we add [Region] to Rows and change our fit from Standard to Entire View, we can start to see the skeleton of our chart.

Creating the Striped Map Layer

Parameter: pSlashes

Because I enjoy controlling the number of slashes in each bar, I like to create a parameter to gain this control. Whether exposing the parameter to the end user or not, I still find it useful to easily manipulate the look of the bars with a parameter. A good default value for this parameter is 5.

Calculations: Y-Value, X-Value, and Striped Bars

Next up, we will make our [Striped Bars] map layer. Because these calculations can be a bit complicated, I’ve broken them into [X-Value] and [Y-Value] sub-calculations.

To illustrate the goal, we are using points in groups of 4 to create each individual stripe going through the bar. Once we reach the end of our final stripe (Point 12), we use one more point (13) to take us back to the starting point. If we turn this layer into a Polygon mark type, this will fill in each of the sections to give us the desired “stripe” effect.

To accomplish our goal, we can use the modulo operator (%). Modulo enables us to return the remainder for every value of [Point ID] divided by 4.

For example, 8 % 4 = 0, because 8 divided by 4 returns 2, with a remainder of 0.

Similarly, 9 % 4 = 1, because 9 divided by 4 returns 2, with a remainder of 1.

Combining this operator with the MAKEPOINT() logic above, we have the following calculations:

We can put these two sub-calculations inside a MAKEPOINT() function to create the final map layer.

Now we can add our [Striped Bars] as a Marks Layer.

• Change the Mark Type to Polygon.
• Add [Point ID] to Path.

We can also remove our [Dummy Map Layer] from the view now that we have 2 other layers added.

Cleaning Up the View

We’re almost there.

Drag [Total Sales Bars] onto the view again to add a second Marks Layer with the same calculation.

• Change the Mark Type to Polygon.
• Add [Point ID] to Path.

Re-order the three marks layers so that we have, from top to bottom:

1. Total Sales Bars (Line Mark)
2. Striped Bars (Polygon Mark)
3. Total Sales Bars (Polygon Mark)

Change the Mark Color of Striped Bars to White.

For some additional formatting:

• Increase the Mark Size of Total Sales Bars (Line Mark).
• Add [Region] to Color for both our Total Sales Bars layers.
• Edit your [pSlashes] value to control the number of stripes going through the bars.
• Disable Selection in the Marks Card for Total Sales Bars (Line Mark) and Striped Bars.
• Remove grid lines, zero lines, row/column dividers, and axis headers.
• Filter or hide the null indicator in the bottom right.
• Clean up/customize/remove your tooltips on the Total Sales Bars (Polygon Mark).
• Rename your Map Layers to stay organized.

Optional: Add a Custom Bar Label

If we want to use a custom label at the end of our bars, we can do that with one more calculation.

Add [Bar Label] as a Marks layer.

• Change the Mark Type to Circle.
• Lower Opacity to 0%.
• Disable Selection on the Map Layer.
• Add [Region] and SUM(Sales) to Label.
• Set the Label Alignment to Middle Right (Controls where the text sits relative to the Circle).

• Format the Label text. Left align inside of the label text (Controls how the text sits within the textbox).

• Unhide the [Longitude] axis and set a fixed axis range to add some space for the labels to breathe.

And, done!

Wrapping Things Up

Well, this technique is definitely not a “Show Me” bar chart… But hopefully, for some more niche use cases, this tutorial is beneficial for the craziest of the #DataFam.

What did you think about this tutorial? Leave a comment if you found this helpful, or share ideas for future content on this blog. I’ll see you all next month with another #feizadata blog post! 👋

Tableau Map Layers Magic: Striped Bar Chart was originally published in Retail Tableau User Group on Medium, where people are continuing the conversation by highlighting and responding to this story.