Migration Trends FAQs

Q: What is the source of the polygons used to define/geofence the Cities and Towns?

A: We use Census Places polygons, taken from this source: https://www.census.gov/cgi-bin/geo/shapefiles/index.php?year=2022&layergroup=Places

Q: Why does my town not appear in Placer’s Migration Trends ‘Cities and Towns’?

A: A total of just over 22,000 Cities & Towns is supported by our Migration trends (after having filtered out ones that are too small, e.g. lacking an adequate panel). Most likely your town has too small a population for us to be able to establish data from a reliable panel in it, throughout the year.

Q: Do Placer’s Migration numbers take into account migration from or to Puerto Rico?

A: As of V3.1 (August release) Yes - in geographies where relevant, we incorporate migration counts derived from Census data, allowing us to include migration to and from Puerto Rico

Q: How does Placer address the migration of non-DMA and non-CBSA areas?

A: The v3.1 release of the Migration trends feed introduces the following new DMA/CBSAs to answer this exact question:
non-DMA : 111 - represents non-DMA covered areas of Alaska. Migrations identified as occurring to/from those ‘non-DMA covered’ locations are counted as part of this new ‘non-DMA’.
non-CBSA: XX111 - Is a new formatted code of aggregating CBSAs representing the non-CBSA areas of any state includes such areas. The code of this new CBSAs is a concatenation of the FIPS state code and ‘111’. For example Florida FIPS state code is 12, so the non-CBSA areas in Florida are aggregated into CBSA code 12111.

Q: How do you count an individual that migrated towards the end of last month’s report, but then turned out to have left the destination of migration (i.e. returned home ) right after the report was published?

A: Such an “edge case” will be corrected in the following month’s migration report. On calculating migration for the following month the individual will be identified as not having met the migration criteria of a minimal 2 month stay, so will be filtered out of the month in which his migration was previously reported. This correction will retroactively reflect that the individual did not migrate (to the region previously reported), and the migration data for that region will be adjusted accordingly.

Q: Can Migration Data update historically/retroactively?

A: Yes, historical migration data may update retroactively to reflect ‘real world’ changes that transpired, e.g. a person that moved (counted towards migration) but then returned after less than 5 months (therefore did not migrate in reality). There may be more retroactive updates in the latest month reported, but they subside significantly the further you look back; e.g. typically negligible tiny changes to historical data 6 months and older. We recommend that customers using the Migration Trends report will refresh the historical data each month, upon receiving the new report.