Salesforce Data 360 Credits Guide

Salesforce Data Cloud offers a lot of functionalities in terms of data aggregation, transformation, unification, segmentation, and activation. But, using these features, we should be careful regarding service data usage billed with so-called Credits. How it works?

Data Cloud billing could be tricky, especially with credit-burning features like data streaming and profile unification. With a higher amount of data (hundreds of thousands of records and more), you should be more careful when using Data Cloud capabilities. Especially if there is no easy way to check how much of them you still have.

One naming note before we start. In October 2025 Salesforce renamed Data Cloud to Data 360, announced at Dreamforce as part of Agentforce 360. It is the same product. You will still find “Data Cloud” across the documentation, the UI, the consumption cards and your own contracts, so both names appear in this article, each where it matches what you will actually see on screen.

Data 360 Licenses

Data Cloud Licensing is not so clear in pricing and features as other tools e.g. Sales/Service/Marketing Cloud. From the official information available on the Salesforce.com site we can evaluate that there are two common licenses - free Data Cloud Provisioning and paid Data Cloud Starter license. The second one appears in different types – Data Cloud for Marketing Starter, Data Cloud for Tableau Starter, and Data Cloud for Health Starter.

Salesforce Data Cloud is officially free to use with its Data Cloud Provisioning (also called Data Cloud Everywhere) package, containing 250,000 Data Services credits per year, 1 Data Cloud Admin Account, 100 Data Cloud User Accounts, and 5 integration users, plus 1 TB of storage for users with Salesforce Enterprise and Unlimited editions. Unlimited Plus edition gets 2,500,000 credits per year. This package is a nice entry to the Data Cloud world, especially with 1 TB of storage that we can use. It is also a good opportunity to check what Data Cloud could do. Remember that if you have a longer contract, for example for 3 years, the number of credits will be multiplied (e.g. 250,000 x 3 = 750,000) and you will have access to the entire pool immediately.

Data Cloud Starter for Marketing is probably the most common type of license. Usually sold with Marketing Cloud, contains 10M credits, 5TB of storage, 1 Data Cloud Admin Account, 100 Data Cloud User Accounts, and 5 integration users.

Data Cloud Starter for Tableau looks similar to the Marketing one. 10M credits, 5 TB of storage, but there are no possible add-ons such as segmentation, data spaces, or ad audiences.

Data Cloud Starter for Health looks different from the two previous licenses. It is treated not as a separate Cloud license, but as an add-on to the Health Cloud. There are also no starter credits or storage - you have to buy it separately, the same as Unified Health Scoring, which is a Unified Profiles variation for your patients.

Marketing Cloud Growth is a new addition to the Salesforce portfolio. The license provides a Data 360 instance with 1 TB of space and a limited number of unified profiles. The credit allocation is worth checking on your own Order Form, because the separate Segment and Activation pool was retired in September 2025 and Salesforce does not publish the current base number. The fun fact is that to use Marketing Cloud Growth license you should have Service/Sales or other Salesforce license (which provides free Data Cloud), so there could be an option to merge the free tier and Growth Edition credits pool (I hope so…).

Data Cloud for Commerce is the newest license in the Salesforce inventory. But there is not so much information about it. You can find the mention of this license in the Release Notes and Trailhead, but nothing more.

Data 360 Add-ons

Data Spaces - if you want to create some kind of “internal environments”, for example for each of your brands, you have to purchase the Data Spaces Add-On for your Data Cloud instance. The basic cost is 60,000$ per data space per year.

Data Storage – if you exceed the basic storage (1 TB or 5 TB) in your Data Cloud instance, you have to buy an additional Data Storage Add-On. The basic cost is 23$ per 1 TB of additional data storage per month.

Data Services – if you need more credits, you have to purchase an add-on containing 100,000 credits. As of 2026, the list price is 500$ per 100,000 credits, for both Data Services Credits and Flex Credits.

Ad Audiences – if you want to activate the segments to advertising platforms like Meta, Amazon Ads, and Google Ads, you have to purchase the Ad Audiences Add-On for your Data Cloud instance. The basic cost is 2400$ per audience per year.

