Running tests for cointegration. All of the series need to be non-stationary to be valid for testing. Some of my series are non-stationary (with high p-values either 1 or close to 1), but when I log the series, it results in a statistically significant p-value of 0 or close to 0.
Why is the log changing the stationarity of my time-series data? How do I maintain the non-stationarity of my variable?
Extra Info: the variables are personal income per capita in specific locations.
Thanks!
If you have a two-d time series: personal income per capita in two regions, call them $x_t$ and $y_t$, then the two time series you are testing for cointegration have different interpretations. You should only be testing the one with the "good" interpretation that coheres with subject matter knowledge.
Stationarity in $a_1 x_t - a_2 y_t$, a linear combination of the levels, would imply that if one region gets richer relative to another, that good fortune will be short-lived. If you take expectations of this (I'm assuming driftless) stationary process, it implies that there is a long run equilibrium between personal income per capita in the two regions. This is because $a_1 \mu_x = a_2\mu_y + \mu_{non-logs}$. Or in other words, one's mean is a linear function of the other's.
Stationarity in $a_1 \log x_t - a_2 \log y_t$, a linear combination of the log-levels, would imply that if one region is growing faster than another, then that expansion will be short-lived. Taking the expectations implies that there is a long-run equilibrium between growth in per capita income. This is because $a_1 \mu_{log x} = a_2 \mu_{\log y} + \mu_{logs}$. Or in other words, one's average log-income per capita is a linear function of another's.
So you should reason out theoretically which of these hypotheses makes sense more. This is important, because the null hypothesis on these stationarity tests is NON-stationarity. You will likely have higher power (higher chance of concluding stationarity) if you are testing the right series.
I would advise against running both tests, and then using the transformation that successfully rejected either null. The type 1 error on that overall strategy is not the same as an individual test.
