How to cut your Salesforce Data 360 credit bill: an optimization playbook

The first big Data 360 invoice usually arrives about three months after go-live, and it rarely looks like the forecast. Open Digital Wallet next to it and the story is almost always the same: two or three meters are eating the budget while everything else barely registers. A transform someone configured as streaming. Segments republishing hourly for a campaign that sends weekly. An identity ruleset that got edited four times in a sprint and reprocessed the entire profile base each time.

The good news is that this failure mode has a matching fix. Because consumption billing is mechanical — we’ve covered how the credit model and rate card actually work separately — the bill is a direct function of configuration choices, and most of those choices can be changed in an afternoon without touching a single use case. You don’t need a re-implementation. You need a triage pass.

This playbook is that pass: where credit burn concentrates, then eight levers in rough order of impact — batch-versus-streaming triage, ingestion hygiene, refresh scheduling, segment cadence, unification discipline, the query and activation long tail, and the monitoring and alerting that keeps the savings from eroding. Run it once this quarter, then keep the last two levers running permanently.

Where Data 360 credit consumption actually concentrates

Every billable operation in Data 360 draws from one credit pool. Salesforce consolidated its four separate credit types into a single fungible credit in September 2025, usable across production and sandbox, ingestion through activation, with sandbox metered at a 20% discount. Consumption follows one formula: volume divided by one million, times the usage type’s multiplier.

The multipliers are where the drama lives. On the official rate card, a data query costs 2 credits per million rows processed while profile unification costs 100,000 — a spread of four and a half orders of magnitude across operations paid from the same pool. In practice that spread means a Data 360 bill is never evenly distributed. It concentrates in whichever two or three meters your architecture leans on, which is why effective optimization starts with reading your Digital Wallet breakdown, not with a generic cost-cutting exercise.

The eight levers below are ordered by the impact we typically see, but your order should follow your own top meters:

Lever	Meter it moves	Why it matters	First thing to check
1. Batch-vs-streaming triage	Pipelines, transforms, insights, activations	Streaming runs 2.5x–160x the batch rate	Streams with no signed-off real-time need
2. Ingestion hygiene	External data pipeline	2,000 credits/1M rows, every single run	Unused fields; full loads where deltas would do
3. Transform and insight scheduling	Transforms, calculated insights	Every refresh bills rows processed again	Hourly refreshes feeding daily decisions
4. Segment publish cadence	Segment rows processed	20 credits/1M rows, per publish	Segments left on default schedules
5. Unification discipline	Profile unification	100,000 credits/1M rows on re-runs	Ruleset edits shipped one at a time
6. Query and activation patterns	Queries, activations, data shares	Cheap rates, unbounded volumes	Streaming activations that could be batch
7. Digital Wallet monitoring	All of them	Catches drift while it’s cheap	Nobody owns the weekly review
8. Alerts and internal budgets	All of them	Converts surprises into decisions	No thresholds configured

Rates are production batch multipliers from the official Data 360 rate card and segments and activations rate card as of May 2026.

Lever 1: downgrade every stream that doesn’t need real-time

Salesforce’s own training is blunt about this one: opt for batch over streaming, because streaming processes data continuously and consumes more credits. How much more depends on the operation. On the rate card, external ingestion runs 2,000 credits per million rows in batch and 5,000 in streaming — a 2.5x premium. Data transforms jump from 400 to 5,000, a 12.5x premium. Calculated insights go from 15 to 800, roughly 53x. And activation runs 10 credits per million rows in batch against 1,600 for streaming DMO activation — 160x.

The arithmetic compounds fast. Take a transform touching one million rows a day — an assumption for illustration, not a benchmark. In batch that’s 400 credits daily, about 12,000 a month. The same transform configured as streaming bills 5,000 daily, about 150,000 a month. Same logic, same data, same output. The only difference is a configuration choice someone probably made by default.

The triage method is simple and slightly confrontational. List every data stream, transform, insight, and activation. For each one, write down the freshness requirement a business owner has actually signed off — “in-session”, “hourly”, “daily”. Not the requirement someone assumed; the one somebody will defend in a meeting. Anything daily goes batch. Anything hourly almost certainly goes batch too, on a schedule. What survives is your genuine real-time footprint, and in our experience it’s a fraction of what the original architecture diagram assumed.

Two cautions. Streaming insights operate on windows of incoming events rather than your full historical estate, so some real-time designs genuinely can’t be replicated in batch — those are the ones worth paying for. And the extreme end of the card, sub-second real-time events at 70,000 credits per million, buys millisecond personalisation. Scope it to the pages and journeys where revenue actually depends on it.

Lever 2: ingestion hygiene — only the rows and fields you’ll use

Ingestion is rarely the most expensive multiplier, but it’s the meter that never stops running, so hygiene here pays out monthly forever.

