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: For the specific 36 ZCTAs that are mentioned under V3.1 release notes - How exactly are those ZCTAs calculated differently, compared to other ZCTAs?

A: Due to the statistical nature of Migration calculations, we sometimes encounter ‘edge cases ZCTAs’ (eg with low population or high seasonality) where invalid population results may occur (eg zero or negative results). Our algorithms will detect such cases, and for them, re-estimate the migration flows between the ZCTAs in question, based on ZCTA-level (rather than county level) panelist weighting.

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 2 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.

Q: Sometimes when hovering over a county or CBSA in the Overview screen, I see a certain population number, but then when I click into it, the population graph in the ‘Zipcodes Map’ screen shows a different population. Why is this?

A: This is mainly because many ZIP/ZCTAs belong to more than one county or CBSA. In the Overview screen, the population numbers are an accurate calculation based on Census data for that county/CBSA + Placer's migration data for the same region. When you click into the ZIPs map for that area, it includes all ZIPs that overlap it, but some of those ZIPs might also partially belong to a neighboring area; consequently, summing them all up may result in a slightly different number.