Sub-Second Real-Time Service Usage - if you want to use Real-Time Identity Resolution, Real-Time Data Graphs, or Real-Time Segments, you have to purchase the Sub-Second Real-Time Service Usage Add-On. The basic cost is unknown.

Real-time profiles - provides an option to maintain the profiles with real-time updates and functionalities. The basic cost is 750$ per 10,000 profiles. Do not confuse this add-on with the Data 360 Profiles license, which is a whole billing model rather than an add-on, and which is covered further down.

Data Cloud One - increases the maximum Data Cloud instances connections. The cost is 60,000$ per additional instance connection.

Platform Encryption for Data Cloud - if you want to encrypt the Data Cloud data with additional customer-managed root keys, you have to purchase the Salesforce Shield (f.k.a. Platform Encryption) Add-On for your Data Cloud instance. The basic cost is unknown.

Private Connect – if you want to connect to your Data Cloud instance with a private connection (including Snowflake and Redshift), you have to purchase the Private Connect Add-On for your Data Cloud instance. The basic cost is 600$ per connection.

Data Masking - called sometimes Einstein GPT service add-on, provides the dynamic data masking and data tagging for structured data. The basic cost is unknown.

From September 4, 2025, the Segmentation and Activation add-on is no longer needed to access the segmentation and activation features. All Data 360 licenses are now capable of using these features without any additional cost.

In terms of the licenses, all topics like data storage, admin and user account number, and so on look quite clear. But what about credits? There is not so much information about credits in the documentation or pricing details, nor in the Data Cloud demos. But it turns out that they will be crucial in your implementation and maintenance. Why?

What are Credits?

Credits in Data Cloud (a.k.a. CDP, a.k.a. Genie) are like coupons, that you spend to cover your Data Cloud usage bill. In other words – you buy Data Cloud Credits for your money and then you can use them to pay for importing data, exporting data, transforming data, profile unification, or segmentation and activation.

Salesforce Data Cloud is hosted on Amazon Web Services, where credits have the same role. So basically you pay Salesforce, who pays Amazon, for operations, that you make in your Data Cloud instance. 💁‍♂️

Salesforce merged the two types of Credits, that existed in Salesforce Data Cloud. Data Services Credits was a name for credits that are used for data processing (e.g. importing, exporting, transforming, unification). Segment and Activation Credits were used for data segmentation and activation (they were available as an add-on, not included in the basic package). Currently these two types are merged, but in the older instances you can find the deprecated Segment and Activation section in some places, e.g. in the Digital Wallet.

One more thing about credits themselves. They do not roll over. Credits have to be used before the Order End Date on your Order Form, and whatever is left expires with it. If you hold Data Services Credits across several products, for example Marketing Cloud and Tableau, they are pooled for consumption. The total is accumulated across all active Order Forms with unexpired units, and usage is decremented against the Order Form with the earliest end date first.

Three ways Data 360 bills you

When this article was first published there was one answer to “how am I billed” - you bought Data Services Credits and you spent them. That is not true anymore. There are three models now, and the one your org is on decides which of the numbers below actually apply to you.

Data Services Credits are the original model, and the one the tables in this article describe. One pool, one flat multiplier per usage type, no volume discounts. If you purchased credits before February 24, 2026, this is what your org consumes.

Flex Credits are a universal currency. One credit pays for any action, and the same pool covers Data 360, Agentforce and Slack, so an org running agents next to a Data 360 implementation no longer has to guess how to split the budget between them. Orgs purchasing or renewing after February 24, 2026 can have either Flex or Data Services. Flex also brings volume tiering, which Data Services does not have.

Profile-based pricing works on a different principle. Instead of metering what you do, you pay a flat price per profile: 240 USD per 1,000 profiles per year for the Data 360 Profiles license, 420 USD for Data 360 Enterprise Profiles. The Profiles license is not a separate model, though. It is added on top of a Data 360 org that still has one of the two credit models underneath it, and it stops metering some of the most expensive usage types.

There is no forced migration. You can stay on Data Services for as long as your contract runs. But moving to Flex means swapping all of your existing Data Services Credits, not part of them.

Which model is my org on?

There is no single screen that states it. You read it off your Digital Wallet consumption cards:

