Why does taking logs of right-skewed values like house prices reduce the skewness?

## Why the log pulls in a right tail Positive skewness on a strictly positive variable usually has a common structure: a hard floor at zero, a dense cluster of ordinary values, and a thin tail of values that are many times larger. House prices, session durations, file sizes, and claim amounts all look like this. The natural logarithm is **concave and increasing**. Increasing means it preserves order — the most expensive house stays the most expensive. Concave means it compresses larger inputs more aggressively than smaller ones: `log(1000) - log(100) = log(10) = log(100) - log(10)`. A tenfold step is the same distance no matter where it starts. So the stretch from 200,000 to 2,000,000 in the tail collapses to the same span as the stretch from 20,000 to 200,000 near the floor, and the tail stops dominating. Because skewness is the average of *cubed* z-scores, the far tail is where nearly all of the positive contribution comes from. Shrinking that region is precisely what drives the statistic toward zero. ## What the numbers do There is no guarantee, only a strong tendency. For data whose logs are close to symmetric, the log transform lands sample skewness near zero and typically pulls excess kurtosis down as well, because it also thins the fourth-power contributions from the tail. On a variable with a mild right skew, the log can **overcorrect** and leave you with a left-skewed shape and a negative skewness. Always recompute skewness on the transformed values rather than assuming the transform worked. ## The Box-Cox family The log is one member of a one-parameter family of power transforms. For strictly positive `y`, the Box-Cox transform is `y(lambda) = (y^lambda - 1) / lambda` for `lambda != 0` `y(lambda) = log(y)` for `lambda = 0` The `lambda = 0` case is defined as the log precisely because `(y^lambda - 1) / lambda` tends to `log(y)` as `lambda` goes to zero, which makes the family continuous in `lambda`. Useful landmarks: `lambda = 1` is essentially no transform (a shift and rescale), `lambda = 0.5` is a square root, `lambda = 0` is the log, and `lambda = -1` is a reciprocal. Smaller `lambda` means a more aggressive squeeze of the right tail. `lambda` is normally chosen by maximising a profile log-likelihood over a grid — in effect, picking the power that makes the transformed values look most like a symmetric bell. Two practical points: the fitted `lambda` usually comes with a wide interval, so it is common and sensible to round to a nearby interpretable value such as 0 or 0.5 rather than reporting `lambda = 0.07`; and the standard Box-Cox transform requires **strictly positive** input, which is the single most common reason it cannot be applied directly. ## Zeros and negatives The log is undefined at 0 and for negative numbers, and a variable such as session duration or revenue per user is full of exact zeros. Options in practice: - Add a small constant: transform `log(x + c)`. This works but is not innocent — the choice of `c` visibly changes the shape of the low end, and results can be sensitive to it. Choose `c` on substantive grounds (a natural measurement floor) and state it. - Use a transform defined for zero and negative values, such as the signed power family that extends Box-Cox, or the inverse hyperbolic sine. - Model the zeros separately from the positive part, if the zeros mean something structurally different (no session started at all versus a very short session). ## Left skew The log is a *right*-tail tool. Applied to left-skewed data it lengthens the left tail and makes skewness more negative. For left skew, reflect first (transform `max(x) + 1 - x`) and then apply a power transform, or use a power greater than 1 such as squaring or cubing, which stretches the upper end. ## Interpretation cost This is the tradeoff that separates a good answer from a mechanical one. After the transform you are describing a different quantity. Differences on a log scale are ratios on the original scale: a gap of 0.7 in natural logs is roughly a 2x multiplicative difference. And exponentiating the mean of the logs does **not** return the arithmetic mean of the original values — the exponential of an average is not the average of exponentials. So a summary produced on the log scale must either be reported on the log scale with that stated plainly, or back-transformed with an explicit and correct statement of what the back-transformed number represents. If the audience makes decisions in dollars, hiding a log transform inside the pipeline is a communication failure even when the statistics are cleaner.