How to calculate the total cost of ownership of Salesforce Data Cloud

The number that lands in the business case is the licence. It is a real number, and it is the small line. Two months later a stream of every object is on, an identity ruleset is running over objects nobody segments, and an activation is carrying attributes the destination does not use. The usage conversation starts. Someone says zero copy will make the new source free. It will not. Someone else asks for the peer's price, or a savings percentage, to put the conversation back in the box. Neither belongs on this page. This page states no price.

#The line everyone quotes

Search still says Data Cloud. The product is Data 360, rebranded on 14 October 2025. The behaviour is unchanged. You may still see the old name in the product and in the documentation. "While the name is new, the functionality and content remains unchanged." The rename did not collapse consumption into the licence, and it did not publish a rate card on this page.

The help page is plain about the rest of the shape. Some features are offered as add-on licences. Other features have usage limits. Many of those limits can be adjusted to the business. An adjustment is a commercial event. It is not a setting you flip at no cost, and it is not evidence that the limit was decorative. Treat the licence figure as the opening line of a cost conversation. Then ask which action draws on which meter. If the answer is a single annual figure, the answer is unfinished.

Credits sit on the usage side where your contract meters consumption that way. Those credits are part of the cost of doing the work, alongside the add-on licences. This page will not invent a credit rate, a pack size, or a discount. Ask the agreement. Then ask which action draws down which balance. A credit estimate spread across five years, before you have operated one use case for a month, is a story. It is not a total.

#The meters that actually move

Four questions cover the work people forget to cost. They are questions, not a tariff.

What do you ingest, and how often. Streaming and batch both land data. The help page includes both in the same job: ingest, harmonise, unify, analyse. A stream of everything costs more processing than a nightly history load of the rows a person is waiting on. The architecture choice is a cost choice. Each streamed row is processing. If you cannot name the waiter, you are paying for freshness nobody reads. That pattern is streaming versus batch. Cost it before you enable the second stream.

What do you unify. Identity resolution reads the source profiles you stored and builds unified profiles. More sources, more match rules, and more frequent runs are more processing. A ruleset you run because you can, on objects you do not segment and no agent reads, is a meter with no audience. Unified profiles are keys. They are not a golden record. The engine does not pick a winning value and does not override source values. You do not get a cleaner person as a side effect of paying for another run. You get another run. If the keys are blank, you paid to unify blanks.

What do you activate. Each destination, each refresh, and each attribute you attach is work. A wide activation is a cost and a disclosure. Price the narrow one you meant: the identifier the destination needs, and the consent that justified it. Attributes added because the mapping screen had empty slots are a cost you did not decide. Take them off the design before you ask what the send costs.

What is an add-on. Features that are not in the base entitlement need a line of their own, once you have confirmed they are add-ons in your agreement. List them. A blank "platform" row is how add-ons arrive in year two as a surprise. Do not list a product you have not confirmed. "We will probably need the advanced one" is not a line. It is a guess, and guesses get approved faster than lines.

#Ask which meter moves

Before a new source is approved, make the owner answer one sentence. Which meter moves, and who reads it monthly. If the answer is "the licence covers it," send the question back. The licence is the small line. The source might move ingest, identity processing, storage of a copy, activation, or an add-on. It might move more than one. A sentence that names none of them is not an approval. It is a delay you chose not to notice.

Do this for federated data as well as copies. Zero copy is federation. The help page says you can connect data using zero copy data federation. Leaving bytes in an external store avoids one copy inside Data 360. It is not a synonym for no cost, and it is not a latency promise. Querying, modelling, and activation can still consume. A federated table a segment filters on every refresh is a different load from a batch you control. Cost the pattern you chose. Do not cost the slogan.

Keep a one-page register. Source. Pattern, ingest or federate. Cadence. Whether an identity ruleset includes it. Activations touched. Add-on required, if you have confirmed one. Named reader of the meter. Review the register when someone asks to add columns. Columns move meters. They also move disclosure, which is a cost of a different kind when the column leaves the org.

The reader of the meter is a person, not a shared mailbox. A shared mailbox is how a limit adjustment arrives as a surprise: everyone assumed someone else was watching. Put the name in the register. If that person leaves, replace the name in the same week. An unowned meter drifts in the direction of more, because more feels like delivery and less feels like a cut.

#What not to put in the total

Do not put a savings percentage you cannot trace to a meter you already run. Do not put a peer's price. Do not spread a credit estimate across a long horizon if you have not operated a single use case long enough to see a month of consumption. A short proof, with one object and one activation, is a better cost input than a spreadsheet of imaginary volume. The shape of that proof, including the kill criterion, matters as much as the invoice. Scope it as one object, not as the estate.

Do not put a match rate in the total as if it were a discount. Match rate, if an advertising destination returns one, is an outcome after the send. It is not a price, and it is not a promise Data 360 made. This page will not invent one. A business case that needs an invented match rate to clear a hurdle is a business case about the wrong object.

Do not put "real time" in the total as if it were free once the licence is paid. Real time is a stream, and a stream is processing. If the person is not waiting, batch the history and say so in the register. The saving is the stream you did not turn on. That saving is real. It is also unglamorous, which is why it gets omitted from the steering pack in favour of a feature list.

Tableau Next does not replace Tableau. The help page says you can expand Data 360 using Tableau or Tableau Next. A new analytic surface is an estate decision with its own licences, its own extracts, and its own people who must open the workbook. Do not hide that decision inside the Data 360 total as "included visualisation." If the asker already has Tableau, the incremental cost of a new tool is a choice, not a default. Cost the choice on its own line or do not make it.

#Re-forecast as a habit

Re-forecast after the proof, with the actual meters, and again when the second source arrives. The second source is where the register usually lies. People copy the first source's cadence onto a wider object, include it in the ruleset because the ruleset exists, and attach it to the activation because the mapping was already open. Each of those is a meter. None of them is implied by the first month's invoice.

A month of real consumption teaches you which of those meters actually moved, and which line in the business case was decoration. Keep the proof's object small enough that you can point at the movement. If five things changed in the same month, you will not know which one drew the usage, and the re-forecast will be another story. One object, one ruleset decision, one activation. Then read the meter. That reading replaces the imaginary volume. It does not need a price published on this page to be useful. It needs the name of the meter and the name of the reader.

The total cost of ownership is that habit. It is not a single figure you defend in a steering pack and then forget. A figure you cannot recompute from the register is a slogan with a currency sign. Keep the register short enough that a person will update it. A cost model with forty drivers and no named reader will be wrong in a quarter and still be quoted.

Read the third column in the approval meeting. It is the list of sentences that get a source connected too early. The fourth column is the correction. Almost none of it is a price. That is deliberate. A price you invented to fill a cell will be the number everyone remembers, and it will be the wrong one.

#Ownership after the first invoice

Name who may approve a new stream, a new ruleset run, and a new activation attribute. Three names, or one name with three duties, but not a committee that meets after the connector is live. The change gate is the same gate as identity: a new source is a change to cost and to match behaviour, and it should re-read the register before it goes live.

Once a quarter, read the register against what the org is actually doing. Streams that have no waiter. Rulesets on objects with no consumer. Activations wider than the design. Federation paths nobody has timed. An hour is enough if the register is one page. A governance forum is how this becomes a slide. The hour is how it stays a control.

The underlying design choices, made before ingestion, are what the meters are measuring. Scope of unification, match rules, source of truth per attribute, copy versus reference, and a named owner. They are set out in getting Data 360 right the first time. A cost model that starts from the licence and never opens that list will be surprised by every one of them, on a schedule the vendor did not choose. You did, by connecting first.