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_tagsGeneric: Places outside of naics_code like '72%'

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 Enhanced: Places where naics_code like '72%'

As of March 2025, SafeGraph released and enhanced version of category_tags for places where naics_code like '72%' (Accommodation and Food Services). The following details only apply to places where naics_code like '72%'.

Refined Definition

A large part of the enhanced version is 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.

More Data and More Structure

• Expanded values: +100 new, 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

Amenity columns capture relevant facts and features about places where naics_code like '72%' (Accommodation and Food Services) only. Contact SafeGraph to review the full list of 100+ possible values found in amenity columns.

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"]]

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)

Open/close column definitions

opened_on: The year and month this POI opened in yyyy-mm format. If null, then we do not have enough metadata to determine an open date.

closed_on: The year and month this POI closed in yyyy-mm format. If null, then this POI is open.

tracking_closed_since: The year and month we started tracking closed_on for this POI.

• This column indicates whether it's possible for SafeGraph to capture POI closures.
  • If tracking_closed_since is null, then we are unable to provide a closure date for this POI if/when it closes in reality. In most cases, the POI will drop from our data when it closes.
    • Note: A handful of POIs with a non-null closed_on date but null tracking_closed_since exist. These are rare and are the result of manually applied closed_on corrections.
  • If tracking_closed_sinceis not null, then we can/should provide a date if/when the POI closes.

Scope: Which POI does SafeGraph determine open/close for?

• Brands vs Non-Branded:
  • opened_on dates are only inferred for POIs with a safegraph_brand_id ("branded" POIs)
  • closed_on dates are inferred for both branded and non-branded POIs.
• Geography: Open/Close features are actively supported in the following 25 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'
  • iso_country_code = 'AU'
  • iso_country_code = 'AT'
  • iso_country_code = 'BE'
  • iso_country_code = 'CZ'
  • iso_country_code = 'DK'
  • iso_country_code = 'HU'
  • iso_country_code = 'ID'
  • iso_country_code = 'IE'
  • iso_country_code = 'MY'
  • iso_country_code = 'NL'
  • iso_country_code = 'NZ'
  • iso_country_code = 'NO'
  • iso_country_code = 'PL'
  • iso_country_code = 'PT'

*A handful of POIs outside of the 25 supported countries have opened_on and closed_on dates. These values were either 1.) Inferred prior to narrowing on a supported country list or 2.) Manually applied as a correction. These values will remain in the data, but additional open/close dates should not be expected at scale outside of the supported country list.

Caveats and known issues

• Accuracy

  • POIs with an opened_on or closed_on date have been determined to be accurate within a ~60 day margin of error, and the margin of error is relatively smaller for POIs with a safegraph_brand_id ("branded" POIs).

• Temporary Closures

  • Temporary closures are not captured in open/close columns.

• Interpreting Dates and Date Anomalies

  • Starting Dates

    • SafeGraph first released opened_on and closed_on in July 2019. Therefore, the majority of open/close dates are from '2019-07' onwards. POIs with open/close dates preceding '2019-07' are rare and are the result of manually applied corrections. We do not support historical open/close dates at scale.

  • Unknown Closure Dates

    • closed_on = '1900-01' implies that the POI is permanently closed, but we are not confident in the exact closure date.

  • March 2020 - June 2020 (closed_on values between '2020-03 and '2020-06')

    • 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_onvalues between '2020-03' and '2020-06' as we erred towards the side of caution to not mistakenly mark temporarily closed businesses as permanently closed.

  • March and April 2022 (closed_on = '2022-03' and '2022-04')

    • Covid catch-up: As we caught up on permanent closures post COVID, March and April 2022 saw a spike in closed_ondates. This took place prior to assigning closed_on = '1900-01' for unknown closure dates, so some of the POIs with these dates may extend well past a ~60 day window of actual store closure accuracy.

  • May 2023 and March 2024 (closed_on = '2023-05' and '2024-03')

    • Closed POI modeling improvements lead to an increase in closed_on detection. This took place prior to assigning closed_on = '1900-01' for unknown closure dates, so some of the POIs with these dates may extend well past a ~60 day window of actual store closure accuracy.

How does SafeGraph determine open/close?

• We use the following method to infer opened_on for branded POIs:

  • If a new POI/record from an existing store locator appears in consecutive crawl updates, it is flagged as
    opened_on during the month in which it first appeared.

• We use the following methods to infer closed_on for branded POIs:

  • If an existing POI/record from an existing store locator disappears in consecutive crawl updates, it is flagged as closed_onduring the month in which it first disappears.
  • We also trace branded POIs through various third party sources each month to verify the open/close opinion derived from store locator crawl updates. In some cases, there is enough 3rd party evidence to reverse our store locator opinion.
  • We also leverage an ML model that looks for "likely closed signal" in the combined metadata across all sources for a POI.
    • For example: A POI has 650 total reviews with an average volume of 20 reviews/month. If the last review date for this POI is > 45 days old, then this POI is more than likely closed. This, in combination with 3rd party validation, can infer or override a previously inferred closed_on date.

• We use the following methods to infer closed_on for non-branded POIs:

  • We trace non-branded POIs through various third party sources each month to gauge majority sentiment/agreement on POI closure. We also leverage the ML model that looks for "likely closed signal" in the combined metadata across all sources for a POI.

Store locators are typically the best authority for brand coverage and freshness, but you'd be surprised how often a company's locator is wrong! A broken or stale locator jeopardizes our store locator derived open/close logic, so we layer in 3rd party validation and modeling as a back-up for brands and as the default for non-branded POIs. 3rd parties may also be blind or delayed to openings/closings in some cases, so errors still persist despite this multi-pronged effort.

We're constantly looking for new methods, new sources, etc. to improve our open/close data, and your feedback is wanted! Diagnosing what/how specific POIs slipped through the cracks is the best way for us to quickly solution new fixes.

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.