The SafeGraph Developer Hub

Welcome to the SafeGraph developer hub. You'll find comprehensive guides and documentation to help you start working with SafeGraph as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    

Places Manual

This document provides details on attribute methodology and answers frequently asked questions (FAQs) about the nuances of the SafeGraph Places dataset.

Core Places

Places Scope

Core Places provides baseline information about every record in the SafeGraph product suite. The current scope of a place is defined as a location where consumers can spend money and/or time in the U.S. and Canada. This definition encompasses a broad swath of places ranging from restaurants, grocery stores, and malls; to parks, hospitals, and museums. In contrast, places like the SafeGraph Office, homes, and residential-only apartment buildings are not places that consumers visit, so these are not included in the SafeGraph dataset.

To enable easy search for certain types of places, we group places into 6 digit NAICs codes based on available metadata (see the naics_code section below for more information). We rely on a machine learning model to accurately predict the naics_code of each place, and our model is constantly calibrating. In general, the better the metadata - the more accurate the prediction. Some NAICs codes are easier to predict than others due to the definition of the NAICs code itself, the volume of data, and the quality of data. For example, we are very confident in our ability to assign the proper naics_code to places that are Full-Service Restaurants (722511). However, we are relatively less confident in our ability to assign the proper naics_code to places that are "Carpet and Upholstery Cleaning Services" (561740). If there are certain types of places missing from our current scope, or if there are other countries that would be valuable to include in our scope, please reach out to your SafeGraph rep or Contact Sales.

safegraph_place_id

The SafeGraph Place ID safegraph_place_id is a unique and persistent identifier for a place of interest across releases and the primary key across SafeGraph products. Each place of interest is defined as a location where people can spend time or money.

Please note that a SafeGraph Place ID may change across releases for a small subset of places of interest (POIs). Let us know if you happen to notice an inconsistency and we'll address it ASAP!

safegraph_brand_id

  • SafeGraph curates over 5800 distinct brands (and growing). These are chains of commercial POIs that include all major brands in the United States (McDonald's, AMC, Macy's Chevrolet, Whole Foods Market, etc.).
  • ~1 million POIs are associated with at least one brand. Please note that ~80% of POIs have no brand associated as they are single commercial locations (local restaurants, museum, etc.). Please see Places Summary Statistics for more detail. SafeGraph is continually improving the fill rate of brands with each release -- please contact us if you notice a brand missing.
  • Some POIs include multiple brands. Car dealerships are a good example of this: a given dealership may sell multiple car brands. Another example is POIs that are co-located, such as some Taco Bell & KFC stores, or IMAX and AMC (or Regal, etc.) cinemas. In these cases the brands and brand_ids are listed as an array that is alphabetized by brand name and the order does not specify any importance.
  • Brands provide an easy way to isolate for only major stores. If you know you are searching for a brand that we cover, we advise searching the brand column instead of the name column. Even better is to search the brand_info file and build your workflows around safegraph_brand_id.
  • Every place has a name but only POIs belonging to a chain will have a brand. In certain cases, name and brand will be the same but in other cases, these fields may be different.
  • For example, if you’re searching for all McDonald’s (fast-food) stores, you would search for all POI entries where brands = ‘mcdonalds’. Many stores may be called mcdonalds that are not the fast-food chain and therefore searching for name = 'mcdonalds' would incorrectly return non-fast-food stores. Please note that you may see alternative names in the name column even once you filter for brands = 'mcdonalds', but these will all be McDonald's fast food stores.
  • Please note that if you are having difficulty matching location or brand names to listings of POI that you have, we offer a matching service that will provide you with SGPID's of locations mapped to your existing POI data.
Name Brand Comment
mcdonald's us mcdonalds
mcdonald's store mcdonalds You may occasionally get variations in the name column, but as long as you query the brand column correctly, you’ll get all the McDonald’s correctly.
mcdonald’s tractor supply store null This POI that is not a branch of the McDonald’s fast food chain is easy to notice because it has a null value in the brands column.

street_address

  • We implement a number of steps to clean, validate and standardize street_address.
  • You should expect street_address to be Title Cased, consistent and friendly for human reading. Please send us your feedback if you see otherwise.
  • If you care about street addresses as much as we do, we also have more specific address columns to split out address components. These are optional and available upon request for future deliveries!
    • primary_number
    • street_predirection
    • street_name
    • street_postdirection
    • street_suffix

naics_code, top_category, sub_category

  • SafeGraph Places uses the NAICS categorization taxonomy developed by the US Census Bureau that consists of a numeric NAICS code up to 6 digits in length.
  • The code itself is hierarchical; in other words, the first 2 digits describe a very general category, and additional digits describe more and more specific categories. For example:
    • 72 is the general category Accommodation and Food Services.
    • 722 is the more specific category Food Services and Drinking Places.
    • 7225 is the even more specific category Restaurants and Other Eating Places.
    • 722513 is the most specific category Limited-Service Restaurants (i.e. quick-serve or fast-food restaurants).
  • Category information is available for almost all our POI (see latest fill rate stats here). However, there are some businesses where we are not sure about the NAICS category; in these cases, NAICS will be left blank.
  • top_category and sub_category are the string labels associated with the first 4 digits and 6 digits of naics_code, respectively.

category_tags

  • Here is the full list of possible tags.. category_tags currently only supports POI belonging to NAICS "Food Services and Drinking Places" (i.e. the first three digits of the naics_code is 722). For these POI, SafeGraph provides a higher-granularity category informatio via category_tags. category_tags is a list of descriptive words about the POI. There is a fixed set of possible tags (see link above). There is no constraint on how many descriptors (tags) a POI can have; SafeGraph strives to label all relevant tags for every POI.

latitude & longitude

  • In general, latitude and longitude are defined by our best knowledge of the POI location. It is not designed to specifically locate the front door of the business, but rather defines the general center of the business.
  • Latitude and longitude still attempts to identify the individual business even if that business and others have the same polygon (e.g. strip mall).

open_hours