If you also have a Data 360 Profiles or Enterprise Profiles license, part of your usage stops being metered on top of whichever credit model you are on. The multipliers for both credit models are in the next section.

What a Profiles license stops metering

How a profile is counted depends on whether identity resolution is running. With an active ruleset in a data space, the billable count is your known unified profiles, plus 4% of your anonymous profiles, plus every record in the DLOs mapped to Profile-category DMOs that the ruleset does not use. Without identity resolution, it is every record in every DLO mapped to a Profile-category DMO. Sandbox orgs count at 80% of the total, and going over your entitlement means paying the overage rate.

Basically, you swap metered consumption for capped object counts. The un-metered features still consume the supplementary usage types, so Data Queries and data storage keep billing normally underneath.

Credits usage per each activity

Now we dive into the more interesting stuff. Surfing through the official Data Cloud documentation it won’t be so easy to find the proper Credits usage calculation for each feature in the system. The core sources for us will be the Data Cloud Billable Usage Types from the documentation, Multipliers for Data Cloud, and the Agentforce & Data 360 Rate Cards page, where the Flex Credits card covers the Data 360 usage types. None of them are easy to find on the website.

Data Services multipliers

Multiplier is nothing more than the amount of credits used per 1 million processed records. For example, if we have processed 500,000 records in Calculated Insights, we have used 15/2 = ~8 credits.

Flex Credits multipliers for Data 360

Flex is not the same list of usage types at different prices. It is a shorter, consolidated list. Data 360 Prep covers what Data Services splits into Batch Data Transforms and Batch Calculated Insights. Data 360 Streaming Pipeline covers streaming ingestion, streaming transforms, streaming calculated insights and streaming data actions, so four usage types collapse into one. You cannot map a Data Services estimate onto Flex line by line.

The multipliers are tiered, and the tiers are counted per usage type, not on your total consumption. They reset on the first day of every calendar month.

The thresholds include the upper limit, so Tier 2 runs through the 1,500,000th credit and Tier 3 starts at credit 1,500,001.

Sandbox and other pre-production environments run at 80% of the Base Tier rate and do not participate in tiering at all.

Two things follow from that when you plan an implementation. First, the thresholds are counted in credits consumed, not in rows processed, so an expensive usage type like Unification reaches Tier 3 long before Data 360 Queries ever will. Second, because the tiers reset monthly, running a big backfill in one month is cheaper than spreading the same work evenly across three. That is the exact opposite of how you would plan it on Data Services, where the rate never moves.

A few usage types are not listed on the Flex rate card for Data 360 at all. Batch ingestion from external sources, Inferences, Data Federation rows accessed, Private Connect data processed and Data Share rows out are all missing from it. The documentation does not say whether they are unmetered, folded into another type, or billed somewhere else. If any of them is central to your use case, get the answer from your account executive in writing.

What each usage type covers

Now, let’s talk about each of the types, following the billable usage types documentation. The list follows the Data Services usage types, which are the more granular of the two. On Flex the same operations are grouped into the consolidated types described above.

Credits decrement at a fractional rate, and the minimum decrement per usage type is 1 credit, counted when fractional usage adds up to 1 or more over the monthly billing period. And when you read “rows processed” below, it means every record touched to produce a result, not the number of rows you get back. That difference is behind most of the surprises in this article.

The Internal Data Pipeline represents the ingested data from Salesforce products (via Salesforce CRM connector, Marketing Cloud connector, Commerce Cloud connector, Marketing Cloud Personalization connector) to Data 360, both in Batch and in Streaming Data Streams. From the 7th of August 2025, the Internal Data Pipeline is completely free in both modes.

The Batch Data Pipeline represents the ingested data through the Data Stream to the Data Cloud. With the multiplier set as 2000 credits per 1M rows, you should estimate how much data you will bring. There could be scenarios when starting ingested data won’t be a problem, but their rapid growth may be pushing usage to your license limit day by day.

The Streaming Data Pipeline represents the rows of streaming data processed across all data streams with stream processing - in practice, streams created by the Website and Mobile App connector and by the streaming ingestion API (bulk mode is not included). It is calculated in the same way as the Batch Data Pipeline, but at a significantly higher multiplier, in exchange for near real-time processing. Note that Streaming Data Transforms are a separate usage type with their own multiplier, so they are not counted here.

