You are here:
Billing Considerations for Data Graphs
Use of data graphs impacts the consumption of credits in these usage types. Use Digital Wallet to check which consumption cards are active in your org, find out how many credits are available on each card, and determine how many credits have been consumed in each usage type. Some usage types aren’t metered for certain licenses or editions, such as a Data 360 Profiles license or Agentforce 1 Edition. Check your licenses and review license documentation for more information.
This feature has access to Digital Wallet, a free account management tool that offers near real-time consumption data for enabled products across your active contracts. Access Digital Wallet and start tracking your org's usage. To learn more, see About Digital Wallet.
| Digital Wallet Card | Usage Type | Usage Type Description | Notes |
|---|---|---|---|
| Data Services | Batch Data Transforms | Usage is calculated based on the higher of the number of rows read or number of rows written. For incremental batch data transforms, after the first time a transform runs, usage is based on the number of rows that have changed since the previous run. |
Both batch and streaming data transform meters are essential to keep the data graphs updated. The cost of a data graph refresh isn’t determined exclusively by the amount of data changed. Instead, it depends on refresh frequency, data model structure, and the fields updated. In certain scenarios, a single change to a DMO can trigger updates to a large number of data graph profiles. For example, if the product category for a product is updated, all data graph profiles associated with that product can be refreshed, potentially resulting in thousands of profile updates. |
| Flex Credits | Data 360 Prep | Usage is calculated based on the data object type. For local data lake objects and data model objects, the number of rows used for billing calculations is limited to the number of rows in the object. For external data lake objects, the actual count of rows read or written is used. This number can exceed the number of rows in the object if an object’s rows are read multiple times in a single transform run. For incremental batch transforms, after the first time a transform runs, usage is calculated based on the number of rows that changed since the previous run. For batch calculated insights, usage is calculated based on the number of records in all underlying objects used in creating the Calculated Insight each time it runs. |
|
| Data Services | Streaming Data Transforms | Usage is calculated based on the number of records processed. | |
| Flex Credits | Data 360 Streaming Pipeline | Usage is calculated based on the data object type. For streaming data ingestion, usage is calculated based on the number of rows of streaming data processed by Data 360 across all data streams with stream processing, with the exception of structured data that is ingested via the Internal Data Pipeline. Data streams that report usage with this usage type are streams created by Website and Mobile App Connector and streaming ingestion API. For streaming data transforms and streaming calculated insights, usage is calculated based on the number of records processed. For streaming data actions, usage is calculated based on the number of records processed in the DMO. Records processed are based on the number of new records created or updated in the DMO per activation. If a data graph is being used with the activation, the number of records processed will be doubled in the final calculation. For example, when a data graph is being used with the activation, if there is 1 new record change in the DMO, this will count as 2 records processed. |
|
| Data Services | Data Queries | Usage is calculated based on the number of records processed. The count of records processed depends on the structure of a query as well as other related factors such as the total number of records in the objects being queried. |
When a data graph includes a participating DMO from an external lake, querying the data graph may consume data federation credits. Usage is measured using meters such as data federation or sharing rows accessed, or data query storage usage, and can be billed using a different credit multiplier than standard data graph queries. |
| Flex Credits | Data 360 Queries | Usage is calculated based on the number of records processed. The count of records processed depends on the structure of a query as well as other related factors such as the total number of records in the objects being queried. When an object is queried in the context of a data space, the number of rows processed is based on the total number of processed rows in the source object, not the number of rows pertaining to the particular data space |
|
| Data Services | Sub-second Real-Time Events & API | Usage is calculated based on the sum of the number of profile events, engagement events, API calls, and data actions processed in the sub-second real-time layer and real-time ingestion API, including web and mobile SDKs traffic. Profile events, engagement events, API calls, and data actions are processed in the real-time layer if they are associated with a real-time data graph. For example, if 3 profile events, 10 engagement events, 20 API calls, and 5 data actions are processed during a particular billing period, the total processed is 38. |
This category applies to real-time data graphs. |
| Data 360 Real-Time Profile | Sub-second Real-Time Profiles & Entities | Usage is calculated based on the total number of unique real time data graph records (Profiles for users) that appeared in real time record cache during the billing month. Even if a single unique record appears more than once, it’s only counted once. For example, if a real-time data graph’s primary data model object has 10 million rows cached on the first day of the month, and 1 million unique records are added to the real time cache daily for 30 days, the total count is 40 million. |
This category applies to real-time data graphs. |
| Flex Credits | Data 360 Real-Time Pipeline | Usage is calculated based on the sum of the number of profile events, engagement events, API calls, and data actions processed in the sub-second real-time layer, including web and mobile SDKs traffic and real-time ingestion API. Profile events, engagement events, API calls, and data actions are processed in the real-time layer if they are associated with a real-time data graph. For example, if 3 profile events, 10 engagement events, 20 API calls, and 5 data actions are processed during a particular billing period, the total processed is 38. |
This category applies to real-time data graphs. |
Data 360 Storage Usage
Storage costs are determined by your contract. Use Digital Wallet to check your current usage.
| Digital Wallet Consumption Card | Usage Type | Usage Type Description | Notes |
|---|---|---|---|
| Data Storage | Storage Beyond Allocation | Usage is calculated based on the amount of storage used above the amount allocated. | Data Graph stores data in Data 360. |
For more information on how Data 360 usage is billed, refer to your contract or contact your account executive.
Reduce Data Graph Costs
You can reduce usage by using filters to reduce the number of records included in a data graph. When data graphs are smaller, your processing costs during build and refresh operations are reduced.
Add filters when you create or edit a data graph so that only the records required for your use case are included. For example, instead of including all transaction history, include only recent transactions or active customer records.
Consider these common filters when creating data graphs.
- Use date ranges, such as records created in the last 30 or 90 days.
- Use status values, such as active accounts, open opportunities, or current subscriptions.
- Use geography, business unit, or product line filters when only a subset of records is needed.
- Exclude obsolete or unused records.
Review filters regularly as business requirements change. Well-designed filters help keep data graphs efficient and easier to maintain.
