Marginal effects and interaction terms
The trick
I recently tweeted one of my favourite R tricks for getting the full marginal effect(s) of interaction terms. The short version is that, instead of writing your model as lm(y ~ f1 * x2)
, you write it as lm(y ~ f1 / x2)
. Here’s an example using everyone’s favourite mtcars
dataset.
First, partial marginal effects with the standard f1 * x2
interaction syntax.
Second, full marginal effects with the trick f1 / x2
interaction syntax.
To get the full marginal effect of factor(am)1:wt
in the first case, I have to manually sum up the coefficients on the constituent parts (i.e. factor(am)1=14.8784
+ factor(am)1:wt=5.2984
). In the second case, I get the full marginal effect of −9.0843 immediately in the model summary. Not only that, but the correct standard errors, pvalues, etc. are also automatically calculated for me. (If you don’t remember, manually calculating SEs for multiplicative interaction terms is a huge pain. And that’s before we even get to complications like standard error clustering.)
Note that the lm(y ~ f1 / x2)
syntax is actually shorthand for the more verbose lm(y ~ f1 + f1:x2)
. I’ll get back to this point further below, but I wanted to flag the expanded syntax as important because it demonstrates why this trick “works”. The key idea is to drop the continuous variable parent term (here: x2
) from the regression. This forces all of the remaining child terms relative to the same base. It’s also why this trick can easily be adapted to, say, Julia or Stata (see here).
So far, so good. It’s a great trick that has saved me a bunch of time (say nothing of likely usererror) that I recommend to everyone. Yet, I was prompted to write a separate blog post after being asked whether this trick a) works for higherorder interactions, and b) other nonlinear models like logit? The answer in both cases is a happy “Yes!”.
Dealing with higherorder interactions
Let’s consider a threeway interaction, since this will demonstrate the general principle for higherorder interactions. First, as a matter of convenience, I’ll create a new dataset so that I don’t have to keep specifying the factor variables.
Now, we run a threeway interaction and view the (naive, partial) marginal effects.
Say we are interested in the full marginal effect of the threeway interaction vs1:am1:wt
. Even summing the correct parent coefficients is a potentially errorprone process of thinking through the underlying math (which terms are excluded from the partial derivative, etc.) And don’t even get me started on the standard errors…
Now, it should be said that there are several existing tools for obtaining this number that don’t require us working through everything by hand. Here I’ll use my favourite such tool — the margins package — to save me the mental arithmetic.
We now at least see that the full (average) marginal effect is −7.7676. Still, while this approach works well in the present example, we can also begin to see some downsides. It requires extra coding steps and comes with its own specialised syntax. Moreover, underneath the hood, margins relies on a numerical delta method that can dramatically increase computation time and memory use for even moderately sized realworld problems. (Is your dataset bigger than 1 GB? Good luck.) Another practical problem is that margins may not even support your model class. (See here.)
So, what about the alternative? Does our little syntax trick work here too? The good news is that, yes, it’s just as simple as it was before.
Again, we get the full marginal effect of −7.7676 (and correct SE of 2.2903) directly in the model object. Much easier, isn’t it?
Where this approach really shines is in combination with plotting. Say, after extracting the coefficients with broom::tidy()
, or simply plotting them directly with modelsummary::modelplot()
. Model results are usually much easier to interpret visually, but this is precisely where we want to depict full marginal effects to our reader. Here I’ll use the modelsummary package to produce a nice coefficient plot of our threeway interaction terms.
The above plot immediately makes clear how automatic transmission exacerbates the impact of vehicle weight on MPG. We also see that the conditional impact of engine shape is more ambiguous. In contrast, I invite you to produce an equivalent plot using our earlier fit1
object and see if you can easily make sense of it. (I certainly can’t.)
Aside: Specifying (parent) terms as fixed effects
On the subject of speed, recall that the lm(y ~ f1 / x2)
syntax is equivalent to the more verbose lm(y ~ f1 + f1:x2)
. This verbose syntax provides a clue for greatly reducing computation time for large models; particularly those with factor variables that contain many levels. We simply need specify the parent factor terms as fixed effects (using a specialised library like fixest). Going back to our introductory twoway interaction example, you would thus write the model as follows.
(I’ll let you confirm for yourself that running the above models gives the correct −9.0843 figure from before.)
In case you’re wondering, the verbose equivalent for the f1 / f2 / x3
threeway interaction is f1 + f2 + f1:f2 + f1:f2:x3
. So we can use the same FE approach for this more complicated case as follows.^{1}
There’s our desired −7.7676 coefficient again. This time, however, we also get the added bonus of clustered standard errors (which are switched on by default in fixest::feols()
models).
Caveat: The above example implicitly presumes that you don’t care about doing inference on the parent term(s), since these are swept away by the underlying fixedeffect procedures. That is clearly not going to be desirable in every case. But, in practice, I often find that it is a perfectly acceptable tradeoff for models that I am running. (For example, when I am trying to remove general calender artefacts like monthly effects.)
Other model classes
The last thing I want to demonstrate quickly is that our little trick carries over neatly to other model classes to. Say, that old workhorse of nonlinear stats hot! new! machine! learning! classifier: logit models. Again, I’ll let you run these to confirm for yourself:
Okay, I confess: That last code chunk was a trick to see who was staying awake during statistics class. I mean, it will correctly sum the coefficient values. But we all know that the raw coefficient values on generalised linear models like logit cannot be interpreted as marginal effects, regardless of whether there are interactions or not. Instead, we need to convert them via an appropriate link function. In R, the mfx package will do this for us automatically. My real point, then, is to say that we can combine the link function (via mfx) and our syntax trick (in the case of interaction terms). This makes a surprisingly complicated problem much easier to handle.
Conclusion
We don’t always want the full marginal effect of an interaction term. Indeed, there are times where we are specifically interested in evaluating the partial marginal effect. (In a differenceindifferences model, for example.) But in many other cases, the full marginal effect of the interaction terms is exactly what we want. The lm(y ~ f1 / x2)
syntax trick (and its equivalents) is a really useful shortcut to remember in these cases.
PS. In case, I didn’t make it clear: This trick works best when your interaction contains at most one continuous variable. (This is the parent “x” term that gets left out in all of the above examples.) You can still use it when you have more than one continuous variable, but it will implicitly force one of them to zero. Factor variables, on the other hand, get forced relative to the same base (here: the intercept), which is what we want.
Update. Subsequent to posting this, I was made aware of this nice SO answer by Heather Turner, which treads similar ground. I particularly like the definitional contrast between factors that are “crossed” versus those that are “nested”.

For the
fixest::feols
case, we don’t have to specify all of the parent terms in the fixedeffects slot — i.e. we just need am^vs
— because these fixedeffects terms are all swept out of the model simultaneously at estimation time. ↩
Comments