Use of data graphs impacts the consumption of credits in these usage types. A data graph creates a transform at the backend and hence reflects under the respective usage type in Digital Wallet.
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.
Data 360 Usage
When you use Data 360 for data collection and processing, your org consumes credits from either the Data Services consumption card or the Flex Credits consumption card.
- If your contract included Data Service Credits, those are consumed for all Data 360 usage
- If you run out of Data Service Credits, your org is billed at your Data Service Credit overage rate for the remainder of your term unless more are added
- If you have Flex Credits for Data 360, those credits are consumed instead
Data Services and Flex Credits organize data services within different usage type groupings. For more information, see Data Services Billable Usage Types for Data 360 and Flex Credits Usage Types for Data 360. To check multipliers for each usage type, see the Multipliers for Data Services Rate Card or the Agentforce & Data 360 Flex Credits Rate Card. The cost of each credit is determined by your contract.
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 higher of the number of rows read or the number of rows written. When performing joins, the number of rows read is calculated by multiplying the number of records from the streaming input object by the number of joined objects. |
|
| 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 the ingestion API when used in streaming mode. Bulk mode of ingestion API is not included. For streaming data transforms, usage is calculated based on the higher of the number of rows read or the number of rows written. When performing joins, the number of rows read is calculated by multiplying the number of records from the streaming input object by the number of joined objects. For 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 DMO from an external data lake, querying the data graph may consume data federation credits for live query mode. In such cases, "Data Federation or Sharing Rows Accessed” usage type 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 |
Usage is calculated based on the sum of the number of profile events, engagement events, and API calls processed in the sub-second real-time layer, including accelerated data ingest, web and mobile SDKs traffic, server to server API traffic, and real-time ingestion API. Profile events, engagement events, and API calls 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, and 20 API calls are processed during a particular billing period, the total processed is 33. |
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 and active visitors during the billing month. Each unique visitor is counted only once per month, regardless of how many times they appear or engage. For example, if 1 million unique visitors become active each day for 30 days, the total count is 1 million unique active visitors for that month. |
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, and API calls processed in the sub-second real-time layer, including accelerated data ingest, web and mobile SDKs traffic, server to server API traffic, and real-time ingestion API. Profile events, engagement events, and API calls 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, and 20 API calls are processed during a particular billing period, the total processed is 33. |
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.
Understand Data Graph Processing Costs
Data graph costs have two main components, build costs, which cover processing during refresh operations, and query costs, which cover querying when the graph is read, for example, by agents and APIs. Incremental data graph requires a full daily refresh to stay in sync with the underlying data. Changes that occur across multiple incremental refreshes can be missed, making a full 24-hour refresh cycle mandatory to ensure data accuracy.
Note: Streaming data graphs don’t require full refresh and are only updated incrementally.
Build and Refresh Costs
During a full refresh, all source records in each participating source objects are processed to evaluate filter criteria and build the graph, regardless of how many records ultimately match your filters.
Build costs are based on the total number of source records processed, not the number of records in the final output.
- Source objects categorized as Profile: All rows in the object are processed during each full refresh.
- Source objects categorized as Engagement: All rows within the configured time window are processed during each full refresh.
During an incremental refresh, all source records that changed since the previous full refresh are processed to evaluate filter criteria and update the graph, regardless of how many of those records ultimately match your filters. Build costs are based on the total number of source records processed during the incremental refresh, not the number of records in the final output.
To reduce build costs, consider these approaches:
- Reduce the number of source records in the data lake objects mapped to your data model objects before they enter the data graph. For example, use data transforms or data prep to pre-filter data lake object data.
- Adjust refresh frequency to balance data freshness against processing volume.
- For objects categorized as Engagement, narrow the time window to include only the history required for your use case.
Query Costs
When a data graph is queried by agents or APIs, only the records stored in the graph are accessed unless it's in a live data federation query. Data graph queries are designed to operate most efficiently on the primary key of the root DMO, so the lookup time stays the same regardless of how many records are in the data graph.
To reduce query costs
- Add filters when you create or edit a data graph so that only the records required for your use case are included.
- Don’t query fields that aren’t the primary key field. Queries on fields other than the primary key field can require extra queries..
Storage
Using filters reduces Data 360 storage consumption by limiting the volume of data materialized in the data graph. Smaller data graphs consume less storage, which helps you stay within your storage allocation.