SAP Analytic Models Tutorial (Part 1)

An Analytic Model in SAP Analytics Cloud (SAC) is the central metadata object that defines how raw data is structured, described, and made available for analysis, planning, and predictive use cases. Before a business user can build a story, chart, or planning input form, someone must first create a model that tells SAC what the data means: which fields are dimensions (descriptive attributes like Region, Product, Cost Center), which are measures or accounts (numeric values like Revenue, Quantity), how time is represented, and how currency and units behave.

Why this matters: SAC stories cannot directly consume a flat table of numbers without semantic context. Two people looking at the same CSV file might disagree on what a column means; the model removes that ambiguity by embedding definitions, hierarchies, and calculation logic once, so every story built on that model behaves consistently. This is the same principle behind BW InfoProviders or BPC models in on-premise environments, but reimagined for a cloud-native, self-service analytics product.

SAC supports two primary model types. The first is the Account-based model, historically tied to planning use cases inherited from BPC. In an account model, all measures are represented as members of a single 'Account' dimension, and a special Account dimension type allows different accounts to have different behaviors (e.g., some are additive, some are non-additive like ratios). The second is the Measure-based model, which is more analytics-oriented: each numeric column becomes its own measure with its own aggregation type (sum, average, count, min, max). Measure-based models are generally preferred for pure reporting/BI use cases because they are simpler and align with how business users think about individual KPIs, while account-based models remain the standard for planning because they support versioning, categories, and currency conversion patterns needed for driver-based planning.

Every model, regardless of type, is built from dimensions and measures/accounts. Dimensions include generic dimensions (custom hierarchical attributes), the mandatory Date dimension (time), the Version dimension (for planning, distinguishing Actual vs Budget vs Forecast), and for account models, the Account dimension itself. Measures can be simple stored measures, calculated measures (formulas referencing other measures), or restricted measures (a measure filtered by a specific dimension value, such as 'Revenue for Region = EMEA').

Models can be created from a data import (uploading a flat file or connecting to a live source and letting SAC infer structure), or built manually from scratch by explicitly defining each dimension and measure. In modern SAC, models are also increasingly built on top of SAP Datasphere views, where Datasphere handles data integration, harmonization, and semantic modeling upstream, and SAC models consume that curated layer either live or via replication (import). Understanding this foundational structure is essential because every subsequent decision—performance tuning, security, planning enablement, or Datasphere integration—builds directly on how the model's dimensions and measures were initially defined.

A retail company onboarding SAC for the first time needs a sales reporting dashboard. The consultant is given a CSV export from the legacy reporting system containing columns: Date, Store, Product Category, Revenue, Units Sold. The consultant imports this file to create a measure-based model, mapping Store and Product Category as dimensions, Date as the time dimension, and Revenue/Units Sold as measures with SUM aggregation. Business stakeholders later ask for a 'Revenue per Unit' KPI, which the consultant adds as a calculated measure (Revenue / Units Sold) directly in the model so it is available consistently across every story built afterward.

• Treating every numeric column automatically as a measure without checking if it should actually be a calculated ratio (e.g., importing 'Average Discount %' as SUM-aggregated, producing meaningless totals.
• Choosing an account-based model for a pure reporting use case, adding unnecessary complexity when a measure-based model would suffice.
• Not planning dimension granularity upfront, leading to models that cannot support drill-down requirements discovered later.
• Ignoring the Version dimension's implications early on, then struggling to retrofit planning capability into a model not designed for it.
• Assuming model changes are free; altering dimension structure after stories are built can break existing bookmarks and calculated measures.

• Clarify with stakeholders early whether planning/what-if capability will ever be needed, since that determines account vs measure-based model choice.
• Keep dimension granularity as close to the source system's natural grain as possible to avoid costly rework.
• Use calculated measures for derived KPIs instead of pre-calculating them in the source data, so logic stays visible and maintainable in SAC.
• Document the meaning and aggregation logic of each measure/account at model creation time, since this becomes the single source of truth for all downstream stories.
• Prefer building on curated Datasphere views over raw file imports whenever the source data volume or complexity is significant.

Interviewers commonly ask candidates to explain the difference between account-based and measure-based models and to justify which they would choose for a given scenario (planning vs reporting). Be ready to explain aggregation types, the role of calculated vs restricted measures, and how the Version dimension is unique to account models. Demonstrating awareness that model type is a foundational, hard-to-reverse decision shows practical project experience rather than just textbook knowledge.