Spend

SafeGraph’s Spend dataset contains anonymized debit and credit card transaction data aggregated to individual places in the U.S.

Gain insights on how spend behavior is changing over time at specific points of interest (POI), including the average transaction size, spend in-person vs. online, spend by customer demographics such as income, and spend by customer loyalty.

This data is ideal for:

• Competitor Analysis (e.g., In which markets are store sales growth outperforming competitors?)
• Site Selection (e.g., What co-tenants drive sales volume for individual stores within a brand?)
• Impact Measurement (e.g., Where did sales go up the most for our new product launch?)

and any other use-cases where dynamic spend insights at individual locations are paramount.

Spend is aggregated at a monthly time interval, and delivered on the 20th after each month's end. Historic Spend data is available back to January 2019.

Check out our Spend Summary Statistics page for detailed information on our coverage.

Contents:

• Schema
• Key Concepts

Spend Schema

spend.csv [reference file name for enterprise deliveries]

Spend contains many columns which are of JSON type (e.g., bucketed_customer_frequency). Please see our FAQs page here for guidance on how to work with these columns.

Note that Spend is bundled with Places which provides address information, geo-coordinates, industry categorizations and more.

🛡 We do not report data unless at least 2 customers are observed from that group. Differential privacy is also applied to these columns for further anonymization See more on privacy here.

Cross Shopping Columns

[New additional columns added in July 2022]

See additional notes below on how brand and merchant names are handled in these columns and which carriers/services are allowable for related_wireless_carrier_pct, related_streaming_cable_pct, related_delivery_service_pct, related_rideshare_service_pct, related_buynowpaylater_service_pct, and related_payment_platform_pct columns.

Panel Overview Data

Along with the Spend file, we also deliver Panel Overview Data (see table below) to help you better understand the context of the data appearing in Spend.

Transaction and Customer Distributions by State

[transaction_panel_summary.csv]

Key Concepts

Geographic Bias

Small geographic bias exists in our panel based on our understanding of the home locations of the customers in the panel. SafeGraph tested for geographic bias by comparing its determination of the state-by-state numbers of home location of the customers in the panel to the true proportions reported by the 2019 US Census. Based on that analysis, SafeGraph panel density closely mirrors true population density. The overall average percentage point difference is < 1% with a maximum of +/-4% per state. For a deep dive on geographic bias in the panel, see Quantifying Sampling Bias in SafeGraph Spend.

Correlations with Quarterly Revenue

When rolled up to the parent brand, SafeGraph Spend data can be compared against financial indicators of companies (eg. quarterly revenue). SafeGraph uses such tests as a benchmark even though the use cases of Spend are far more varied than aggregating by brand. Based on one such analysis, SafeGraph data track with quarterly revenue from major brands like McDonald's, Chipotle, and Target, including cases where companies report online sales separately than overall revenue (e.g., Chipotle). Read more about that analysis in our blog.

Date Granularity

• The underlying transaction data being aggregated are only resolvable at the daily level. Therefore, columns such as date_range_start and date_range_end that are provided down to the hour level are done so to facilitate consistent joining to other SafeGraph datasets, and not reflective of the actual granularity of the transaction timing.
• Furthermore, whenever possible, the transaction dates used in spend_by_day, spend_per_transaction_by_day, spend_by_day_of_week reflect the date of the actual transaction. However, for some transactions, the date reported is instead the date processed by the financial institution, which is typically the next business day.
  • This means that Saturday and Sunday spend will appear lower in the data and Monday will be appear higher (i.e., Sat/Sun spend being attributed to Mon), but this only affects these three columns.
  • Debit (a.k.a. bank) card transactions are also more likely than credit card transactions to have this bias, so weekend numbers are more likely to reflect credit card transactions.
  • Note that we have provided a column called day_counts which is simply a count of how many of each day occurred in the given month (e.g., there were 4 Tuesdays in the month). You can use this column to determine whether an increase in spend in a given month is due to a real phenomena or due to the fact that there were more Mondays in the given month.

