You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We already have the ability to run geo-testing (with synthetic control methods), but this assumes that we have just a single treated region.
But often we may have (or plan to have) multiple regions which receive treatment. This treatment may either be the same, or different, if it is different, it could be different in kind (e.g. store refurbishment vs price discounts) or degree (level of price discount).
Below are notes which sketch out some approaches we could take here:
1. Individual synthetic control analyses for each treated geography
It would be perfectly valid to treat each treated region as its own experiment. For each treated region, the set of control regions would be the complete set of remaining untreated regions. I don't see any problem in a control region being used as a donor in multiple synthetic control experiments.
This method may make most sense if the treatments were different in kind or magnitude. That is, when we do not expect the effects of the intervention to be similar in each treated region.
Optionally, if we have a natural hierarchy then we can choose the control regions based upon this. For example, if we have one test store per geographical state, then we could use the relevant store data for each of the separate tests.
2. Aggregated synthetic control
If the treatments are similar and we expect the effects of the intervention to be similar across treated regions, then it may make sense to create a new aggregate (e.g. mean or median) test region
TODO
This issue can be closed by the addition of a new notebook example which demonstrates each of these approaches. It should operate on simulated data where we simulate known intervention effects on multiple regions.
Though it could also be useful to create new functionality, so a function or class called something like MultiCellSyntheticControl and we can pass kwargs to provide the test region and method (independent vs aggregated)
The text was updated successfully, but these errors were encountered:
We already have the ability to run geo-testing (with synthetic control methods), but this assumes that we have just a single treated region.
But often we may have (or plan to have) multiple regions which receive treatment. This treatment may either be the same, or different, if it is different, it could be different in kind (e.g. store refurbishment vs price discounts) or degree (level of price discount).
Below are notes which sketch out some approaches we could take here:
1. Individual synthetic control analyses for each treated geography
It would be perfectly valid to treat each treated region as its own experiment. For each treated region, the set of control regions would be the complete set of remaining untreated regions. I don't see any problem in a control region being used as a donor in multiple synthetic control experiments.
This method may make most sense if the treatments were different in kind or magnitude. That is, when we do not expect the effects of the intervention to be similar in each treated region.
Optionally, if we have a natural hierarchy then we can choose the control regions based upon this. For example, if we have one test store per geographical state, then we could use the relevant store data for each of the separate tests.
2. Aggregated synthetic control
If the treatments are similar and we expect the effects of the intervention to be similar across treated regions, then it may make sense to create a new aggregate (e.g.
mean
ormedian
) test regionTODO
This issue can be closed by the addition of a new notebook example which demonstrates each of these approaches. It should operate on simulated data where we simulate known intervention effects on multiple regions.
Though it could also be useful to create new functionality, so a function or class called something like
MultiCellSyntheticControl
and we can pass kwargs to provide the test region and method (independent vs aggregated)The text was updated successfully, but these errors were encountered: