Rich Attributes

Our Rich Attributes expand on the standard details about a Place to provide even more meaningful metadata. More granular category tags. Open hours. Closed On Dates. And much more.

Contents

• Column Definitions for definitions and in depth details
• Key Concepts relevant to our Places data
• Known Artifacts for any nuance to the dataset

Helpful Links

• Places Data Schema
• Rich Attributes Schema

Column Definitions: Rich Attributes

category_tags

SafeGraph assigns category_tags to supplement NAICs descriptions (top_categoryandsub_category) with more granular category information. For example, an upscale, Japanese restaurant that primarily serves sushi might have category_tags = '[Japanese Food, Sushi, Fine Dining]'. These descriptions help narrow on a desired set of places meeting specific parameters both within a single naics_code or across multiple naics_codes.

category_tags are generally available across many categories and countries, but null values exist if the POI does not have an applicable naics_code for our current list category_tags , or due to metadata limitations. See here for the full list of possible category_tags for each NAICS code.

category_tags Improvements [March 2025 Release!] 🎉

In the March 2025 release, SafeGraph is re-introducing category_tags, featuring a variety of improvements, as well as several new rich attributes describing other relevant facts about a place (see amenity columns). The following updates and definitions apply to global places where naics_code like '72%' (Accommodation and Food Services) only. Expansion into additional categories is expected in subsequent releases.

Improvements

• REFINED DEFINITION: As a part of our improvement effort, we are clearly defining which values belong in category_tags vs which belong in a separate amenity column intended to answer different sets of questions about a place. As a guiding rule, all possible category_tag values should be a suitable answer to the following question: "What words/phrases best describe this place or what type of food/goods does it sell?"
  • ❌Old Definition: An array of descriptive tags indicating higher-resolution category information. ❌
  • ✅New Definition: An array of alphabetically ordered values describing the granular category, and/or cuisine, and/or common dish/good for a place.
    • "Granular category" examples:
      • 'Dive Bar' for a place with naics_code = 722410 (Drinking Places (Alcoholic Beverages))
      • 'RV Park' for a place with naics_code = 721110 (Hotels (except Casino Hotels) and Motels)
    • "Cuisine" examples:
      • 'Latin American Food', or 'Mexican Food', or 'Oaxacan Food' for a place with naics_code = 722511 (Full-Service Restaurants)
    • "Common dish/good" examples:
      • 'Bagels', or 'Coffee', or 'Pastries' for a place with naics_code = 722515 (Snack and Nonalcoholic Beverage Bars)
  • category_tag values DO NOT capture other amenities/features like 'Delivery', 'Wifi', 'Dinner', 'Fitness Center', 'Drive Through', 'LGBTQ+ Friendly', ‘Accepts Credit Cards’, etc. This information can be found in the new amenity columns.
  • Per this refined definition, some previously existing category_tag values will see a slight textual change, will move to a new amenity column with a better fitting definition, or will deprecate entirely. See here for a complete mapping of all previously existing values with a change in March 2025.
    
    
• FILL RATE: Increase in the total number of places with category_tags📈

• ADDITIONAL VALUES: 100+ sensical, category_tag values tailored to common user queries
  • See here for the universe of possible values for places where naics_code like '72%'

• HIERARCHY: Interpret when category_tags are sub-values of other category_tags through our published hierarchy here.

Amenity Columns

Available in the March 2025 release! 🎉 Amenity columns capture relevant facts and features about places where naics_code like '72%' (Accommodation and Food Services) only. See here for a universe of possible values for each column and below for further detail.

accessibility

As a guiding rule, all possible accessibility values should be a suitable answer to the following question (but not a suitable answer to other amenity columns): "How can I get there and am I able to get around there?"

• Definition: An array of alphabetically ordered values describing various access methods and options.
• Example: '[Parking, Wheelchair Accessible Parking, Wheelchair Accessible Restroom]'
• Data Type: List

activities

As a guiding rule, all possible activities values should be a suitable answer to the following question (but not a suitable answer to other amenity columns): "What can I do while I’m there?"

• Definition: An array of alphabetically ordered values describing common, on-site activities.
• Example: '[Karaoke, Pool and Billiards, Trivia]'
• Data Type: List

amenities

As a guiding rule, all possible amenities values should be a suitable answer to the following question (but not a suitable answer to other amenity columns): "What things do they offer to use while I’m there?"

• Definition: An array of alphabetically ordered values describing general, on-site amenities.
• Example: '[Bar On-site, Restroom, Wifi]'
• Data Type: List

owner_demographic

As a guiding rule, all possible owner_demographic values should be a suitable answer to the following question (but not a suitable answer to other amenity columns): "What type of people run this place?"

• Definition: An array of alphabetically ordered values describing how the business owner self-identifies.
• Example: '[Black Owned, Women Owned]'
• Data Type: List

payment_options

As a guiding rule, all possible payment_options values should be a suitable answer to the following question (but not a suitable answer to other amenity columns): "How can I pay for things there?"

• Definition: An array of alphabetically ordered values describing accepted methods of payment.
• Example: '[Cash, Credit Card, Debit Card]'
• Data Type: List

service_options

As a guiding rule, all possible service_options values should be a suitable answer to the following question (but not a suitable answer to other amenity columns): "What kind of meals do they serve, what are my options, and how can I get it?"

• Definition: An array of alphabetically ordered values describing the types of meals offered along with service options.
• Example: '[Accepts Reservations, Breakfast, Carry Out, Delivery, Happy Hour, Lunch, Dinner]'
• Data Type: List

setting

As a guiding rule, all possible setting values should be a suitable answer to the following question (but not a suitable answer to other amenity columns): "How will it look, feel, and sound while I’m there?"

• Definition: An array of alphabetically ordered values describing the general atmosphere and typical crowd at a place.
• Example: '[Family Friendly, Kid Friendly, Moderate Noise, Touristy, Upscale]'
• Data Type: List

domains

The top-level domain(s) for the website(s) associated with the POI as provided and maintained by the POI itself. These will be provided as the domain names relevant to the business or operation in place at a given location. If there are multiple relevant domains (e.g. a unique website for a hotel but also the umbrella hotel chain website) we will include as many as relevant. Prior to June 2023, this had been known as the websites column.

website

The web URL for the POI's publicly available website. This will only be populated if a website exists specifically dedicated to the place, not just if for example there is an overarching corporate website. This attribute was introduced in the June 2023 release.

phone_number

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

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 pm and also from 3 pm to 10:30 pm on Saturday.
• For POI that open and close on different days (e.g. a bar which opens on Tuesday at 6 pm and closes on Wednesday at 2 am), we use a format like:
  • "Tue": [["18:00", "24:00"]], "Wed": [["0:00", "2:00"]]

opened_on, closed_on, tracking_closed_since

These columns reflect the dates surrounding the known openings or closings of certain businesses. See our commentary on Determining when POI Open and Close for detailed information on our approach.

store_id

Store_id is the unique ID associated with a store as provided and maintained by the store/brand itself. This is a premium column only applicable to places with a safegraph_brand_id. Most store_ids can be found directly on store locators, but in some cases, the store_id is embedded within the store locator URL for the specific store. Note that there is no single source of truth for store_ids, and some first party datasets may not define store_id in the same manner which SafeGraph does, but we strive to provide the most widely used concept of store_id.

Typically, store_ids are alphanumeric codes unique to each location. However, they are not always alphanumeric. For example the store number for this store is 1615.

store_id is especially useful as join key when working with transaction data. For example, “TJ256Y8” may be the only location specific information within a transaction dataset. A Places dataset which also contains "TJ256Y8" as a store_id enables a join to contextualize transaction data (or other internal, store-level data) with SafeGraph places information.

Determining POI Open/Close (opened_on, closed_on, tracking_closed_since)

opened_on 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. opened_on dates are only inferred for POIs with a safegraph_brand_id whereas closed_on dates are attempted for both branded and non-branded POIs. POIs with an opened_on or closed_on date have been determined to be accurate within a ~60 day margin of error.

Open/Close features are currently supported in the following 11 countries:

• iso_country_code = 'US'
• iso_country_code = 'CA'
• iso_country_code = 'GB'
• iso_country_code = 'DE'
• iso_country_code = 'FR'
• iso_country_code = 'ES'
• iso_country_code = 'IT'
• iso_country_code = 'MX'
• iso_country_code = 'JP'
• iso_country_code = 'CN'
• iso_country_code = 'SG'

For supported countries, if a POI has not yet been sourced consistently enough to provide the metadata needed to determine closed_on dates, then it will have a null value in the tracking_closed_since column. Outside of supported countries, the tracking_closed_since column should be ignored. 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.'

We know that some POIs are permanently closed but are not confident in the exact closure date. These POIs show closed_on = '1900-01' to denote this uncertainty.

Note that temporary closures are not captured in open/close tracking. It became difficult to distinguish permanent closures from temporary closures at the onset of COVID-19, and this resulted in a relatively low count of POIs with closed_on values between "2020-03" and "2020-06" as we erred towards the side of caution to not mistakenly mark temporarily closed businesses as permanently closed.

As we caught up on permanent closures post COVID and invested in open/close model improvements, the following spikes are reflected in closed_on dates - which may extend past a ~60 day window of actual closure:

• March 2022 (closed_on = '2022-03')
  • Covid catch-up
• April 2022 (closed_on = '2022-04')
  • Covid catch-up
• May 2023 (closed_on = '2023-05')
  • Model improvement
• March 2024 (closed_on = '2024-03')
  • Model improvement

Place Format

The place_format column applies to specific brands or categories that adhere to a widely adopted classification system that specifies the POI's layout or format type. Each brand or category with this feature includes a dictionary for its values.

Place Format Definitions

Shopping malls (US and Canada only; naics_code = 531120)

MCC

Merchant Category Codes (MCCs) classify businesses based on the type of goods or services they offer. These codes are widely used across payment ecosystems to categorize, track, and analyze transactions, offering valuable insights into merchant types.

This information is displayed as an array of all possible MCCs associated with the business and is ordered from most to least common MCC used by the businesses point of sale (POS) systems. For example, [5942, 5814, 5945] can be interrupted as the POI primarily uses mcc = '5942' at its POS but may also use mcc = '5814' followed by mcc = '5945'.

Note: Although mcc is supported globally, the MCC code is not inferred from underlying POS systems outside of the US and is instead inferred from the POI's naics_code. POIs outside of the US will only have a single MCC value.