OCC2010 any change in June/July 2015?

CPS
1

I was computing month-to-month transitions between occupations (different digits as well as major and detailed groups) based on the harmonized OCC2010 variable and noticed a weird spike in June 2015. It jumps to around 7% while between 2005 and today it is usually around 2% or 3%. Also for the rest of the time range (even when there is a new occupation classification e.g. in Jan 2020) no such anomaly is visible. Is this a known issue/due to some reclassification or change in interviewing technique? Any help would be greatly appreciated.

I would attach the figure for the month-to-month transition rates for 10 major occupation groups but I’m not allowed to as a new user.

2

Can you provide a little more information about the discrepancy? You should be able to add an image to your post now, so adding that might help. If you’re having issues with this please email ipums@umn.edu.

I have a few immediate follow up questions: Is the rate that jumps to 7% the average monthly transition rate between any two major occupation groups, across all employed people? What coding of major occupations are you using? Which transition is anomalous, from May-June 2015 or June-July?

3

Thanks a lot for your reply. I’ve done a lot more digging around and found a strange behaviour of the EMPSAME variable (which I use implicitly at some point) that might explain this pattern. EMPSAME has only NIU as expected for observations with MISH 1 or 5, but weirdly enough for June 2015 and MISH=2 all observations of EMPSAME are NIU. Any idea why this might be happening? Or should I open a new thread for this? Interestingly if I simply drop MISH=2 for my analysis the spike in occupation switches disappears because I implicitly use the EMPSAME variable when computing the transitions.

4

The IPUMS CPS team has looked into this issue and it appears to be an undocumented anomaly in the original public use microdata files obtained from the Census Bureau. Thanks for pointing this out. Unfortunately, we are unable to correct these issues in the underlying data, but we will update the documentation for EMPSAME in a future release to clearly note this issue.

5

Thanks a lot for your response. I will contact the BLS to inquire about potential reasons for this and keep you posted