I have a panel data in the following form:

<id> <city> <treated> <time> <after>

where id identifies the individuals in my panel, city is the location where the individual live (non-time varying), treated is a dummy indicating those individual that are eventually treated (0: non-treated, 1: treated), time is a year-month variable, and after is a dummy (0: before, 1: after) indicating the period in which the treated unit are under treatment.

With this data, I am running a simple difference-in-differences model. I am including individual fixed effects and year-month fixed effects. To relax the parallel assumption, I include a treatment-city specific time trend -- people often include treatment specific trends, but in my settings the outcome can vary a lot across cities for treatment and control units -- so my specification should be:

xtset id time
xtreg depvar i.treated i.after c.treated#c.after i.time i.city#c.treated#c.time, fe cluster(id)



is the treatment-city specific linear trend.

Generally, in this kind of models I use to include only a treatment-specific trend, and not a 3-way interaction. The first question is whether this approach makes sense.

Second, I thought that adding:




was exactly the same (note that the variable treated in coded as 0/1), but apparently is not. Can someone explain me the statistical difference between including one term or the other in my regression?

Morever, some tests I did suggest that adding




is the same. Why with a 2-way interaction, treating the variable treated as continuous or as a factor does not matter?

P.S. Thanks to Dimitriy for the current answer!

  • $\begingroup$ I cleaned up your question a bit. You omitted the command name, which I filled in as xtreg. Please edit with the correct one if that is not the case. $\endgroup$ – Dimitriy V. Masterov Jul 24 '16 at 2:52
  • 1
    $\begingroup$ I think there's a statistical question lurking in there about whether treatment-specific trends are appropriate, so it's not purely about software. $\endgroup$ – Dimitriy V. Masterov Jul 24 '16 at 5:50
  • 1
    $\begingroup$ Hi All, why my question is still on hold? I edited and it seemed that the edits where approved. Thanks! $\endgroup$ – Davide Jul 24 '16 at 19:31
  • $\begingroup$ Hi @Davide, there is a difference between the "edit approval" process and the "reopening" process. I approved your edit (the problem was an account problem and you should have been able to edit your own post automatically), but didn't take part in the process to reopen/leave closed. So hopefully someone who did can explain. It's likely they felt that the edits didn't sufficiently clarify the extent to which this question is statistical (on-topic) rather than merely about programming (off-topic). $\endgroup$ – Silverfish Jul 25 '16 at 1:13

This is edited a bit in response to revisions.

It is strange to me that treated and after are dummies, yet you are treating them as continuous variables by using the c. prefix. I would have used the i. prefix. I will assume that is what you had intended below.

This will not matter in simple models, but once you add interactions, Stata might choose a different city as the base in your specification (for reasons which elude me). This means the parameters will be different for that reason alone. Fixing the base with something like ib4.city and ib0.time will remedy this. I will add an example below.$^*$

Also, I might be inclined to cluster at the city level with this setup.

Also, note that i.treated#c.time and c.treated#c.time are not equivalent. Here's example with the cars data:

sysuse auto, clear
reg price i.foreign#c.mpg
reg price c.foreign#c.mpg

The first spec allows for two separate effects for mpg on price, one for domestic cars and one for foreign. The second allows for mpg to alter price for foreign cars only.

Now to answer your main question. As a way to relax the parallel trends assumption, people will often include time dummies and a parametric time trend (linear or quadratic) for the treated only in the estimating specification. You are going further and making the time trend city-specific in your first command. There's a nice SJ paper by Mora and Reggio, where they discuss this approach (take a look at equations (3) and (4)). If I understand their notation, that corresponds to i.city#c.treated#c.t or i.city#1.treated#c.t with i.t. They also have a WP with a section on common types of specifications from the literature. All the linear/polynomial trends are for the treatment group only, not both.

Your goal can be accomplished by i.city#c.treated#c.t since treating a binary variable as continous is equivalent to putting in a dummy. When you use i.city#i.treated#c.t, that is equivalent to putting in two trends for each city: one for treated and one for control observations. I don't think this is something you want.

Personally, I think the clearest way to achieve the former goal is with i.city#1.treated#c.t.

Here's an example with the Card & Krueger unemployment data, where I am using the fast food chain instead of city (Wendy's is the base category). This data only has two periods, so there's no separate time dummy. It's a bit confusing since X.chain#c.treated#c.t coefficient is the same parameter as X.chain#1.treated#c.t in the table, but it has different labels:

. set more off

. estimates clear