Start with what’s free. Since September 2025, structured data from Salesforce Core, Marketing Cloud Engagement, Marketing Cloud Personalization, and Commerce Cloud ingests at no credit cost. If any of that first-party data is arriving through a paid external route — an ETL tool, a warehouse hop, a middleware layer someone built before the pricing change — rerouting it through the native connectors is found money.

For genuinely external sources, three habits matter:

• Ingest fields, not tables. Salesforce’s guidance is to limit ingested data to what your use cases need. Every mapped field that never appears in a segment, insight, or activation is storage you pay for and rows you process for nothing. “We might need it later” is how most orgs end up ingesting three times the data they use.
• Filter before you unify. Salesforce’s own credit-management guidance notes that adding a filter to a data lake object reduces the rows processed by identity resolution downstream. Filtering at the source system is better still — dormant profiles, test records, and out-of-scope regions shouldn’t cost you at every stage of the pipeline.
• Load deltas, not history. Ingestion bills rows processed per run. A daily full load of a 10-million-row table processes 300 million rows a month; a 2% daily delta processes 6 million. (Those volumes are assumptions for illustration.) Wherever a source supports incremental extraction or upserts, use it, and keep engagement-data lookback windows as short as the use case allows.

None of this is glamorous. It’s also the difference between an ingestion meter that scales with your business and one that scales with your data team’s optimism.

Levers 3 and 4: match refresh and publish schedules to freshness someone will defend

Transforms and calculated insights bill rows processed on every run, which makes refresh frequency a straight cost multiplier. An insight that runs hourly costs roughly 24x one that runs daily — cutting an hourly schedule to daily removes about 96% of that meter’s spend, and it’s frequently the fastest single win in the whole playbook.

Put numbers on it with an assumed workload: a batch calculated insight reading 10 million rows across its underlying objects bills 150 credits per run at the 15-credit batch multiplier. Hourly, that’s 3,600 credits a day and roughly 108,000 a month. Daily, it’s 4,500 a month. The insight’s consumers — a lifetime-value field, a churn score, a loyalty tier — almost never change hour to hour, and the dashboards reading them refresh daily anyway.

The audit question for every scheduled job is the same one from lever 1: who consumes this output, and how stale can it be before a decision changes? Ask it about transforms too. A transform feeding a nightly segment has no business running every fifteen minutes, and where transforms support incremental processing, changed-rows-only runs beat full refreshes on the same schedule.

Then apply it to segments. Segment publishes bill 20 credits per million rows processed — trivial per run, brutal on a fast clock. A segment processing 2 million rows costs 40 credits per publish: about 1,200 a month published daily, about 28,800 published hourly (again, assumed volumes). Match publish cadence to send cadence. A weekly newsletter audience doesn’t need an hourly refresh, and for journey-triggered sends, publishing on demand as part of the campaign flow beats any fixed schedule — fresh data exactly when it’s used, zero publishes in between. While you’re in there, act on Salesforce’s other standing tip: deactivate segments that are no longer used. Every org we’ve looked at has a few still publishing to campaigns that ended last quarter.

Lever 5: treat identity resolution changes as costed change requests

Profile unification carries the heaviest row-based multiplier on the card: 100,000 credits per million rows processed. At that rate, the difference between processing your full profile base and processing a daily delta is the difference between a capital cost and an operating one — and certain changes force the full version.

Salesforce’s credit-management guidance is specific about what triggers a full reprocess: altering match rules, modifying reconciliation rules, mapping new DLOs to data model objects, or adding new fields to mapped DMOs. Its first recommendation is equally specific: filter the DLOs feeding your rulesets so fewer rows get evaluated at all. The same article names identity resolution as the usage type behind most sudden consumption spikes, which matches what we see in Digital Wallet reviews.

The discipline that follows is organisational, not technical:

• Batch ruleset edits into planned releases. Four separate edits in a sprint can mean four full reprocessing runs over your entire profile base. One consolidated change means one.
• Cost the change before approving it. A ruleset edit on an org with 8 million source profiles is a ~800,000-credit decision at the full-reprocess rate. That’s an assumption-based example, but it’s the right order of magnitude to put in the change request.
• Experiment in sandbox. Sandbox multipliers run at a 20% discount to production — cheaper, though not free, so sandbox experimentation needs a budget too.
• Question ruleset count. Every additional ruleset is another unification meter. Two rulesets doing approximately one job is a common and expensive pattern.

Most teams put governance around Apex deployments and none around identity rulesets. The rate card says it should be the other way round.

Levers 6 to 8: watch the long tail, then automate the watching

The last three levers share a theme: cheap-per-row usage types and slow drift, both invisible until they compound. None of them needs re-architecting. They need an owner and a calendar.

Lever 6: queries, activations, and data shares

Below the headline meters sits a set of usage types that grow unbounded with volume. Individually they’re rounding errors. Left unwatched for a year, they’re a line item.