The new format for open hours is a JSON string with days as keys and opening & closing times (in the POI's local time) as values

  • Each JSON string is guaranteed to have all 7 days as keys
  • We indicate that a POI is closed for the day by giving it a value of "[]"
  • We indicate that a POI is open the entire day by using a format like:

"Thu": [["0:00", "24:00"]]

  • For POI that open and close multiple times throughout the day (e.g. a restaurant open in the morning and evening but not midday), we list multiple opening/closing pairs. For example:

“Sat": [["8:00", "13:00"], ["15:00", "22:30"]]

  • This indicates that a POI is open from 8 am to 1 p.m. and also from 3 p.m. to 10:30 p.m. on Saturday.

  • For POI that open and close on different days (e.g. a bar which opens at Tuesday at 6 p.m. and closes at Wednesday at 2 a.m.), we use a format like:

"Tue": [["18:00", "24:00"]], "Wed": [["0:00", "2:00"]]

To re-iterate: a “closing time” of 24:00 doesn’t mean the POI actually closes at midnight, if it’s followed by an opening time of 0:00 on the following day.

Example Open Hours JSON string

{ "Mon": [["8:00", "22:00"]], "Tue": [["8:00", "13:00"], ["18:00", "24:00"]], "Wed": [["0:00", "2:00"]], "Thu": [["0:00", "24:00"]], "Fri": [["23:00", "24:00"]], "Sat": [["0:00", "3:00"], ["15:00", "22:30"]], "Sun": [] }

This example represents the following open / close times:

  • Open from 8 a.m. to 10 p.m. on Monday
  • Open from 8 a.m. to 1 p.m. and 6 p.m. onwards on Tuesday
  • Open until 2 a.m. on Wednesday (note: open from Tuesday 6pm through 2am Wednesday)
  • Open all day on Thursday (i.e. midnight Wednesday to midnight Thursday)
  • Open from 11 p.m. onwards on Friday
  • Open until 3 a.m. and between 3 p.m. and 10:30 p.m. on Saturday
  • Closed on Sunday

phone_number

This is a 10 digit phone number. We filter out toll-free numbers (e.g. 1-800) and strive to have POI-specific numbers (not franchise-level or corporate-level numbers).

opened_on, closed_on, tracking_opened_since, tracking_closed_since

Open and closed on dates are determined from metadata at the source level. If a new POI from an existing source repeatedly appears in our build pipeline, it is flagged as opened_on during the month in which it first appears. Similarly, if a POI from an existing source repeatedly disappears in our build pipeline, it is flagged as closed_on during the month in which it first disappears. These flags are added to the Places product permitting final QA checks and overall data hygiene. Temporary closures of any kind are not captured in this tracking.

Some POIs have not yet been sourced consistently enough to provide the metadata needed to determine open or closed dates. These POIs will have a null value in the tracking_opened_since and/or tracking_closed_since columns. In general, the SafeGraph Places product tracks opened_on and closed_on dates from as early as 2019-07 onward, and therefore, the majority of POIs that have a tracking_closed_since date will show a value of "2019-07."

Please note that opened_on, closed_on, tracking_opened_since, and tracking_closed_since columns are specific to Core Places. These are not available in stand-alone Geometry or Patterns purchases. If Core is purchased in combination with Geometry and/or Patterns, the Geometry and Patterns specific fields will be null for any POIs with a closed_on date. Please reference the Column Ordering section of the Places Manual for details on where these columns exist per product combination.

Geometry

wkt

  • Spatial Reference used: EPSG:4326
  • WKT stands for Well-Known-Text. It’s a simple way to define a polygon/shape and is the standard format for polygons in SafeGraph Places.
  • Other geospatial file formats you may utilize include Shapefile and GeoJSON. WKT can easily be converted to these formats and file conversions are available by request.

Spatial Hierarchy

  • Some POIs are characterized by a broader footprint and cannot be represented by the outline of a single building. These types of POIs often encompass smaller POIs within their borders, and we try to flag where these overlapping relationships exist in the real world by setting the parent_safegraph_place_id of the smaller POI equal to the safegraph_place_id of the larger, encompassing POI. We colloquially refer to the larger, containing POI as the "parent" and the smaller POI as the "child."
  • If a POI is not contained by an overlapping polygon, the parent_safegraph_place_id will be null. Only POIs of particular categories can qualify as "parent" POIs. Below is the full list of sub_categories and corresponding naics_codes that have the potential to be parents:
 * Gasoline Stations with Convenience Stores (447110)
 * Malls (531120)
 * Elementary and Secondary Schools (611110)
 * Nature Parks and Other Similar Institutions (712190)
 * Other Gasoline Stations (447190)
 * Colleges, Universities, and Professional Schools (611310)
 * Correctional Institutions (922140)
 * Junior Colleges (611210)
 * Golf Courses and Country Clubs (713910)
 * Casinos (except Casino Hotels) (713210)
 * Casino Hotels (721120)
 * Hotels (except Casino Hotels) and Motels (721110)
 * Other Technical and Trade Schools (611519)
 * Amusement and Theme Parks (713110)
 * General Medical and Surgical Hospitals (622110)
 * Sports Teams and Clubs (711211)
 * Promoters of Performing Arts, Sports, and Similar Events with Facilities (711310)
 * Skiing Facilities (713920)
 * Other Airport Operations (488119)

polygon_class

  • We provide a polygon_class for each POI to identify how well the polygon reflects the POI itself.
  • In dense environments, such as indoor malls or multi-story buildings, we may not be confident about a POI’s true shape, so we provide the overall structure polygon instead. This results in several POIs sharing the same polygon. In other cases, we simply may not have a unique polygon for each POI, so several POIs end up sharing the same polygon. In each of these cases, the POIs would be classified as "SHARED_POLYGON" in the polygon_class column.
  • If a single POIs maps to a distinct polygon (excluding that POI's children), then the POI is classified as "OWNED_POLYGON" in the polygon_class column. We exclude children from influencing a POI's polygon_class because in cases where a unique polygon is not available for a child POI, the child POI most likely maps to the parent POI's polygon; however, that does not mean the polygon is not a good reflection of the parent. A good example of this would be a Nike store inside of a shopping mall. If we don't have a good polygon for the Nike store, then the Nike store may share the same polygon as the mall, but the polygon for the mall is still representative of the Mall's shape and size. For more details on parent-child relationships, see the Spatial Hierarchy section above.
  • If you need to differentiate unique stores within a shared polygon, you should use the POI centroids (the latitude and longitude columns). Since user GPS signals often drift inside of large structures, for use cases such as determining places visited by a user, we have found that user distance to centroid is a good substitute for distance to polygon.

includes_parking_lot

  • In some cases, our polygons intentionally include the parking lot since the parking lot (e.g., car dealerships and gas stations). The value of the includes_parking_lot column is to make explicit to our customers when the polygon_wkt does or does not include the parking lot. There are three possible values true, false, and null (null when we are not sure whether a parking lot is included in the geometry).

Patterns

raw_visit_counts

These are the aggregated raw counts that we see visit the POI from our panel of mobile devices.

These values should be taken in the context of specific nuances & biases in our dataset:

Geographic Bias

  • Small geographic bias exists in our panel based on our understanding of the home locations of the devices in the panel.
  • SafeGraph tested for geographic bias by comparing its determination of the state-by-state numbers of home location of the devices in the panel to the true proportions reported by the 2016 US Census.
  • Based on that analysis, SafeGraph panel density closely mirrors true population density. Overall average percentage point difference < 1%. Maximum +/-3% per state.
  • For a deep dive on geographic bias in the panel, see Quantifying Sampling Bias in SafeGraph Patterns.

Panel Growth

  • The panel has grown significantly since its inception. As such, it is important to normalize the data when doing time series analysis across long periods of time or multiple releases.
  • We have seen success by normalizing visits by the total number of visits in the SafeGraph Panel, month by month. It is also worth exploring normalizing based on state or census block group. With each delivery, we provide you with the Panel Overview Data files to enable you to do these calculations.

Predicting Financial Indicators
SafeGraph data can be used to estimate foot traffic and predict financial indicators of companies ( number of visitors, revenue, etc.). Please see Normalization White Paper: How to Use SafeGraph Visits Data to Predict Company Reported KPIs.

Correlation between reported company KPIs and SafeGraph visits will vary depending on multiple factors related to the company:

  • Does the business separately report online vs in-store sales and revenue.
  • How much do online sales contribute to the overall revenue.
  • How much revenue is generated outside of the USA (SafeGraph Visits are US only).
  • The ground truth correlation between foot traffic and sales for that business. e.g. the relationship between foot traffic and sales at a car dealership has a very different pattern than at a convenience store.

Visits to Dense Urban Areas

  • Visits to urban, suburban, and rural areas have varying precision levels. It is more difficult to measure visits to a midtown Manhattan Starbucks than a visit to a suburban standalone Starbucks.

Visits to Large Structures/Indoor Malls

  • We attribute visits to the containing element i.e. the indoor mall or airport, and not to any individual tenants. We believe this is the most accurate option given the limitations of GPS inside such structures (e.g., indoor malls, casinos, hotels).

Visits to Strip Malls

  • We attribute visits to the individual stores as well as the parent strip mall (assuming we have a POI for the entire strip mall). There will be instances where we have not divided a strip mall polygon into its constituent stores. Our model to determine visits does take a number of factors into account, including distance from centroid, so even though there are multiple POI in one strip mall polygon, we attempt to allocate visits within the strip mall to the POI most likely to have received the visit.

Worker & Non-Worker Visits

  • Prior to our May 2020 release, we attempted to exclude workers at a POI from our visit counts to the POI. However, we were only able to determine a limited number of workers so we decided to remove this filter. The best way to determine how many of the visitors to a POI are workers is by looking at the bucketed_dwell_time column.

GPS Data

  • The visits are determined using GPS data.
  • We do not include any GPS data with a horizontal accuracy greater than 160 meters.

raw_visitor_counts

  • These are the aggregated raw counts of visitors.

visits_by_day

  • This is an array of visits on each day in the month.
  • We are breaking up days based on local time.

poi_cbg

  • This is the census block group that the POI resides within as determined using the centroid of the POI.

visitor_home_cbgs

  • These are the home census block groups of the visitors to the POI.
  • For each census block group, we show the number of associated visitors (as opposed to the number of visits).
  • We do not have a home census block group for each visitor and not each visitor originates from the U.S. The number of U.S. visitors listed in the visitor_country_of_origin column represents the total number of visitors which we have determined originate from the U.S.
  • We apply differential privacy to the counts. We do not include a census block group unless there are at least 2 visitors from that census block group. If there are between 2 and 4 visitors from a census block group, we show this as 4.
  • We determine the home census block group by analyzing 6 weeks of data during nighttime hours (between 6 pm and 7 am). We require a sufficient amount of evidence (total data points and distinct days) to assign a home (common nighttime) location for the device.
  • The census block group is the highest geographic resolution for which the US Census provides demographic information. This demographic data is publicly available through APIs maintained by the US Census. SafeGraph provides census block group demographic data to download for free. There are also resources for developers on Github and Stackoverflow for working with the US Census APIs. Some of the most common APIs are the Population Estimates API and the Decennial Census
  • See also: How do I work with Patterns columns that contain JSON

visitor_work_cbgs

  • These are the work census block groups of the visitors to the POI.
  • For each census block group, we show the number of associated visitors (as opposed to the number of visits).
  • We determine the work census block group of a device by looking at 1 month of data and determining where the device is most frequently during traditional work hours and is not during the weekend or overnight. It is easier to determine a home/common nighttime location of a device than it is to determine the work census block group so our data contains more home_cbgs than work_cbgs.
  • We apply differential privacy to the counts. We do not include a census block group unless there are at least 2 visitors with a work census block group in that census block group. If there are between 2 and 4 visitors with a work census block group in a census block group, we show this as 4.
  • See also: How do I work with Patterns columns that contain JSON

visitor_country_of_origin

  • These are the countries of origin of the visitors to the POI.
  • We determine the country of origin by analyzing 6 weeks of data during nighttime hours (between 6 pm and 7 am). We require a sufficient amount of evidence (total data points and distinct days) to assign a common nighttime location for the device. The country of this common nighttime location is the specified country of origin.
  • We apply differential privacy to the counts. We do not include a country unless there are at least 2 visitors from that country. If there are between 2 and 4 visitors from a country, we show this as 4.
  • See also: How do I work with Patterns columns that contain JSON

distance_from_home

  • This is the median distance from home to the POI in meters for the visitors we have identified a home location.
  • If we have fewer than 5 visitors to a POI, the value will be null.
  • We do not adjust for visits -- each visitor is counted equally.

median_dwell

  • This is the median of the minimum dwell times we have calculated for each of the visits to the POI.
  • We determine the median dwell time by looking at the first and last ping we see from a device during a visit. This is a minimum dwell because it is possible the device was at the POI longer than the time of the last ping.
  • It is possible to have a minimum dwell of 0 if we only saw 1 ping and determined the visit based on factors such as wifi.

bucketed_dwell_times

related_same_day_brand

These are the brands that the visitors to this POI visit (on the same day that they visit the POI) in higher numbers than the general members of our panel. The number mapped to each brand is an indicator of how highly correlated a POI is to a certain brand beyond what we are seeing generally in the panel. For example, if a lot of visitors to Starbucks at 123 Main Street also tend to visit an unpopular brand on the same day, the number could be quite high (e.g., > 50) whereas if the same number of 123 Main Street Starbucks visitors also visit Targets on the same day, the number will be lower because Target is a popular brand.

See also: How do I work with Patterns columns that contain JSON

If you want to know the nitty-gritty of how we calculate this index, read on at your own risk:

  • For each day in the month, we find the total number of visitors who went to both the POI and another branded location. For each brand, we divide this number by the total number of visitors to the POI. This gives us our "POI Specific Brand Ratios" for each brand for each day in the month.
  • For each day in the month, we find the number of visitors who went to each brand divided by the total number of visitors in the Panel. This gives us our "Baseline Brand Ratios" for each brand for each day in the month.
  • For each brand, we take the POI Specific Brand Ratio for each day of the month and subtract from it the corresponding Baseline Brand Ratio (the "Daily Percentage"). We then take the median of the differences. If the result is greater or equal to 5%, we include the brand in the list.
  • In determining the median we exclude any POI Specific Brand Ratios that are 0.
  • Note that the final number is rounded so it is possible to have 100 (likely because the applicable Baseline Brand Ratio is less than 0.5%).

For example, if on the first of the month, 20 visitors out of 100 that went to a certain SoulCycle POI also went to a Sephora while in the Panel generally, only 2 out of 100 visitors went to a Sephora, the Daily Percentage would be 18% (20/100 - 2/100). This 18% would be included with the other Daily Percentages for the month to determine the median of those numbers.

related_same_month_brand

These are the brands that the visitors to this POI visit in higher numbers than the general members of our panel over the course of the month. The number mapped to each brand is an indicator of how highly correlated a POI is to a certain brand beyond what we are seeing generally in the panel. For example, if visitors to Starbucks at 123 Main Street also tend to visit an unpopular brand a lot, the number could be quite high (e.g., > 50) whereas if the same number of 123 Main Street Starbucks visitors also visit Targets a lot, the number will be lower because Target is a popular brand.

See also: How do I work with Patterns columns that contain JSON

If you want to know the nitty-gritty of how we calculate this index, read on at your own risk:

  • For the entire month, we find the total number of visitors who went to both the POI and another branded location. For each brand, we divide this number by the total number of visits to the POI. This gives us our "POI Specific Brand Ratios" for each brand.
  • For the entire month, we find the number of visitors who went to each brand divided by the total number of visitors in the Panel. This gives us our "Baseline Brand Ratios" for each brand.
  • For each brand, we take the POI Specific Brand Ratio and subtract from it the corresponding Baseline Brand Ratio. If the result is greater or equal to 5%, we include the brand in the list.
  • Note that the final number is rounded so it is possible to have 100 (likely because the applicable Baseline Brand Ratio is less than 0.5%).

For example, if for the entire month 20 visitors out of 100 that went to a certain SoulCycle POI also went to a Sephora while in the Panel generally, only 2 out of 100 visitors went to a Sephora, the percentage would be 18% (20/100 - 2/100).

popularity_by_hour

  • This is an array of visits seen in each hour of the day over the course of the month.
  • Local time is used.
  • If a visitor stays for multiple hours, an item in the array will be incremented for each hour during which the visitor stayed. This means that if you sum the numbers in the popularity_by_hour array the sum will likely be greater than the amount shown in the raw_visit_counts column (since the raw_visit_counts counts a multiple hour visit as one visit).

popularity_by_day

device_type

  • This shows how many visitors to the POI use android vs. iOS.
  • We apply differential privacy to the counts. We do not include a device type unless there are at least 2 visitors with that device type. If there are between 2 and 4 visitors with that device type, we show this as 4.
  • See also: How do I work with Patterns columns that contain JSON

Privacy

To preserve privacy, we apply differential privacy techniques to the following columns: visitor_home_cbgs, visitor_daytime_cbgs, visitor_work_cbgs, visitor_country_of_origin, device_type, carrier_name.
We have added Laplacian noise to the values in these columns. After adding noise, only attributes (e.g., a census block group) with at least two devices are included in the data.

Column Ordering

Files are delivered in a joined format when more than one product is purchased, and the exact column ordering depends on the product combination. If column order matters to you, take heed and reference the breakdown of column orders below:

*only pertinent to files including closed POIs

Core+Geometry+Patterns

[core_poi-geometry-patterns.csv]

safegraph_place_id

parent_safegraph_place_id

safegraph_brand_ids

location_name

brands

top_category

sub_category

naics_code

latitude

longitude

street_address

city

region

postal_code

open_hours

category_tags

*opened_on

*closed_on

*tracking_opened_since

*tracking_closed_since

polygon_wkt

polygon_class

phone_number

is_synthetic

includes_parking_lot

iso_country_code

date_range_start

date_range_end

raw_visit_counts

raw_visitor_counts

visits_by_day

poi_cbg

visitor_home_cbgs

visitor_daytime_cbgs

visitor_work_cbgs

visitor_country_of_origin

distance_from_home

median_dwell

bucketed_dwell_times

related_same_day_brand

related_same_month_brand

popularity_by_hour

popularity_by_day

device_type

carrier_name

Core+Geometry

[core_poi-geometry.csv]

safegraph_place_id

parent_safegraph_place_id

safegraph_brand_ids

location_name

brands

top_category

sub_category

naics_code

latitude

longitude

street_address

city

region

postal_code

open_hours

category_tags

*opened_on

*closed_on

*tracking_opened_since

*tracking_closed_since

polygon_wkt

polygon_class

phone_number

is_synthetic

includes_parking_lot

iso_country_code

Core+Patterns

[core_poi-patterns.csv]

safegraph_place_id

parent_safegraph_place_id

location_name

safegraph_brand_ids

brands

top_category

sub_category

category_tags

naics_code

latitude

longitude

street_address

city

region

postal_code

iso_country_code

phone_number

open_hours

*opened_on

*closed_on

*tracking_opened_since

*tracking_closed_since

date_range_start

date_range_end

raw_visit_counts

raw_visitor_counts

visits_by_day

poi_cbg

visitor_home_cbgs

visitor_daytime_cbgs

visitor_work_cbgs

visitor_country_of_origin

distance_from_home

median_dwell

bucketed_dwell_times

related_same_day_brand

related_same_month_brand

popularity_by_hour

popularity_by_day

device_type

carrier_name

Geometry+Patterns

[geometry-patterns.csv]

safegraph_place_id

parent_safegraph_place_id

loaction_name

safegraph_brand_ids

brands

latitude

longitude

street_address

city

region

postal_code

iso_country_code

polygon_wkt

polygon_class

includes_parking_lot

is_synthetic

date_range_start

date_range_end

raw_visit_counts

raw_visitor_counts

visits_by_day

poi_cbg

visitor_home_cbgs

visitor_daytime_cbgs

visitor_work_cbgs

visitor_country_of_origin

distance_from_home

median_dwell

bucketed_dwell_times

related_same_day_brand

related_same_month_brand

popularity_by_hour

populairty_by_day

device_type

carrier_name

Delivery Cadence and Directory Structure

Updated a day ago


Places Manual


This document provides details on attribute methodology and answers frequently asked questions (FAQs) about the nuances of the SafeGraph Places dataset.

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.