# How Data Cloud improves the accuracy of Einstein AI predictions A model learns the history you give it. Data Cloud was rebranded to Data 360 on 14 October 2025, and that history is what identity resolution and field hygiene can make fairer. More rows of the same bad Opportunity data do not make a score wiser. **Published:** 2026-02-05 **Canonical:** https://synconai.com/data-cloud-einstein-prediction-accuracy **Author:** SynconAI Architecture Team ## In short A prediction learns the history you give it. Data Cloud was rebranded to Data 360 on 14 October 2025. Identity resolution and feature hygiene can make that history fairer. More rows of the same bad Opportunity data do not. Grounding Agentforce is retrieval for an answer, a different job from training a score. Fix who the record is, and what the fields mean, before you add volume. ## Sources - **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. - **About Salesforce Data 360** (retrieved 2025-10-14) https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5 > As of October 14, 2025, Data Cloud has been rebranded to Data 360. During this transition, you may see references to Data Cloud in our application and documentation. While the name is new, the functionality and content remains unchanged. ## What to take away - Data Cloud is Data 360 as of 14 October 2025. The name changed. You may still see Data Cloud in the application and the documentation. - Identity resolution can join a split history. It does not elect a winning value, overwrite the source, or produce a golden record. - Stage, amount, and close reason have to mean one thing before a model should learn them. A renamed column does not decide the meaning. - Grounding Agentforce is retrieval for an answer. A well grounded reply is not proof the prediction got better. ## The guide Sellers advance Opportunity stage on a Thursday afternoon so the weekly meeting has movement to show. The stage is not a description of the deal. It is a description of the meeting. A model trained on that history learns that Thursday movement predicts whatever happened next, including the losses. Adding a second year of the same behaviour gives it more confidence in the habit. It does not create a cleaner definition of a win. The score gets surer about a fiction the forecast already suffered from. A prediction learns what your history actually did, including the bad habits. Data 360 is where that history can be assembled, and it will assemble the fiction just as willingly as the fact. The work that moves a score is deciding who the row is, and what the fields mean, before the extract gets larger. Salesforce states that as of October 14, 2025, Data Cloud has been rebranded to Data 360. During the transition you may still see Data Cloud in the application and the documentation. The name changed. The functionality did not. Say both names while your org and your papers still use both. A programme that announces better predictions because the product was renamed has changed a label. The history underneath is the one the model will learn. The history you assemble is also the data you can ground an agent on. Those are related, and they are not the same task. One is a score learned from outcomes. The other is a fact retrieved for an answer. This page keeps them apart. The decisions that belong before any of that history is connected are in [getting Data 360 right before ingestion](/insights/data-360-implementation-best-practices). What follows is the narrower question: what, in that history, a prediction is allowed to treat as a feature. ## Identity resolution changes who the row is Duplicate Accounts split one customer's Opportunities across two histories. A score then learns two thin stories instead of one. A win on the billing Account and a loss on the service Account look like two customers with two fates. They were one customer, recorded twice, and the model will treat the split as information. Identity resolution in Data 360 is the processing that builds unified profiles from source profiles. Use it when the same organisation, household, or person arrives from more than one system, and use it before you ask a model to learn across those systems. It will not save you from a loose match rule. Join too eagerly and two real customers become one history, which is a different way to be wrong, and a quieter one. The joined history looks richer. More stages, more amounts, a longer trail of activity. Nothing on a dashboard distinguishes it from a customer who genuinely had that trail. The score learns a person who never existed, and it will sound more confident than the two correct, thinner scores would have. The unified profile is not a golden record that has chosen the best amount or the best stage. Resolution does not elect a winning value and does not overwrite the source row. If the source stages are muddled, the unified profile is a joined muddle. If one source records amount including tax and another records it without, the join does not adjudicate the tax. It gives you both, still meaning different things, now sitting where a model can treat them as one feature. Check a sample of matches by hand before a model learns from them. Read pairs you expect to match and pairs you expect not to, including shared household names, generic mailboxes, and the test Accounts nobody deleted. [How duplicate records should be judged](/data-cloud-identity-resolution-duplicates) is its own discipline. This page only needs the consequence for a score: a wrong join is a wrong training row, and it fails silently because the row looks complete. The audit that should happen before a migration pours more of those rows in is [what to check in the source before you move it](/audit-data-quality-before-data-cloud-migration). Volume added on top of an unchecked match rule is how the fiction gets a larger sample. ::: warn A loose match is worse than a duplicate. Under-matching leaves two thin histories, which you can see. Over-matching builds one rich history of two real customers, which looks like a success and teaches the score a person who is not there. ::: ## Feature hygiene changes what the row means Volume is not a feature. A feature is a field with one meaning, stable enough that a new manager and an old report would describe it the same way. Opportunity stage names that differ by region, amounts that sometimes include tax, and close dates that mean the meeting in one team and the signature in another, teach the model the inconsistency. The model does not experience inconsistency as a problem to flag. It experiences it as the pattern. Pick the fields a score is allowed to learn, and write the definition in a sentence a sales manager can reject. Stage means this checkpoint, and a move that exists only to feed a meeting is not a checkpoint. Amount means this figure, tax in or tax out, one of them, everywhere. Close reason means a list you already require, not a free-text apology. Close date means the signature, or the meeting, and you have chosen. A field you cannot define in that sentence is a field the model should not see, however populated it is. Make the bad values visible before you add more extracts. A required close reason. A report a sales manager already trusts, that shows stages jumped and jumped back inside a week. Hygiene is boring, and it is the part that can move accuracy. A larger extract of the same file does not. Harmonising a column name, so that three sources all present a field called Amount, does not decide which business meaning is correct. The model inherits whatever you decide, including a decision you avoided by calling the harmonised column done. There is a habit of including every field because more signal feels safer. A field that records the Thursday meeting behaviour is signal. It is signal about the meeting. Leave it out, or label it as activity rather than as stage, so the score cannot confuse the two. Refusal is part of feature design. The list of fields you will not let the model learn belongs next to the list you will. | Field | Fit to learn when | Leave it out when | | --- | --- | --- | | Stage | One definition, and moves match that checkpoint | Teams advance it to feed a meeting, or names differ by region | | Amount | Tax in or tax out, the same way on every source | Sources disagree and the join did not adjudicate | | Close date | It means the signature, or the meeting, and you have chosen | The two meanings are mixed in one column | | Close reason | A required list a manager already uses | Free text, or a reason filled in after the loss to satisfy a field | | Activity counts | You can say what the count is evidence of | The count is mostly the Thursday meeting itself | A row that fails the middle column is not improved by being unified. It is the same row, easier to find. ## Grounding is a different use of the same data Salesforce's Data 360 guidance is to ground your data for use with Agentforce. Grounding means the agent retrieves a governed fact and answers from it. A prediction means a model trained on historical outcomes emits a score. A well grounded reply about an Account does not mean the win score on that Account got better. Do not report one as the other. A steering pack that shows a helpful agent transcript beside a chart labelled accuracy has joined two projects with a comma. Use Data 360 for grounding when the answer depends on a resolved person or account across sources, and when you have already decided which source wins for the attribute the agent will say aloud. That decision is not what identity resolution does for you. Resolution joins. It does not pick the value. If the agent needs one amount to quote, someone still has to say which source's amount, for that use case. The grounding checks that catch a stale or invisible article are in [the grounding checklist](/insights/agentforce-grounding-checklist). Passing them means the reply is tied to a fact the running user can see. It does not mean a score moved. Keep the prediction story on its own page of the pack. Which object. Which fields. What you refused to let it learn. How you will notice if the history is still biased, which means a person reads a sample of high scores and asks whether the underlying stages were real checkpoints. If you cannot describe the history in those terms, you cannot claim the score improved. You can claim you connected a source. Connection is not accuracy. ::: note Say which outcome you mean. "The data is in Data 360" covers neither a grounded answer nor a better score. One is a retrieval you can trace. The other is a history you can defend. They fail separately, and they should be reported separately. ::: ## What does not move accuracy More rows of the same bad Opportunity history. A second year of Thursday stage moves is a second year of the same lesson. The model becomes harder to argue with, because the sample is larger, and the argument was about meaning rather than about sample size. A rename from Data Cloud to Data 360 with no change to match rules or fields. The application may still say Data Cloud while you are in the middle of the transition. Neither label touches a stage definition. A prompt that tells an agent the score is usually right. The prompt does not edit the training rows. It edits the confidence of the sentence wrapped around the score, which is how a biased score reaches a seller looking like a fact. If you surface a score at all, surface the definition with it: which fields, and what you refused. An integration user that can see every record. That changes what an agent can say. It does not change what the model was trained on. Widening access to make a grounded demo quote more fields is a permissions decision, and it belongs in the grounding work. It is not an accuracy programme. The failure mode is a programme that buys the rebrand, skips the identity sample, harmonises column names, and announces better predictions because the extract is larger. You will not know if accuracy moved. You will know that the slides did. Fix who the record is. Fix what the fields mean. Then, and only then, decide whether you have a history worth learning. If the Thursday meeting is still in the stage field, you do not. ## Questions ### Is Data Cloud a different product from Data 360? No. Salesforce states that as of October 14, 2025, Data Cloud has been rebranded to Data 360, and you may still see the old name in the application and the documentation. The functionality is unchanged. Say both names while your org and your papers still use both. A rename on its own does not change match rules, field definitions, or what a model will learn. ### Will more historical rows make Einstein predictions more accurate? Only if the extra rows are a fairer record of what happened. More rows of the same loose stages, tax-inconsistent amounts, and duplicate Accounts teach the habit more firmly, and a larger sample makes the habit harder to argue with. Identity resolution and feature hygiene are the changes that can move accuracy. Volume alone does not. A second year of stages advanced for a weekly meeting is a second year of the same fiction. ### Does identity resolution produce a golden record? No. It builds unified profiles from source profiles stored in Data 360, and it does not pick a winning value or overwrite the source. A bad stage on the source is still a bad stage after the join. Amounts that disagree about tax still disagree. Match rules that merge two real customers create a new error, and the joined history looks richer, which is why it gets mistaken for a better row. ### Does grounding Agentforce improve the prediction? Not by itself. Grounding is retrieval so an agent can answer from governed data, which is what Salesforce means by grounding data for Agentforce. A prediction is a score learned from history. Report the two as separate outcomes. A good answer does not mean the score moved, and a prompt that calls the score usually right does not edit the training rows. It only makes the sentence around the score more confident. ### What should we fix before we trust a score? Who the record is, and what the fields mean. Verify a sample of matches by hand, including pairs that must not join. Give stage, amount, and close reason one definition each, in a sentence a sales manager can reject. Leave out fields that mostly record a meeting rather than a checkpoint. If you cannot explain the history to a new manager, do not ask a model to learn it, and do not publish the score as an improvement. --- 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).