• Data queries bill 2 credits per million rows processed — the cheapest rate on the card. But “rows processed” reflects what the query engine touches, not what it returns, so an unfiltered query across a wide object with joins costs far more than its result set suggests. The usual culprits are BI tools and scheduled jobs polling on tight intervals. Give external tools filtered, purpose-built views and sensible refresh schedules.
• Activations are nearly free in batch at 10 credits per million rows, versus 1,600 for streaming DMO activation. Audit any streaming activation against the lever-1 test, consolidate duplicate activation targets, and trim related attributes to the ones the destination actually uses — every attribute rides along on every activated row.
• Data shares meter on the way out: 800 credits per million rows shared to external platforms, and streaming actions including lookups bill at the same 800 rate. Zero-copy patterns that felt free at design time still meter rows accessed, at 70 credits per million. Cheap, until a warehouse job starts scanning it nightly.

Lever 7: put Digital Wallet on a calendar

Everything above is a point-in-time fix. Consumption drifts — new streams appear, schedules get changed in a hurry, a campaign team clones twenty segments — so the durable savings come from monitoring that catches drift within days.

Digital Wallet is the free instrument for this. Its consumption cards give near real-time usage tracking broken down by usage type, with trend views across 7, 30, and 90 days showing exactly which meter moved. Since the September 2025 updates it also carries feature-level usage tagging, out-of-the-box consumption reports, and configurable threshold alerts, so you can see which specific stream, transform, or segment sits behind a meter instead of guessing.

The operating rhythm we recommend is deliberately small. Fifteen minutes, weekly, same person. Which usage type moved most versus last week, and what specific asset drove it? Spikes almost always have a mundane, named cause — and a fix that costs nothing in week one and a renewal negotiation in month eleven.

Lever 8: alerts, budgets, and meter owners

A weekly habit survives longer with structure around it. Three pieces make the review self-enforcing:

• Set threshold alerts now, not after the first overage. Alerts at staged percentages of your entitlement turn a surprise into a scheduled conversation.
• Pace the entitlement across the term. Rate card terms state credits must be used before the order end date with no rollover, and where credits exist across multiple order forms they pool, drawing down the earliest-expiring first. A simple months-elapsed versus credits-consumed line tells you if you’re running hot.
• Give each big meter an owner. Ingestion belongs to data engineering, segments to marketing ops, unification to whoever owns identity. Meters with owners get questioned; shared meters just get paid.

This is also the natural handover point if nobody internally has the bandwidth — consumption review is a standing item in our managed services engagements for exactly this reason.

The bill is feedback — use it

A quarter spent on this checklist typically ends in the same place: the levers weren’t secrets, they were defaults nobody revisited. Streaming where batch would do. Hourly where daily would do. Full loads where deltas would do. Ruleset edits shipped casually because nobody priced them. Consumption pricing punishes inattention far more than it punishes ambition.

That’s worth sitting with, because it reframes what the bill is for. A seat licence tells you nothing about your architecture. A consumption invoice is an itemised critique of it — every over-provisioned freshness requirement and unowned meter shows up as a number, monthly, with your name on it. Teams that read it that way stop treating credit optimization as a procurement problem and start treating it as an engineering-quality signal, which is what it actually is.

The capability you’re left with is portable, too. A team that can walk into a renewal with a usage-type breakdown, a freshness requirement for every flow, and a quarter of flat-or-falling consumption trends negotiates from evidence instead of fear. The same inventory that cut the bill becomes the forecast for the next contract, and the weekly fifteen-minute review keeps both honest. Run the eight levers once this quarter. Keep the last two running forever. The first invoice after that is the one that finally looks like the forecast.

Understanding the basics

How do you reduce credit consumption in Salesforce Data 360?

Work the levers in order of impact: move non-real-time flows from streaming to batch, ingest only the fields and rows your use cases need, slow transform and calculated-insight refreshes to match genuine freshness requirements, align segment publishes with send cadence, minimise identity resolution ruleset changes, and monitor everything weekly in Digital Wallet with threshold alerts. Most orgs find their bill concentrated in two or three usage types, so start where your own meters point.

What consumes the most credits in Data 360?

Per row, profile unification is the heaviest common meter at 100,000 credits per million rows processed on the official rate card, and sub-second real-time events bill at 70,000 per million. In total spend, external ingestion often rivals both because it runs every day. Streaming variants multiply costs further — streaming transforms bill 12.5x their batch rate and streaming DMO activation 160x — so streaming misconfiguration is a frequent top cost driver.

What is Digital Wallet in Salesforce?

Digital Wallet is Salesforce’s free monitoring layer for consumption-based products, including Data 360. Its consumption cards show near real-time credit usage broken down by usage type, with 7-, 30-, and 90-day trend views, feature-level usage tagging, out-of-the-box reports, and configurable threshold alerts that notify you when consumption crosses a percentage of your entitlement. It’s the primary tool for spotting consumption drift before it becomes an overage.

---

Staring at a Data 360 credit bill that outgrew its forecast? Talk to us — running this triage is a very normal week for our team.