Introduction to Analytic Models: Purpose, Types, and Where They Fit
Understand what an Analytic Model is in SAP Analytics Cloud, why it exists, the two core model types (Account and Measure-based), and how it differs from a Story or a Datasphere view.
Explanation
An Analytic Model in SAP Analytics Cloud (SAC) is the semantic object that sits between raw data (imported flat files, live connections, or Datasphere/BW views) and the consumption layer (Stories, Analytic Applications, Planning). Without a model, SAC has no structured way to understand which fields are dimensions (descriptive attributes like Region, Product, Cost Center), which are measures (numeric facts like Revenue, Quantity), how time is represented, and how currency or unit conversions should behave. The model is where you define this structure once and reuse it across many stories and applications, which is the core reason models matter: consistency and governance. If every story builder redefined calculations independently, you would get inconsistent KPI definitions across the business, a common real-world failure mode auditors flag during BI governance reviews. SAC supports two foundational analytic model types. An Account model uses a special 'Account' dimension where each member represents a measure (e.g., Revenue, COGS, Headcount), and all numeric values live in a single generic 'value' column tagged by account member. This pattern mirrors classic OLAP/planning cubes and is required for most planning models because it lets you add new KPIs by adding dimension members rather than restructuring the model, and it supports version/category dimensions needed for planning versions (Actual, Budget, Forecast). A Measure-based model instead has distinct, separately named measure columns (Revenue, Quantity, Cost) similar to a wide table; it is simpler to build and understand for straightforward reporting use cases, and it is the only supported type for import-based models built from wide flat files with multiple numeric columns, though live models can also use this pattern. Models can be built in three data acquisition modes: Import (data is copied/snapshotted into SAC's in-memory store, refreshed on a schedule or manually), Live (SAC queries the source system live, no data stored in SAC, commonly used for SAP BW or HANA live connections and increasingly for Datasphere), and now Datasphere-integrated models which behave similarly to live/import hybrids depending on the space configuration. The choice affects performance, data freshness, security enforcement location, and available modeling features (e.g., certain calculations are only available in import models because they execute in SAC's engine rather than pushing down to source). A critical beginner distinction: a Story is NOT where data structure lives — Stories only visualize data that a Model already structured. This separation is intentional: it allows the same governed model to feed multiple stories, dashboards, and planning applications without duplicating business logic. Confusing 'building a chart' with 'building a model' is the most common early mistake; new users often try to create calculated measures inside a story that should actually live in the model so they are reusable and consistent. Dimensions in a model can be flagged with special roles: Time dimension (enables time-based functions like YTD, prior year), Organization dimension (used for currency conversion logic), Version dimension (mandatory for planning, distinguishes Actual/Plan/Forecast), and Account dimension (for account-model measures). Getting these role assignments right during model creation is foundational — changing them later often requires significant rework or model recreation, so architects should plan dimension roles before loading production data.
Real project scenario
A retail client wanted a single 'Sales Performance' model to feed five different stories (regional dashboard, executive summary, product profitability, a planning app, and a mobile view). The consulting team built one Account-based Analytic Model with Region, Product, Time, and Version dimensions, defined Revenue, Cost, and Margin as account members with calculated logic once in the model. All five consumption artifacts pulled from this single model, so when finance later corrected the Margin formula, it updated everywhere automatically instead of requiring five separate story-level fixes.
Common mistakes
• Building calculated measures repeatedly inside individual Stories instead of once in the Model, causing inconsistent KPI values across dashboards • Choosing a Measure-based model when planning is a future requirement, then having to rebuild as an Account model later • Not assigning a Time dimension role, which disables time intelligence functions (YTD, prior period) in downstream stories • Assuming Import models auto-refresh; forgetting to schedule or trigger data refresh leads to stale dashboards • Treating the model build as a one-time task rather than validating dimension granularity matches all planned consumption use cases upfront
Best practices
• Decide Account vs Measure-based model type before any data load, based on whether planning or multi-KPI flexibility is needed • Assign dimension roles (Time, Organization, Version, Account) deliberately at model creation, not as an afterthought • Centralize all reusable calculations in the model, not in individual stories • Document the model's intended consumption scenarios (which stories/apps will use it) before finalizing granularity • Validate that at least one Version member (e.g., Actual) exists before enabling planning on an Account model
Interview angle
Interviewers commonly ask candidates to explain the difference between Account and Measure-based models and justify when planning requires the Account type. A strong answer connects the Version dimension requirement for planning to the Account model's flexibility in adding KPIs without restructuring, and explains why Story-level logic duplication is an anti-pattern versus model-level governance.