0

I have a panel data with sales rank of an app on appstore over a period of 11 months. Some of the apps were promoted during this period and form the treatment groups (treated=1), while others form the control group. While there are 180 treated apps, there are close to 21k controls apps. I wish to find the nearest neighbors of the treated apps from the control apps during the pre-treatment period, so that I am essentially making an apples-to-apples comparison while estimating treatment effects. I am using psmatch2 package from Stata, however, I am confused if this package requires long or wide data format (I have found contradicting examples on internet), and the psmatch2 documentation itself does not mention anything in specific.

Propensity score matching with panel data answer suggests using wide format in general, however the author of answer is not familiar with psmatch2.

So, what format should I store my data in, wide or long?

Any help would be greatly appreciated.

Thanks!

Community
  • 1
harshal.c
  • 11
  • 3

1 Answers1

1

You will want the data in wide format. The idea is to match on the pre-treatment outcomes for each month as if it was just another X variable.

However, it sounds like apps get treated at different times, so this sort of data structure will not work very well because the number of pre-treatments periods and the number of matching variables will be different for each app. psmatch2 cannot handle that easily.

Also, you might worry about violations of the Stable Unit Treatment Assumption. If an app gets treated, it alters the potential outcome for the control apps for which it is a substitute or a complement since fewer/more of them will be downloaded. In this setting, matching (and all other partial equilibrium estimators that rely on SUTVA) may perform poorly.

dimitriy
  • 31,081
  • 5
  • 63
  • 138
  • Thanks a lot! I read that it in case of time varying treatment, it is ok to include each time period as independent variable (I am not completely convinced that it is). Any suggestions on what I could potentially do instead of matching? – harshal.c Aug 23 '16 at 03:07
  • @harshal.c It is OK, but you need to reconfigure the time to be months before treatment instead of calendar time. I don't know of an alternative identification strategy that is robust to SUTVA violation. This is a very hard problem! – dimitriy Aug 23 '16 at 21:35
  • The problem with re-configuring the time to be months before treatment is that all treated apps were treated at different points in time. As there is no unique date of intervention, I cannot assign the value of reconfiguration variable for the control apps. [link](https://scholar.google.com/scholar_url?url=http://www.mitpressjournals.org/doi/pdfplus/10.1162/rest.88.2.211&hl=en&sa=T&oi=gsb-gga&ct=res&cd=0&ei=HwXHV-upJsTRjAHcg79I&scisig=AAGBfm2lxZtbWs5UBB48JxKtBzMCblMqQw) solves this problem by creating a separate value of this variable for every control, for every treated entity. Reasonable? – harshal.c Aug 31 '16 at 16:29
  • I can't access the link, but that seems sensible and similar to what I had in mind. – dimitriy Sep 01 '16 at 05:50
  • Make sure you really want to do matching. There are many good reasons not to use a matching algorithm, related to loss of efficiency due to discarding "good" observations, and arbitrariness in the choice of matching algorithms. – Frank Harrell Dec 31 '17 at 13:22