Online vs In-Person Transactions

• Prior to being aggregated to POIs, individual transactions are classified by origin as online or in-person based on a proprietary model leveraging information about the transaction, the merchant, the customer, and other factors.
• This allows us to understand what proportion of transactions attributed to a POI (and their corresponding spend) were made physically versus online.
• Certain POIs lend themselves more to online versus in-person transactions. For example, self-storage POIs are more likely to have online transactions where payment is not made at the physical location. On the other end of the spectrum, gas station POIs are more likely to have in-person transactions where payment is made at the physical location.
• Note that online transactions that cannot be tied to an individual physical location will not be included in columns such as raw_total_spend, raw_num_transactions, etc. For example, purchases made online and shipped directly to a residence may not reference a specific store because they might be filled from a warehouse or distribution center. Whereas a "buy online, pick up in store" presents a connection to a physical store.
  • There is one exception to this general rule: transactions that cannot be tied to a physical location (whether online or offline) are included in cross-shopping columns (e.g., related_cross_shopping_physical_brands_pct, related_cross_shopping_online_merchants_pct, etc).

Transaction Intermediaries

• Transaction intermediaries can be apps that facilitate the transaction between the POI and the customer (e.g., DoorDash for restaurant POIs.
• They can also be payment processors through which the transaction takes place (e.g., Apple Pay)
• Transactions can also have multiple intermediaries. Paying for a DoorDash order through Apple Pay would mean there would be a 1 in Apple Pay and also in DoorDash.
• There is also some nuance with specific values which show up in this column:
  • No Intermediary does not mean that the transaction was via cash or anything like that. It means either no intermediary metadata was available and/or it was a direct bank or credit card charge.
  • Similarly, Visa as an intermediary does not mean they used a Visa card. Visa has a shared checkout option similar to Paypal, that's what the "Visa" intermediary means in that context.
  • Similarly with Square: mostly this means the store has a Square POS system, but there are Square intermediaries that aren't necessarily POS, e.g., Square Online, so "Square" would cover that payment processing method as well.

Customer Information

• Each customer in the panel is classified into an income class using a proprietary model based on his or her transactions and spending data.
• Similarly, each customer's home city and state are estimated using a proprietary model based on where the user makes the majority of their transactions.
• Note that we do not provide any individual-level data in this dataset, and these models are used solely for aggregating demographic information about customers to points of interest. A reminder that both of these columns are subject to differential privacy, implemented specifically to remove the possibility of identifying individuals with this data. See Privacy for more.

Brand and Merchant Keys in Cross Shopping Columns

• For all columns with brands in the column name, the keys in the JSON indicate SafeGraph brands with a corresponding entry in the Brand info file. See also Places > Brands.
• All other cross shopping columns use a different set of names (distinguished from SafeGraph brands by referencing them as merchants rather than brands) to accommodate entities without physical locations such as Netflix and Spotify.
  • Almost all of the time, these names are identical to the SafeGraph brand name where there is overlap; however, please note there are some notable differences (e.g., Apple is the online merchant name while Apple Retail Store is the corresponding SafeGraph brand).

Allowable Merchants in Certain Cross Shopping Columns

• Certain cross shopping columns also only allow a fixed set of merchants, as indicated by the table below. These merchants were selected based on popularity in the transaction dataset, meaning less ubiquitous brands are less likely to be included.
• If you think a certain merchant should be added to a particular column, please let us know.

Privacy

To preserve privacy, we apply differential privacy techniques to the following columns: bucketed_customer_income and customer_home_city.

We have added Laplacian noise to the values in these columns. After adding noise, only attributes (e.g., a city) with at least two customers are included in the data. For these columns, we do not report data unless at least 2 visitors are observed from that group.

We take the added precaution of ensuring no city can appear in customer_home_city if <4 panelists have that home city assigned. This is to prevent de-identifying panelists who come from rare or unique cities.