The Batch Data Transforms represent the data processed within the Batch Data Transform functionality in the Data Cloud. Depending on the scenario, you will have to calculate the processed records from starting DLO/DMO and DLOs and DMOs added to the Transform. Batch Data Transforms are not so expensive, with 400 credits per 1M processed rows, but you will use them as a data deduplication and cleaning solution for all of your data (which could mean a lot of processed records). Usage is counted on the higher of the rows read or the rows written, not on the sum of the two. If you set the transform to incremental, then after the first run only the rows that changed since the previous run are counted.

The Streaming Data Transforms represent the data processed within the Streaming Data Transform functionality in the Data Cloud. Depending on the scenario, you will have to calculate the processed records from starting DLO/DMO and DLOs and DMOs added to the Transform. Streaming Data Transforms are used within Streaming Data, so they are more expensive than Batch Data Transforms. Costing 5000 credits per 1M processed rows, if you will use them as a data deduplication and cleaning solution for all of your data, they could be very expensive, but sometimes necessary. As with batch, usage is counted on the higher of the rows read or the rows written. Watch the joins here. When a streaming transform joins objects, the rows read are calculated by multiplying the records from the streaming input object by the number of joined objects, which is the one case where a transform gets expensive without you noticing.

The Unstructured Data Processed represents unstructured data processed without AI-assisted extraction - PDF, TXT, and HTML files, but also audio and video, which are supported now. With the multiplier set as 60 Credits per 1 MB, it is a widely used usage type to boost the Agentforce and Einstein AI capabilities within TXT, HTML, and PDF documents. But it gets painful with audio and video, where the meter runs on file size, so five video files of 100 MB each mean 500 MB of usage. Be careful here. One thing works in your favour though. When a document is chunked and then vectorized with an embedding model, usage is counted once across both steps, so a 100 MB PDF that goes through both is 100 MB, not 200 MB.

The Intelligent Processing is a separate usage type for unstructured data that goes through AI-assisted features, such as LLM-based parsing, LLM-based visual preprocessing, image processing, and Intelligent Context. At 750 credits per 1 MB it costs more than twelve times the plain Unstructured Data Processed rate, so it is worth knowing which of your content pipelines actually needs the AI-assisted path.

The Data Federation refers to the records accessed within the Zero-ETL, also called No-Copy or BYOL connectors, currently supporting Amazon Redshift, Databricks, Google BigQuery, and Snowflake. They are a quick (real-time) alternative to the Batch and Streaming Data Pipeline, with a multiplier set as 70 Credits per 1M rows accessed. But rows accessed mean that they are not copying the data to the Data Cloud. You will pay only for the rows returned from the source, but you will pay for each time the Data Cloud will ask for these data. You should also know that you or your client will also pay for all of the requests from Data Cloud in the data source platform (e.g. query run in Databricks environment). If you want to use Accelerated Data Federation (with caching), you will also be billed for Batch Data Pipeline for storing the cached data in Data Cloud’s DLO.

The Sharing Rows Accessed refers to sharing the data to the external data platform and is calculated based on several rows queried from the external data lake’s request. For external data shares this applies only to cross-cloud and cross-region queries, so if the request comes from the same region and the same cloud, there is no credit consumption at all. In sharing between two Data 360 orgs, this usage type is billed to the target org.

Data Share Rows Shared (Data Out) represents the data processed with Data Share functionality. The Changed type represents the new or changed records in the data share. The billing here is unusually generous. Usage counts the total records processed when you first create the data share and link it to a target, and the incremental changes that follow are not counted at all.

The Private Connect Data Processed covers the volume of data, in GB, transferred over the private network route, in both directions - into Data 360 and out to an external data source. Note that this is billed separately from the Private Connect add-on itself, so the 600$ per connection buys you the connection, not the traffic that runs over it.

The Batch Profile Unification represents the unified source profile data. It is the most “expensive” task in the Data Cloud. It is also the most tricky one, with a not-so-clear definition of what 1 million processed rows mean and how many rows takes to unify one Profile. We will cover it in its own section below.

