You log-transform right-skewed income before a t-test - which hypothesis are you now testing?

## Why anyone logs income in the first place Income, revenue per customer, session duration and waiting times share a shape: a dense mass of small values and a long right tail. That shape makes the arithmetic mean unstable, gives a few observations enormous leverage on the sample standard deviation, and slows the convergence that normally makes a mean-comparison well behaved at moderate sample sizes. A logarithm compresses the upper tail hard and stretches the lower one, and multiplicative processes - things that grow by percentages - become additive on the log scale, which is often close to symmetric. So the transform genuinely fixes the shape problem it was applied for. ## What it does to the question The cost is that the question changes. On the log scale you are comparing `mean(log X)` between groups. Exponentiate a group's mean log and you get the geometric mean: the n-th root of the product of the values, equivalently `exp(mean(log X))`. Exponentiate the difference between the two mean logs and you get the ratio of the two geometric means. So the confidence interval you report on the log scale becomes, after back-transformation, an interval for a ratio - a multiplicative effect - not for a difference in currency. That matters because geometric and arithmetic means are different quantities. By Jensen's inequality the geometric mean is never larger than the arithmetic mean, with equality only when every value is identical. For a lognormal variable with log-scale parameters `mu` and `sigma`, the geometric mean is `exp(mu)` while the arithmetic mean is `exp(mu + sigma^2 / 2)`. Two groups can therefore share a geometric mean and differ in arithmetic mean purely because one has a wider spread in logs - and that extra spread sits in the upper tail, which is exactly where total revenue comes from. A transformed analysis can honestly report 'no difference' while the totals differ substantially. ## Back-transformation is not a formality A related trap is exponentiating a mean of logs and calling the result an estimate of the mean. It is not: it estimates the geometric mean, which for skewed data is systematically smaller. For a lognormal it corresponds to the median rather than the mean. If a stakeholder asks 'how much more does group B earn on average', an exponentiated log difference does not answer that question, and presenting it as though it does is a real reporting error. Report it as what it is: a ratio or a percentage difference in typical values, since `exp(difference) - 1` is the proportional change. ## Zeros, negatives and arbitrary constants The logarithm is undefined at zero and negative. Real income data have zeros. The common workaround of adding a small constant before logging is a modelling decision disguised as a data-cleaning step: the smaller the constant, the more extreme the logged zeros become and the more leverage they gain over the result, and different analysts choosing different constants will reach different conclusions. If zeros represent a genuinely distinct state - unemployed rather than low-earning - the more honest treatments are to model the presence of income and its amount separately, or to work on the original scale with a method that tolerates skew. ## When transforming is the right call Transform when the multiplicative comparison is the one you actually want. Percentage-style effects, elasticities, and outcomes generated by proportional processes all argue for the log scale, and there the geometric mean is not a compromise but the correct target. Transform, too, when the sample is small and the raw skew is severe enough that a mean comparison would be unreliable, and say clearly in the write-up which quantity you compared. Do not transform reflexively. At a large sample size the central limit theorem already handles moderate skew for a comparison of means, so the transform buys little and costs interpretability. And if the decision is about a total - budget, revenue, cost - the arithmetic mean is the decision-relevant quantity, and it is better to face the skew directly than to answer a cleaner question nobody asked. ## The discipline point Choose the scale before seeing the outcome. Trying the raw comparison, then the logged one, and reporting whichever crosses a threshold inflates the false-positive rate in a way no assumption check will reveal. State the transform in the analysis plan, justify it by the shape you expected and the estimand you want, and report the effect on the scale a decision-maker can act on. An interviewer asking this question is checking whether you know that an assumption fix can quietly replace the hypothesis, not just clean the data.