Ingestion, segmentation and activation, and how to forecast consumption before you commit. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real SAP negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back. Session twelve, Data Cloud in practice. Last time we established what a credit is and why the bill moves without anybody buying anything. Today we do the useful half: how the three stages of the pipeline each bill you, which design decisions actually move the number, and how to build your own consumption forecast before somebody hands you one. This is the session that changes what you sign. So: three stages and three meters, the ingestion decisions, segmentation and activation, the five step forecast, and what to do when your number and theirs disagree by a third. Three knowledge checks. Let's begin.
Five objectives. First, follow the data through three meters, because ingestion, segmentation and activation bill separately and each has its own driver. Second, ask the frequency question: what decision changes because this data is an hour old rather than a day old. Third, cut consumption without cutting value, by filtering at source, narrowing the profile, refreshing on demand and batching activations. Fourth, build a bottom up forecast from row counts you can prove, multiplied by the rate card, with the contingency stated. And fifth, use the gap, because when your number differs from theirs, that difference is the negotiation rather than an error in your arithmetic.
So, three stages and three meters, and the same record can be billed at every step. Bring it in: ingestion, driven by rows times refresh frequency, where the cheapest row is the one you filter out. Make it one: identity resolution and processing, driven by ruleset complexity and rerun frequency. Cut the list: segmentation, driven by segment count, size and how often each one recalculates. And send it out: activation, driven by destinations and publish frequency, where five channels is five activations. Let me explain why the design conversation and the commercial conversation almost never happen in the same room.
Guest analyst clip.
Nobody designs a pipeline with the rate card open beside them, and that is exactly the habit worth building. It costs nothing to have the consumption implication written next to each design decision, and it is nearly impossible to reconstruct afterwards.
Right, four ingestion decisions and what each one does to the meter. Refresh frequency: the cheap answer is as slow as the decision allows, because hourly rather than daily is roughly twenty four times the rows. Filter position: filter at source before it arrives, since filtering after ingestion means paying to bring in what you then discard. Field selection: only the fields that resolve identity or drive a decision, because whole table replication is billed on every refresh, forever. And history depth: the window the use case needs, rather than ten years of history reprocessed to answer a ninety day question. Every one of these is reversible in the platform and expensive to have got wrong, because the consumption was already spent by the time anybody looked at it.
First knowledge check. Marketing asks for an hourly refresh on a source that feeds a weekly campaign. What is the right question to ask? A, can the platform support hourly at this volume. B, what decision changes because the data is an hour old rather than a day old. C, do we have enough credits left this quarter. D, can we get a discount on the additional consumption. Pause here and pick an answer before you continue.
B. Frequency is the single largest lever in the whole model, and it is almost always set by preference rather than by requirement. B forces the requirement into the open, and for a weekly campaign the honest answer is usually that nothing changes at all. A is a capacity question the platform will happily answer yes to, which is how the spend happens. C is the right instinct at the wrong moment, because it treats the balance as the constraint rather than the need. And D negotiates the price of something you may not need to buy.
Segmentation next, and this is the stage that quietly outspends the others. Scheduled beats nothing and on demand beats scheduled, because a segment refreshed hourly recalculates whether anybody used it or not. Size compounds with frequency, so a large audience refreshed often is the largest single line in most estates I see. Nested segments recalculate upstream, meaning one refresh can trigger the parents it depends on, which nobody sees in the builder. Retire what nobody opens, because segments built for a campaign that ended are still refreshing on the original schedule. And count them quarterly, since segment sprawl looks like nothing on a screen and reads very clearly on a consumption report. Now activation, where the arithmetic changes shape.
Guest analyst clip.
Multiplication, not addition. So to be concrete: one audience to five channels is five activations, and each publish repeats all five. Publish on change rather than on a timer, because most destinations do not need the same list resent every hour to stay useful. Consolidate overlapping audiences, since three near identical segments feeding one channel are three bills for one outcome.
And watch the test destinations, which is the one that embarrasses people. A sandbox channel wired up during a pilot, still receiving production volume two years later. Then ask what the channel actually does with it, because if the downstream tool batches daily, hourly activation buys you precisely nothing.
Second knowledge check. Same business outcome, two designs. Which consumes less? A, ingest the full table then filter inside Data Cloud. B, filter at source and ingest only the rows the use case needs. C, ingest everything and archive the unused rows monthly. D, there is no difference, the meter counts what you keep. Pause here before you continue.
B. The meter counts what arrives, not what survives, so anything you discard after ingestion has already been paid for, and it will be paid for again on every single refresh. A is the default because it is the easiest thing to build, and it is the most common design mistake in the whole platform. C adds a storage cost on top of the ingestion cost you already incurred. And D is the assumption underneath both A and C, which makes it the one worth correcting first in any design review.
So let me give you the forecast method. Five steps, bottom up, in a spreadsheet you own. One, count the rows per source, using actual volumes from the source system multiplied by refreshes per month. Two, decide what needs unifying, because not every ingested row belongs in the profile and processing is metered separately. Three, count segment refreshes: segments, times profile set size, times how often each recalculates. Four, count activations: audiences, times destinations, times publishes, which is where the multiplication happens. And five, apply the rate card and add contingency, thirty to forty percent, stated openly. Let me explain why the spreadsheet being yours is the part that matters.
Guest analyst clip.
An account team cannot argue with your own row counts. They can argue with a benchmark, they can argue with an opinion, and they cannot argue with a number you pulled from a system you run, which is why this is the strongest position available to you in a consumption negotiation.
So what do the two numbers tell you. Theirs is top down, built from a use case deck, an industry benchmark and an ambition for year three. Yours is bottom up, built from row counts you can evidence from systems you already operate. They will differ, commonly by a third or more, and the direction is almost always the same one. The gap is the conversation, so walk them through your model rather than simply rejecting theirs. And then structure around it: commit near your number, ramp toward theirs, and keep rollover for the difference, which turns a disagreement about a forecast into a contract that survives either of you being right.
Five failures. The pilot that became production, where everything was ingested at maximum frequency to prove it worked and then never revisited. Frequency set by preference, so hourly because it was in the dropdown, defended afterwards as a business requirement. Segments that outlive campaigns, still refreshing on schedule two quarters after the last send. No design review for consumption, because architecture reviews test whether it works and never what it costs to keep working. And accepting their forecast, which means signing a commitment built from somebody else's benchmark rather than your own volumes.
Last knowledge check. Your bottom up forecast is forty percent below the commitment being proposed. What do you do? A, accept the proposal, the vendor has seen more implementations than you have. B, refuse to commit and buy everything on demand. C, present the model, commit near your number, and ramp toward theirs with rollover. D, split the difference, since the truth is usually in the middle. Pause here and pick an answer before you continue.
C. A model built from your own row counts is the strongest position available in a consumption negotiation, because it is specific, evidenced, and not something an account team can wave away with a benchmark. A concedes the largest number in the deal to somebody whose incentive runs the other way. B pays the on demand premium on every credit and throws away the only discount available to you. And D is negotiation by arithmetic rather than by evidence: if your model is wrong then correct the model, and if it is right, a ramp with rollover already covers the uncertainty. Let me set out the review that produces all of this.
Guest analyst clip.
One session, before anybody signs anything. The pipeline on one page: every source, its refresh, its filter, and the profile fields it contributes. The frequency justification, so for anything faster than daily, the decision that depends on it written in one line, and the blanks left visible. The forecast and its assumptions, challengeable, and owned by you rather than by the implementation partner. The design levers not yet used, meaning what you would change first if consumption ran thirty percent hot in month four. And the commitment recommendation: a number, a ramp, and the contract terms that make being wrong survivable.
Three sentences. The same record is metered as it arrives, as it is unified, as it lands in a segment and as it is published, so pipeline design decides Data Cloud cost far more than the unit price does, and the cheapest row remains the one you filtered out at source. Refresh frequency is the largest single lever and it is usually set by preference rather than requirement, which makes the question what decision changes because this data is an hour old rather than a day old, and for most use cases the honest answer is none. And build the forecast bottom up from row counts you can evidence, apply the rate card, state your contingency, and when your number differs from theirs by a third, treat the gap as the negotiation.
Homework before session thirteen, about two hours because this one is worth the time. One, map one pipeline end to end, from a source through unification into a segment and out to a channel, noting the meter at each step. Two, list every refresh faster than daily and write the decision that depends on the extra freshness, leaving the blanks visible. Three, find one filter you can move to source, estimate the rows it removes per month and multiply by the refresh count. Four, count your segments and their schedules, then mark the ones tied to a campaign that already finished. And five, draft the forecast skeleton: five rows, ingestion, processing, segmentation, activation and contingency, and fill in what you can.
Five guides, all on redresscompliance dot com. Salesforce Data Cloud pricing sets out credit costs by operation, which is the rate card side of today. The Salesforce Data Cloud and Agentforce guide shows how the data layer feeds the agent layer and what each one bills for. Negotiating Salesforce AI and Data Cloud licensing covers taking a bottom up forecast into the negotiation itself. Salesforce Data Cloud licensing covers the meter, the families and where the commitment sits. And Salesforce hidden costs collects the wider set of lines that arrive after signature.
That is session twelve. The thing to take away is that in a consumption model the design is the purchase order, so the cheapest hour you will ever spend on Data Cloud is the hour you spend with the rate card open next to the pipeline diagram. Next time, Agentforce: conversation based pricing, Flex Credits, and how to size an agent programme honestly rather than optimistically. See you then.