The Sub-second Real-Time Events refer to the usage of Web SDK or Mobile SDK event tracking through the sitemap, the feature well-known from Marketing Cloud Personalization, which could be implemented also in the Data Cloud. But it is very, very expensive. 70,000 Credits per 1M events (no matter if it is an event triggered by sitemap or API) is an incredible amount. For context, if we pay for these events with additional bought Service Credits, the current Marketing Cloud Personalization Growth license basic cost (108,000 USD) is the equivalent of ingesting around 155 million events (~12,9m per month) through Data Cloud Web SDK. So if you record more than 13m user events within Data Cloud Web SDK per month, you will pay more than the equivalent of a basic one-year Marketing Cloud Personalization license that has no strict event number limits.

The Sub-second Real-Time Profiles & Entities is a separate usage type, tracked on its own Data 360 Real-Time Profiles consumption card. It is calculated on the number of unique, active visitors during the billing month, and each visitor is counted only once, no matter how often they come back. If 1 million unique visitors are active every single day for 30 days, the count for that month is 1 million, not 30 million. So the cost here is driven by the size of your audience and not by how active it is, which is the opposite of how Sub-second Real-Time Events work.

The Batch Calculated Insights represent all records processed during building the CI (Calculated Insights). Note that we count records in all objects that we use for our query and it counts every time the CI runs. For example, with a multiplier of 15 credits, if we build Calculated Insight joining the first DMO (Data Model Object) with 2M records and the second DMO with 1M records, no matter how many records we finally got, we processed 3M records, so we used 45 credits. If we use this CI in the segment that is updated every day, we spend 45 credits every day. Two rules soften this. If none of the underlying objects have changed since the last run, there is no charge for that run at all. And if the same object is used several times in one Insight definition, its records are counted once, not once per use.

The Streaming Calculated Insights are similar to basic Calculated Insights but are used for real-time data processing. Pretty expensive.

Inferences are defined as any data output produced by AI model in Einstein Studio. For example: using AI in flow action (1 flow triggered = 1 inference), prediction job on data model (100 records = 100 inferences), generate text with LLM (1 text generated = 1 inference). This counts for any predictive model you use, whether it was built in Einstein Studio or brought in with Bring Your Own Model. A single inference is one prediction, optionally with its prescriptions and top predictors.

The Data Queries represent the records processed by queries against your data and are calculated on records processed. They are widely used in all of the internal and external API calls that require querying the data in Data 360. They are the cheapest operations in Data 360, so check if you can use them in your case, but be aware that this solution can scale up quickly with more use cases being implemented. There is one catch with data spaces. When an object is queried in the context of a data space, the rows processed are counted on the whole source object, not on the subset that belongs to that data space.

Accelerated Data Queries, used with Tableau or CRM Analytics, are no longer billed. As of August 16, 2024, usage is not recorded against this category at all.

Streaming Actions represent the Data Actions activity in the Streaming Pipeline and Streaming Calculated Insights flow (real-time). Also not so cheap, but usually you will use them in pretty important use cases.

The Segmentation usage type (until recently called Segment Rows Processed) represents the number of rows processed to create the Segment. The catch here is the segment will count all of the rows processed from the DMOs that you get the data from. For example, if you use the data from two DMOs, 2M records each, you will process 4M records no matter the final segment population number. The more complex calculations come if you segment on an Individual and want to create the filter on a field from a related DMO, which is related to another DMO, which is related to the Individual, the more “nested” filter, the more records processed.

The Batch Activations represent the number of rows processed through the segment activation process. Same scenario as in Segmentation. Note that this is counted in the same way with or without related attributes.

The Activate DMO - Streaming (formerly Streaming DMO Activation) represents the number of rows processed through the Data Model Object Activation. Records processed are counted from the new records created or updated in the DMO per activation. Watch out for one rule here. If a data graph is used with the activation, the number of records processed is doubled - one new record change in the DMO counts as 2 records processed.

The Code Extension is the one usage type that is not billed on rows at all. It is measured in Compute Units, where the number of units consumed per hour depends on the compute size you select, and the total depends on how long your code runs.

