1
$\begingroup$

I used the plm() function for a 2-way fixed effect model with zip_code and month (yy-mm) fixed effects. The data table used for the model is panel data with id and date (yyyy-mm-dd) as the panel indexes.

The model looks like this:

plm(DV ~ IV + zip_code + month, data = panel_data, effect = "twoways", index = c("id", "date"), model = "within")

However, I read here that the effect argument takes the index arguments as fixed effects variables, i.e., first index: "group" (id), second index: "time" (month) or both: "twoways" (id, month).

How can I specify zip_code and month fixed effects that are not indexes?

Additional question: Do I need to format month and date variables for the plm() function? For example, month as yearmon and date as Date or would factor() work as well?

$\endgroup$
3
  • $\begingroup$ Welcome. Isn't id and date your zip code and month identifiers, respectively? $\endgroup$ Commented Nov 18, 2022 at 23:52
  • $\begingroup$ Thank you! Not necessarily - an id can have different zip codes on different dates. The data for one id looks like this: id - date (365 days) - month (12 months)- zip code (card >=1) - DV - IV If it would help I could reduce the zip code to a cardinality = 1. $\endgroup$ Commented Nov 19, 2022 at 0:53
  • 1
    $\begingroup$ Does this answer your question? stats.stackexchange.com/a/562373/94889 $\endgroup$
    – Helix123
    Commented Nov 20, 2022 at 9:04

1 Answer 1

1
$\begingroup$

How can I specify zip_code and month fixed effects that are not indexes?

It's permissible to include additional fixed effects in this context. According to the comments, the id's can move around over time, so if I know your id, then I don't necessarily know your zip code. I suppose if you also want to estimate zip code fixed effects, then simply include indicator variables for all the different postal zones. In R, it's as simple as including the zip code variable, as is, assuming it's a character or factor variable. To be safe, use as.factor(zip_code) on the right-hand side like you would any other variable.

# `as.factor(zip_code)` denotes zip code fixed effects

plm(DV ~ IV + as.factor(zip_code), data = panel_data, effect = "twoways", index = c("id", "date"), model = "within")

Do I need to format month and date variables for the plm function? For example, month as yearmon and date as Date or would factor work as well?

It depends.

Including month fixed effects is akin to including a dummy variable for each month. If you have a "month-year" panel with more than one year, then you should concatenate month and year. In short, a repeating month variable (e.g., 1 – 12) is not appropriate. A true "time" fixed effect would distinguish between, say, January in 2015 and January in 2018. Thus, creating a variable like the one you're proposing will work just fine (e.g., "2020-Jan", "2020-Feb", "2020-Mar", etc.). But if you really only have 12 months, then this is not necessary since the month variable uniquely identifies each time period.

Note, however, that the month fixed effects are redundant with the day fixed effects. If the date variable is a running "day-of-the-year" variable, as I suspect it is, then those day-specific effects are collinear with the month fixed effects. The function should warn you about this. I would consider modeling "month" in a different way. Maybe you want to capture some cyclical pattern in the raw data that repeats annually but is the same year-over-year. Or maybe that pattern varies by geography. If these concerns are of substantive interest, then maybe you don't have to omit month from the model.

The short answer to your question is, yes. We can most certainly estimate fixed effects that are not indexes. That being said, in settings with multiple (high-dimensional) fixed effects, the fixest package has the edge over plm in terms of speed.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.