CausalImpact | An R package for causal inference in time series | Time Series Database library

It looks like your data is a dataframe, but you are providing dates in the pre_period and post_period objects, which require your data be be a time series object instead. This is explained in the original R package documentation here.

To sum up: provide indices for dataframes, provide dates for time series.

This turned out to be a bug with CausalImpact version 1.2.3. Since posting this question, a new version of CausalImpact (1.2.4) has become available on CRAN. The bug can be fixed by

install.packages('CausalImpact')

It turned out that the impact_plot.R file was using

There are lots of ways with which you can do that, the simplest way is to convert the data into a data-frame and deal with it easily.

I did not try to use additional packages i.e. tidyverse and only used Base R so as not to complicate the solution.

Also I have reproduced an example using MarketMatching data;

From R 3.6.0 onwards, there is a new option called "conflicts.policy" to handle this within an established framework. For small issues like this, you can use the new arguments to library(). If you aren't yet to 3.6, the easiest solution might be to explicitly namespace CausalImpact when you need it, i.e. CausalImpact::CausalImpact. That's a mouthful, so you could do causal_impact <- CausalImpact::CausalImpact and use that alias.

This is an interesting question and comparison between the two packages. The difference is apparently coming from the different estimation methods: maximum likelihood in Statsmodels and Bayesian MCMC in bsts. It is not surprising that a difference would show up in a case like this, since the time series is so short.

The reason I say this is that, given sigma.obs, sigma.level, and coefficients from the bsts output, for any iteration of their MCMC algorithm, I can replicate their one.step.prediction_errors and log.likelihood for that iteration by applying the Kalman filter to the local level + exog model using the parameter values from that iteration.

They do have one difference from Statsmodels, which is that they set the prior for the unobserved state based on the first observation of the dataset and the variance of the dataset, which is probably not optimal (but shouldn't be causing any major problems). Statsmodels instead uses a diffuse prior, which again shouldn't cause any major discrepancies. As I mentioned above, when I use their prior, I can match their filtering output.

So the difference must be in the estimation method, and this could have to do with the details of their MCMC algorithm and the priors that they set. You could follow up with them to see if they have any intuition about how their setup might be affecting results.

Discussion of residuals and loglikelihood computation

We decided then to compute the loglikelihood of the residuals while ignoring the level component (as its variance is relatively low) to see what would be the most appropriate value for irregular, like so:

I think someone else in your org may have already contacted me about this. We are mid-flight debugging.

Boom is a large package and can time out when building. The first thing to check is that you are able to build with multiple cores (i.e. you can pass the -j x flag to make).

As a diagnostic you can try building the package without involving R. Clone https://github.com/steve-the-bayesian/BOOM and build with either bazel (up to date) or make (not too far out of date). If this build succeeds then compare flags passed to the R build vs the native build.

To better understand where R is failing, download the Boom package from CRAN https://cran.r-project.org/src/contrib/Boom_0.9.1.tar.gz and try the following from the command line R CMD CHECK Boom_0.9.1.tar.gz

This will probably fail, but it will generate a directory called Boom.Rcheck, which contains a file 00install.out containing all the compiler output.

It is suspicious that the build above fails on the poisson_mixture_approximation_table, which is a large file that might be overflowing your stack. Or that might be a coincidence.

Port 3838 is the default port for Shiny Server, but runApp() chooses an available port. It appears R is not picking up your Rprofile.site, so I would just specify the port in your call to runApp():

@Josef is correct and you did the right thing with:

You are right, this is not directly possible with CausalImpact, but it is possible. CausalImpact uses bsts behind the scenes and this package allows to set the parameter. So you have to define you model using bsts first, set the parameter and then provide it to your CausalImpact call like this (modified example from the CausalImpact manual):