. use http://fmwww.bc.edu/repec/bocode/c/CardKrueger1994.dta, clear
(Dataset from Card&Krueger (1994))

. drop if id==407
(4 observations deleted)

. xtset id t
       panel variable:  id (strongly balanced)
        time variable:  t, 0 to 1
                delta:  1 unit

. gen chain = ""
(816 missing values generated)

. foreach var of varlist  bk kfc roys wendys {
  2. replace chain="`var'" if `var'==1
  3. }
variable chain was str1 now str2
(342 real changes made)
variable chain was str2 now str3
(158 real changes made)
variable chain was str3 now str4
(198 real changes made)
variable chain was str4 now str6
(118 real changes made)

. sencode chain, replace

. eststo: qui xtreg fte i.treated##i.t i.chain#c.treated#c.t, fe cluster(id)
(est1 stored)

. eststo: qui xtreg fte i.treated##i.t i.chain#1.treated#c.t, fe cluster(id)
(est2 stored)

. eststo: qui xtreg fte i.treated##i.t i.chain#i.treated#c.t, fe cluster(id)
(est3 stored)

. esttab *, noomitted drop(0.treated 0.t 0.treated#0.t) varwidth(25)

                                   (1)             (2)             (3)   
                                   fte             fte             fte   
1.t                             -2.523*         -2.523*         -2.577   
                               (-2.02)         (-2.02)         (-1.04)   

1.treated#1.t                    3.517           3.517           3.571   
                                (1.63)          (1.63)          (1.17)   

1.chain#c.treated#c.t            0.268                                   

2.chain#c.treated#c.t           -0.225                                   

3.chain#c.treated#c.t           -2.439                                   

1.chain#1.treated#c.t                            0.268           0.268   
                                                (0.14)          (0.14)   

2.chain#1.treated#c.t                           -0.225          -0.225   
                                               (-0.12)         (-0.12)   

3.chain#1.treated#c.t                           -2.439          -2.439   
                                               (-1.28)         (-1.28)   

1.chain#0.treated#c.t                                           -0.791   

2.chain#0.treated#c.t                                            4.804   

3.chain#0.treated#c.t                                           -1.291   

_cons                            17.69***        17.69***        17.69***
                               (79.93)         (79.93)         (79.99)   
N                                  797             797             797   
t statistics in parentheses
* p<0.05, ** p<0.01, *** p<0.001

$^*$Fixing The Base:

estimates clear
eststo: xtreg fte i.treated##i.t ib4.chain#c.treated#c.t, fe cluster(id)
eststo: xtreg fte c.treated##c.t ib4.chain#c.treated#c.t, fe cluster(id)
eststo: xtreg fte c.treated##c.t i.chain#c.treated#c.t, fe cluster(id)
esttab *, noomitted drop(0.treated 0.t 0.treated#0.t) varwidth(30)
| cite | improve this answer | |
  • $\begingroup$ Thanks Dimitriy, your answer was really helpful. I edited the question because I still have a couple of concerns about how to proceed with the identification strategy. $\endgroup$ – Davide Jul 24 '16 at 19:32
  • $\begingroup$ @ Dimitris; I understand that with i.treated#c.time I have two effects, but the coefficients for after, treated, and their interaction are exactly the same independently of what I use, i.treated#c.time and c.treated#c.t. However, this is not case for the 3-way interaction, and I don't understand why. $\endgroup$ – Davide Jul 25 '16 at 3:30
  • $\begingroup$ You can try with the Card&Krueger data, you'll see that 1.t, 1.treated#1.t and the constant are exactly the same in both cases. $\endgroup$ – Davide Jul 25 '16 at 3:37
  • $\begingroup$ @David You are not being clear about the exact spec you have in mind here. As I explained above, with the 3-way interaction, this happens because when you write it one way, the included chain effects are KFC, Roy Rogers, and Wendy's (with Burger King as the omitted base) and the other has BK, KFC, and Roy Rogers (with Wendy's as the base). This changes the parameter being estimated. If you fix the base to Wendy's (as I did in the footnote code snippet) or by using fvset (even better), you will get the same answer. The simpler 2-way interaction spec doesn't have this problem. $\endgroup$ – Dimitriy V. Masterov Jul 25 '16 at 5:49
  • $\begingroup$ Thanks Dimitriy and sorry about being not very clear. I missed that part -- so it is just Stata setting different levels. I actually reached the same conclusion yesterday night playing with a small example. $\endgroup$ – Davide Jul 25 '16 at 16:04

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