# How to build predictive audience segments in Data Cloud A predictive segment needs an outcome you have already recorded. Without that history you have a rule. Call it a rule. **Published:** 2025-12-04 **Canonical:** https://synconai.com/predictive-audience-segments-data-cloud **Author:** SynconAI Architecture Team ## In short A predictive segment needs an outcome you have already recorded. Without that labelled history you have a rule, and you should call it a rule. A calculated attribute is arithmetic on data you hold. It is not a model. Data 360 ingests and unifies what you give it, by stream or by batch, and you can ground that data for Agentforce. It will not invent the outcome for you. ## Sources - **About Salesforce Data 360** (retrieved 2025-10-14) https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5 > Ingest, harmonize, unify, and analyze streaming and batch data with Data 360. - **About Salesforce Data 360** (retrieved 2025-10-14) https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5 > Ground your data for use with Agentforce. ## What to take away - Name the outcome, where it was recorded, and how far back the labels go. - If you cannot show the labels, publish a rule segment and say so. - A calculated attribute is a formula. Do not brief it as a prediction. - Agents should be grounded on the same recorded facts the segment uses. ## The guide Someone names a segment "likely to buy." The filter is an open opportunity and no activity in thirty days. The forecast meeting asks why the audience missed. Nobody can show a person who bought, a date, or a row the rule was checked against. An agent, grounded on the same segment, tells a seller the account is likely to close. The seller asks what "likely" means. The honest answer is that it means the filter. The briefing said otherwise, and the briefing is now the problem. ## Start from a recorded outcome The product is Data 360. Data Cloud is the previous name. Salesforce rebranded it on 14 October 2025, and the behaviour is unchanged. You may still see the old name in the application and the documentation. The help page describes the job, and the job is not prophecy: ingest streaming and batch data, harmonise it, unify it, and analyse it. "While the name is new, the functionality and content remains unchanged." An audience does not become predictive because you named the segment that way. A predictive segment needs labels. Someone bought, churned, attended, renewed, or raised a case, and you stored that fact against a person or an account you can still join. Write the outcome in one sentence. Name the object that holds it. Name the oldest month you trust, and why months before that are not in the set. If the sentence is "people who look like good customers," you do not have an outcome. You have a preference. Preferences are allowed in a conversation. They are not allowed to wear the word predictive. Without labels you can still build a useful segment. You should call it a rule. "Open opportunity and no activity in thirty days" is a rule. It can be the right activation. Calling it a model misleads the person who will be asked, later, why the audience missed, and it misleads the agent that repeats the name. The miss is then treated as model error. It was a filter that did what it said, briefed as something that learns. Labels have a grain. A purchase on an account is not a purchase by every contact on the account. A case opened by one employee is not a churn signal for the legal entity. Write the grain in the same sentence as the outcome. A label at the wrong grain will train, or will appear to train, a story about the wrong entity, and the segment will look precise because the counts are large. ## Calculated attributes are not a model A calculated attribute sums, counts, or combines fields you already store. Lifetime orders. Days since last case. A flag you derived from consent and region. These are formulas. They belong in the model when a segment or an agent will filter on them. They do not learn. They do not know about people who are absent from the inputs. When the formula is wrong, you fix the formula. You do not retrain it, and you do not brief a retraining. Keep the formula next to the segment definition, in words a marketer can read aloud. Hide the logic in a chain of nested calculations and the segment becomes folklore again. Folklore is what a migration was supposed to leave behind. If the only person who can explain the number has left, the number is not an asset. It is a risk with a decimal place. If a vendor or a teammate offers a score, ask three questions before it touches a segment name. What was the label. What period was it trained on, or, if it is only a formula, what does the formula do in one sentence. What do you do when a required input is blank. A blank match key or a blank outcome should not become a confident rank. Exclude the row, or mark it unknown. A default that fills the blank with an average is how a missing person becomes a middling score and then an audience. Identity resolution does not manufacture the label. It generates unified profiles from source profile data stored in Data 360. Those profiles are keys. They are not a golden record. The engine does not pick a winning value and does not override source values. If two sources disagree about whether the person bought, the profile points at both. It does not award you a clean training row. Reconcile the outcome in the system that recorded it, or keep the disagreement out of anything you call a label. A model, or a rule dressed as one, that trains on a contradiction will reproduce the contradiction at larger volume. ## A rule you are willing to sign Publish the rule under its real name. Put "rule" in the name if that is what it is. Reserve "predictive" for a labelled outcome you can show a stranger: the object, the month range, the grain, and a sample of rows where the label is true and a sample where it is false. If you cannot produce the false sample, you do not know what the rule excludes, and you will not know why a good customer was missing. The rule's inputs have to be maintained. Opportunity stage is a fine filter when sellers keep it current. It is a fiction when stage is a graveyard. Days since last activity is a fine filter when activity is captured. It is a fiction when half the team works in a channel you do not ingest. Write the maintenance assumption next to the rule. When the assumption fails, the segment fails in a direction that looks like insight: the "inactive" audience fills up with people who were busy somewhere you cannot see. Do not stack rules and then rename the stack. Three filters combined are still a rule. The combination needs its own sentence. "Stage is late, no activity in thirty days, and consent allows email" is one sentence. It is also three failure modes. Stage wrong. Activity missing. Consent blank, which is not a yes. The sentence makes the review possible. A score from zero to one, with the sentence missing, makes the review impossible, which is why people prefer the score. ## Ground the same facts you segment on The help page says to ground your data for Agentforce: "Ground your data for use with Agentforce." An agent that talks about likely buyers, from a segment you cannot explain, will sound certain and be wrong. The facts you ground are the same facts the segment filters on. The outcome, if you have one. The rule, in the sentence. The consent. The account. Do not ground a score you would not defend in the forecast meeting. The agent will repeat it to someone who cannot open the formula. Streaming versus batch matters here only as freshness. A rule that depends on "last activity today" needs the activity to arrive on a path that meets the word today. A prediction, if you truly have labels, is only as current as those labels and the inputs behind them. Say the refresh in the segment notes. A stale label presented as a live propensity is a reporting problem you created. It is not a property of the platform. Zero copy is federation, not a latency promise, and it does not label anyone. You can connect data using zero copy data federation so a wide history stays in the external store. A federated column can be an input to a rule if you have said which column, and if the person waiting on the segment can tolerate the read. It cannot invent an outcome that was never recorded. Do not federate a lake of clicks and call the result a propensity because the table is large. Size is not a label. Tableau Next does not replace Tableau. The help page says you can expand Data 360 using Tableau or Tableau Next. A chart of the segment count will not tell you whether the segment is a rule or a model. Title the chart with the sentence. If the asker already lives in Tableau, leave the chart there. Moving it to a new surface does not add labels you do not have. ## Consent, then a sample Check consent before activation, the same as any other segment. A predicted audience is still a list of people. The prediction does not create a lawful basis, and a rule does not either. Blanks stay out. Conflicts stay out until a person resolves them, with the stricter flag holding in the meantime. The activation side of that discipline is [segments for advertising](/data-cloud-segments-google-ads), and it does not relax because the segment name sounds scientific. Then read a sample. Twenty profiles. The label, or the explicit statement that there is no label. The rule in words. The blank fields. If the sample is nonsense, the segment is nonsense at full size. A percentage of "coverage" without a sample gets explained away. A profile in the sample with no outcome and a confident rank does not. ::: note If you cannot show the recorded outcome, ship the segment as a rule and say so in the name and in the brief. Renaming the rule after the meeting, so the slide can say predictive, is how the next meeting becomes an argument about a model you do not have. ::: ## A small build order Pick one outcome you have recorded for a period you trust, or admit you do not have one and stop at the rule. Build the rule that approximates the decision a person already makes, and publish it under its real name. Add calculated attributes only for inputs the rule uses. Leave the rest in the source until a question names them. A formula nobody filters on is decoration, and decoration is what makes the next author scroll past the field that matters. If, later, a real approach is trained on those labels, replace the briefing. Say what the label was, what period it used, and what happens on a blank. Do not rename the rule and hope the audience fails to notice. Keep the old rule available for a while, so someone can compare the two lists on the same accounts. If you cannot explain the difference in a paragraph, you are not ready to retire the rule. The paragraph is the test. A lift figure you cannot trace to a labelled row is not. The decisions underneath the labels are the ordinary Data 360 decisions: which records are the same entity, which source owns the outcome attribute, and whether that attribute is copied or referenced. They are cheaper before the first segment is published than after a seller has quoted the score. They are written up in [getting Data 360 right the first time](/insights/data-360-implementation-best-practices). | What you have | What to call it | What to do when it is wrong | | --- | --- | --- | | A recorded outcome you can join to a person or account | A candidate for a predictive segment | Revisit the labels, the grain, and the period | | A filter you can say in one sentence | A rule | Fix the sentence and the inputs | | A sum, a count, or a flag over fields you store | A calculated attribute | Fix the formula. There is nothing to retrain | | A score with no label, no period, and no blank rule | A preference with a number | Do not publish it. Do not ground an agent on it | ## What you leave unnamed on purpose Do not call a lookalike a prediction. Do not call a seller's intuition a model because you stored it in a field. Do not let an activation destination's own optimisation rename your rule on the way out. The name your organisation uses in the brief is the name you will have to defend. Keep it dull enough to be true. One outcome or one rule. One segment. One sample of twenty. One sentence in the campaign brief that matches the segment notes. Then stop. A second score in the same month is how the first sentence gets replaced by a dashboard nobody can read aloud. ## Questions ### Can we mark a segment predictive without historical outcomes? You can misuse the word. You should not. Without a recorded outcome you have a rule. Name the rule and ship it as a rule. A filter on an open opportunity and a quiet month can be the right activation. Calling it a model misleads the person who later asks why the audience missed, and it misleads any agent that repeats the name. ### Is a calculated attribute a predictive model? No. It is arithmetic on data you already hold. Document the formula in words a marketer can read. Fix the formula when it is wrong. There is nothing to retrain. A blank input should exclude the row or mark it unknown, rather than become a confident rank. ### What should we ground for Agentforce? The recorded facts you are willing to defend: outcomes, rules, consent, and account context. The Data 360 help page says to ground your data for Agentforce. Do not ground a score you cannot explain in a forecast meeting. The agent will repeat it. Ground the same sentence the segment uses, not a renamed version of it. ### Does Data 360 create the training labels for us? No. It ingests, harmonises, and unifies what you send, by stream or by batch. The outcome has to exist in a source you trust before you call any audience predictive. Identity resolution points at source rows. It does not pick a winning label when two sources disagree, and it does not override them. ### How do we keep a rule from being briefed as a model? Put the plain-language definition in the segment notes and in the campaign brief. Use the word rule in the name if the audience is a filter. Reserve predictive for a labelled outcome you can show, including the object, the period, and the grain. If you cannot show a row where the label is false, you do not yet know what the audience excludes. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Data 360 (https://synconai.com/salesforce-data-360-services.html).