Usage types that are no longer billed

Four usage types changed status over the last two years. The dates sit in separate release notes, so here they are in one place:

Profile Unification Credits usage

Talking about Profile Unification, there are a lot of questions about how many of the Profiles can be processed with some amount of credits, especially in the free Data Cloud Instance. Some of the promoting materials were talking about 10,000 profiles in the Data Cloud Provisioning Package, which contains 250,000 Credits. With this information, Salesforce Ben estimated, that the one processed Unified Profile takes 25 credits.

25 credits is a very, very huge number. With credit pricing set at 500 USD per 100,000 credits, we can calculate that in this theory one Unified Profile will cost us 0.125 USD. Pretty much, right? With 10M credits in the Data Cloud Starter package, we would use all our credits if we unify only 400k Profiles. But this calculation is a sort of generalization. Why?

To go through this, we need to take a deep dive into the documentation and Salesforce nomenclature. Citing from official Docs:

Batch Profile Unification usage is calculated based on the number of source profiles processed by an identity resolution ruleset. After the first time a ruleset runs, only new or modified source profiles are counted. A source profile is an individual and their related records, such as contact points and party identifiers, which are included in the identity ruleset.

For example, modified means deleted profiles, or profiles marked as suppressed via Consent API preferences.

The key term here is a source profile. A source profile is a record with personal data that is processed by the Identity Resolution ruleset.

Let’s take an example. We have 500,000 user records ingested from Amazon S3 Connector, 700,000 user records from Salesforce CRM connector, and another 200,000 user records from Marketing Cloud connector, all ingested 1:1 to Individual and related Data Model Objects, e.g. Contact Point Email. Starting the unification process, we have 1,400,000 source profiles. After Unification, no matter if we finally got 1,400,000 Unified Profiles, 400,000 Unified Profiles, or 100,000 Unified Profiles, we used 140,000 credits.

Looks better, right? In this scenario, with the result of 400,000 Unified Profiles, we used only 0.35 credits (0.00175 USD) per Profile (and we used about 60% of our credits from the Data Cloud free license). Even if we add the cost of Data Stream ingestion (2800 credits), it is a cost of 0.357 credits (0.00179 USD) per Profile.

What is more, a source profile is a record with information from the Individual DMO and all related records, which includes Contact Point DMOs, Party identifiers, or related custom DMOs. Good information is that when we do the Profile Unification, we count only one processed record as a whole source profile instead of for example 3 records (when we have Individual, Contact Point Email, and Contact Point Address DMOs).

There is another side of the coin. We also count modifications, deletions, or suppression as processed records in Profile Unification. It means that every small change, no matter if we modify 1, 5, or 50 attributes in one record, even in the related DMO, will process the source profile once again in the next Identity Resolution run and will cost us 0.1 credit per modified source profile.

Data 360 Sandbox credit usage

Sandbox environment in Data Cloud is available and recommended for every implementation, especially associated with Salesforce Dev Orgs. Data 360 supports every sandbox type - Developer, Developer Pro, Partial Copy and Full Copy. Note that this feature is still in development and new functionalities come in every release.

Data 360 Sandbox uses the same credit pool as the Production environment, but it is 20% cheaper. Note that this reduced rate applies to every pre-production environment, so it covers scratch orgs as well as sandboxes. These are the Data Services sandbox multipliers:

On Flex Credits the discount works differently. Sandboxes run at a fixed reduced rate, 80% of the Base Tier multiplier, and they do not benefit from volume tiering at all, so a heavy sandbox workload never gets cheaper the way production does:

How do I check my Credit volume?

To check how many Credits you got with your license, you should first find out what license you bought (of course if you don’t remember or were not responsible for buying it). If you do not have access to the contract, you can check it in the Your Contracts section. Look for the Data Cloud named product. You can also do this in the Data Cloud Digital Wallet.

Data 360 Digital Wallet

If you want to check how many credits you have left, you can use a new functionality called Data Cloud Digital Wallet.

