Run the methodology with a senior advisor.
A senior Admodum advisor will walk the methodology through with your CIO, CDO, CMO or procurement team on a private call. Engagements run as fixed fee, contingency or annual retainer.
Twenty pages on the Salesforce Data Cloud credit consumption model and the commitment sizing methodology. Profile and event ingestion sizing, segmentation activation, Agentforce data dependency, Tableau and MuleSoft adjacencies and the exit architecture inside the credit pool.
Salesforce Data Cloud (formerly Customer Data Platform, formerly Genie) is the Einstein 1 platform’s data substrate. It ingests profile data and event data from across the buyer’s estate (Salesforce-native and non-Salesforce), constructs unified profiles, supports segmentation, activates the segments into downstream channels, and underpins the Einstein 1 / Agentforce platform’s access to live customer data.
Data Cloud’s commercial logic is straightforward. Salesforce is migrating the surface of its product portfolio onto the Einstein 1 platform. Einstein 1 depends on Data Cloud as the data substrate. The buyer’s investment in Data Cloud therefore underpins the buyer’s ability to operate Sales Cloud, Service Cloud, Marketing Cloud and Agentforce against unified customer data. The publisher’s framing is that Data Cloud is an enabling platform commitment, sized against the buyer’s ambition.
The buyer’s framing is different. Data Cloud is a credit-consumption commitment with a documented credit-cost schedule. The commitment is contestable; the consumption is sizable from the use case map; the cost arithmetic is transparent. The Admodum methodology in this paper turns the publisher’s narrative-driven sizing into an evidence-driven sizing.
Data Cloud sells through a credit consumption commercial model. The buyer commits to an annual credit pool. Every action inside Data Cloud (profile ingestion, event ingestion, identity resolution, segment build, segment refresh, activation, query) consumes a documented quantity of credits against the pool. At year-end, the credit pool retires against the consumed credits.
Salesforce publishes a credit-cost schedule that maps each Data Cloud action to a credit cost. Profile ingestion costs a published rate per profile per source. Event ingestion costs a published rate per event. Segment build costs a published rate per segment per build. Activation costs a published rate per activation target per push. Identity resolution and queries are similarly priced.
The schedule is the single most important contract artefact inside the Data Cloud commitment. The schedule is the input to the buyer’s sizing arithmetic; it is the determinant of the buyer’s actual consumption rate; and it is the document the buyer holds against the publisher when the next-term pool is sized.
Over-consumption (consuming above the committed credit pool) is converted into a published over-use rate, typically billed at the over-use rate against the credits consumed above the pool. The over-use rate is higher than the committed rate. Under-consumption (consuming below the pool) does not refund; the unused portion expires at year-end in most contract constructs.
Profile ingestion is the consumption that drives the credit pool for many Data Cloud customers. Each ingested profile from each source carries a credit cost; the cost compounds with profile-resolution work as the same individual is matched across multiple sources into a unified profile.
Buyers commonly underestimate the source-count multiplier inside profile ingestion. A customer record ingested from three sources (Sales Cloud, Marketing Cloud and a non-Salesforce CDP) is not one profile ingestion; it is three profile ingestions, plus the identity resolution work that joins them into a unified profile, plus the ongoing refresh credit cost as each source updates the underlying record.
The buyer’s sizing arithmetic begins with the source map: every system that will write a profile or an event into Data Cloud, the expected volume per source, the expected update frequency and the expected attribute completeness. The credit-cost schedule is then applied per source to produce the annual ingestion credit consumption.
Event ingestion (transactional events, web events, mobile events, marketing events) is sized against the per-source event volume and the event retention window. High-volume event sources (a transactional commerce stream, a marketing-attribution event stream, a web-clickstream stream) are the principal credit-pool drivers on the event side.
The Admodum protocol caps event ingestion at the use-case threshold rather than the source threshold. An event source that supports five use cases at 1% of its volume is a candidate for sampled ingestion at 5%, not the full 100%. The principle is to ingest the events Data Cloud actually needs, not the events the source can produce.
Segmentation is the principal Data Cloud workflow. Segments are constructed against the unified profile store; segments are refreshed on a cadence (continuous, scheduled, or on-demand); segments are activated into downstream channels (Marketing Cloud, Advertising Studio, Commerce Cloud, Service Cloud or third-party destinations).
A segment build (the construction or refresh of a segment definition against the profile store) consumes credits at a published rate. The rate depends on the segment complexity, the segment size and the refresh frequency. Continuous segments (segments refreshed in near-real-time as the underlying profile changes) carry the highest credit cost per unit time; on-demand segments (refreshed only when explicitly built) carry the lowest.
Activation (the push of a segment into a downstream channel) consumes credits against the activation target and the activation cadence. A single segment activated daily into a marketing channel for a year is 365 activation events; a single segment activated weekly is 52. The activation envelope dominates the credit consumption for activation-heavy use cases.
The buyer’s activation discipline is the principal lever inside the segmentation conversation. The discipline is a use-case-by-use-case decision: which segments need continuous refresh, which need daily, which need weekly, which need monthly. The discipline produces a refresh and activation profile that sizes the credit-pool consumption against the operational need, not the operational maximum.
Agentforce, the Salesforce agentic-AI commercial layer, depends on Data Cloud as the customer-data substrate. An Agentforce agent that operates against live customer data accesses that data through Data Cloud; the access consumes credits inside the Data Cloud pool.
The dependency means the Data Cloud commitment cannot be sized independently of the Agentforce rollout. An Agentforce rollout that touches one thousand customers per day at five data-access events per conversation is five thousand data-access events per day inside the Data Cloud credit pool. The Agentforce per-conversation pricing sits on top of the Data Cloud consumption; the buyer pays for both layers.
The Admodum protocol sizes the Data Cloud commitment alongside the Agentforce commitment. The Agentforce rollout plan documents the agent inventory, the per-agent conversation volume, the per-conversation data-access count and the per-data-access credit cost. The aggregate is added to the Data Cloud credit-pool sizing alongside the segmentation and activation envelopes.
Tableau and MuleSoft sit alongside Data Cloud inside the Salesforce portfolio. The adjacencies create commercial decisions inside the Data Cloud commitment that are not visible from the Data Cloud line in isolation.
The Tableau-Data Cloud connector enables Tableau to query Data Cloud directly. Each Tableau query against Data Cloud consumes credits inside the Data Cloud pool. Buyers with substantial Tableau use cases pointed at Data Cloud must include the Tableau query envelope inside the Data Cloud credit-pool sizing.
MuleSoft is the integration platform that moves data into and out of Data Cloud. MuleSoft is sold separately, on its own subscription, but the MuleSoft pipeline sizing has implications for Data Cloud: a richer MuleSoft pipeline drives more data into Data Cloud and therefore more credit consumption inside the Data Cloud pool. The two are jointly sized.
The rationalisation question, against an existing data warehouse stack (Snowflake, BigQuery, Databricks), is whether Data Cloud replaces the warehouse layer or sits alongside it. The answer is rarely “replaces”. The Admodum default position is “sits alongside, with documented data-flow paths in each direction”, and the Data Cloud commitment is sized for the customer-data-platform workload, not the general-purpose analytical workload.
The exit architecture is the post-Data Cloud position the buyer carries out of the commitment. Three exit patterns recur across the Admodum Salesforce practice.
Pattern one: Data Cloud replacement with a third-party CDP (Adobe Real-Time CDP, Tealium, Treasure Data, Segment). The pattern requires the buyer to extract the unified profile store, the segmentation definitions and the activation history. The Salesforce-native dependency on Data Cloud (Einstein 1, Agentforce) is then re-pointed at an alternative data substrate, with implications for the breadth of those dependencies. Pattern two: Data Cloud retention at a smaller credit pool, sized against a narrower set of use cases, with the broader use case map retired or moved to an alternative platform. Pattern three: Data Cloud retention at the existing pool, with the use case map rationalised against the trailing-period evidence to ensure the pool maps to the actual consumption.
The portability constraints sit principally on the segmentation definitions and the activation history. Profile data can be exported; segmentation definitions are encoded in a Salesforce-proprietary segment-definition language; activation history is held inside Data Cloud’s execution layer. The exit cost is therefore not in the data; it is in the segmentation and activation re-build.
The Salesforce Data Cloud paper sits inside a multi-paper Salesforce reading list. The companion papers extend the methodology into the adjacent commercial mechanics:
The methodology in this paper is the methodology Admodum has applied across more than twelve Salesforce Data Cloud commitments. Each engagement is structured as fixed fee, contingency / gainshare or annual retainer, depending on the buyer’s posture at the commitment window.
A senior Admodum advisor will walk the methodology through with your CIO, CDO, CMO or procurement team on a private call. Engagements run as fixed fee, contingency or annual retainer.