Data Cloud Digital Wallet is a feature that shows your current credit consumption and Data Storage Allocation usage. Which consumption cards you see depends on your billing model - a Data Services Credits card, a Flex Credits card, or both. Older orgs may still see a deprecated Segment and Activation Credits card, which was retired on September 4, 2025. Segmentation and activation usage is now recorded against the same usage types on the Data Services card. You can view the consumption details within a period (Last 24 Hours, Last 7 Days, Last 30 Days, and Last 90 Days). The data refreshes hourly.

To access the Data Cloud Digital Wallet, simply type the “Consumption Cards” in the App Launcher. The other way is to go to the Your Account menu and look for Consumption Cards on the navigation bar or in the UI card next to Invoices.

You can edit who can have access to the Digital Wallet and also export the Digital Wallet Data using the Digital Wallet DLOs. Refer to the documentation or check my article about Digital Wallet to find out more information.

How to save Credits?

There are many ways to reduce Credits usage, but the main answer to the question “how to save credits” is simple - REDUCE THE ROWS PROCESSED on each stage of the process. After reading this article, you probably have some ideas about how you could do this. But we can collect the most obvious and effective ways.

Before implementation

Make a good Discovery Phase

The first and probably most important tip. It can not only reduce used Credits but also speed up your implementation. Gather the functional requirements for the Data Cloud, get to know the data architecture in your company, and localize the necessary data sources that you need to fulfill your use cases.

Focus on use cases

Don’t immediately ingest all of the company’s data immediately to the Data Cloud. Try the use case approach - what data you will need to accomplish the goal? And then ingest just this. Then scale for next use cases.

Start small

Pick the simplest and least data-heavy use cases for the start. Even small implementation of Data Cloud could be time-consuming so focus on easy use cases that requires less data than more advanced scenarios. Then, after successful implementation, you can scale.

Ingestion

Reduce the frequency

Data Cloud can work in near real-time with Streaming Data solutions and regular data updates from Connectors. But every new data import, no matter if with an upsert or full refresh method, will use your credits. So check if your use case needs highly frequent data ingestion. The same tip can be used with segment and activation. Check how frequently the data should be updated in your scenario.

Note that Salesforce CRM Connector uses only automatic, 15-minute frequency, so if you have a lot of data processed many times on the same records throughout the day, the import could cost you additional credits.

Filter the data at the source side

To reduce processing of unnecessary rows, filter the data at the source side if possible. Data Cloud has the filtering option, but it will still process all of the records from the source and then filter the data. Use only the data that are necessary for your implementation. Check if you can get all data from less amount of data sources. Remember that more normalized data means more imported tables, which means more records processed.

Count processed records

Usually, if you have external Data Streams with Incremental Refresh, you should count the processed records, not the changed or added ones. Each time the process runs, Data Cloud will process all of the records in your data source and then decide which records should be changed. So if you have a data source with 1M rows, ingestion will process 1M rows, no matter if it changes only 10 or 100,000 records.

Get every needed attribute

Sometimes it is good to reduce the number of attributes that you ingest from data sources to Data Lake Objects (because if you import it, you will be able only to disable it, but not hide or delete it). But remember that after the first ingestion, if you would like to add another attribute, you will have to process all the records again.

Check the Zero-Copy option

Zero-Copy connectors can drastically reduce the ingestion credit usage. With a multiplier set as 70 credits per 1M processed rows they could be a cheap alternative for batch ingestion of a large number of rows. But remember that the zero-copy queries are also billed at the Cloud Provider’s end.

Prioritize the internal data pipeline if possible

If you can choose data from Salesforce products over external sources or APIs, go for it. Since August 7, 2025, the Internal Data Pipeline is free for both Batch and Streaming ingestion, so anything arriving through the Salesforce CRM, Marketing Cloud, Commerce Cloud, and Marketing Cloud Personalization connectors costs you nothing to bring in. Prioritize the use cases that run on internal data at the beginning of the implementation.

Split the Data Streams

Consider splitting the data streams for upserts and deletions if you want to ingest files or tables that are not updated frequently. The same applies if you have time-sensitive data that cannot be ingested in a streaming format - keep it in its own, more frequently refreshed stream instead of re-processing the whole dataset on every run.

Transform

Prepare the data on the source side

If possible, clean and prepare the data on the source side. Especially if you work with Snowflake, Big Query or other DMP/Warehouse tool that have the cleaning and transforming functionality.

Use Formula Fields

Formula Fields are a free option to create additional columns with specific data. Despite being restricted to specific connections and operators, sometimes they will allow you to avoid using Data Transforms.

Use incremental transforms

If you have a Data Transform that runs more often than 24 hours, you can use the Incremental Transform type to limit the records processed. After the first full run, for the next 24 hours, Incremental Data Transform will process only new or changed records in the target DLO or DMO. This can significantly reduce the credits used. Remember about limits in incremental transform.

Implement the deletion process

If your compliance rules allows to not store deleted users and related records, you can implement the deletion process that will wipe out this data from Data Cloud. This will result in reducing the rows processed for each of the “cleaned” DLO and DMO.

Mapping and Identity Resolution

Draft the mapping before ingestion

For some of the connectors, there is an option to do the “draft” mapping before ingesting the data. With the connector set up, you can create a Data Stream by adding all necessary headers, skipping the data ingestion for now. You can now map these headers, create relationships, check if the data model architecture is correct, and then ingest the data.

Divide the data to separate DMOs

You can split the huge tables or views into smaller pieces. For example, if you have data from several years, you can split it into separate tables or views with historic data and data from the last 2 years (or something similar, depending on your use cases). Then, creating separate DMOs for historic data and current data will allow you to segment and query only on the period that you are interested in, reducing the records processed. Especially if you use the Other data category, as the lookback window works only for the engagement data category, note that this approach has some limitations and implications.

Denormalize if possible

Maybe it’s not the best practice, but a cost-saving practice. Reduce the number of separate objects if you can. Each additional related object storing 1M rows will cost you an additional 1M processed rows in every query, every segment, and every activation that uses this additional related object.

Check if you need the Identity Resolution

Identity Resolution is the most expensive feature in the Salesforce Data Cloud. But you won’t use it in every implementation. If you know that the data is normalized, unique, and well-arranged, you can build a fully custom solution and/or skip the Unification process and work on defined relationships. It will be a more complicated, more technical, and not so easily scalable solution, but it can save you a huge amount of credits, which is crucial, especially in the free tier.

Segmentation and Activation

Reduce re-running in the editor

In the segment builder, each time you recalculate the population, rows will be processed. Try to do as few segment changes as possible to check the result.

Use Query Editor

If you know SQL well, you can easily recreate the segment logic in the Query Editor tool and check the output, or use the COUNT option to see the population size. Segmentation and activation no longer have their own credit pool, so every recalculation in the segment builder competes with your ingestion and unification budget. The Query Editor bills as Data Queries (2 credits per 1M rows) instead of Segmentation (20), so checking the population there is an order of magnitude cheaper than iterating in the canvas.

Narrow the segment with Calculated Insights

Using Calculated Insights for narrowing the audience, you can push the billing from segmentation and activation type to data service type. Batch Calculated Insights are cheap and can significantly reduce the number of processed rows in Segmentation and Activation.

Reuse the segments

You can use nested segments and reuse the segments that you have, instead of creating new ones that will process the data again. For example, you can create a wider segment with some specific rules and then build smaller segments on it, using the Segment Membership DMO.

Be careful

Note that every action in the Data Cloud costs you. Processing data in every ingestion, every Data Transform, every Calculated Insight, and every Segment will be paid. Remember that you can add the Data Streams and map the Data Lake Objects without starting the data ingestion. You should be careful, especially if there is still no easy way to find out how many Credits you spent for which operation.

Data 360 is a powerful tool, with powerful features. Although it is still in development (just check how many new options and fixes it got through the year), it can be used in a lot of use cases, especially focused on marketing automation solutions. With a nearly no-code approach, it seems to be an easy and friendly option to process and segment your data. And it is now the foundation of the marketing stack - Marketing Cloud Growth and Advanced are built on top of it, so what used to be a rumor about moving Marketing Cloud into Data Cloud has happened.

But there are some things that we should be careful about. I hope that this article will make it clear what Data Cloud billing looks like, how to calculate Credit usage, and how to become more aware while working with this tool.