Home · Sep 10, 2026

Slowly Changing Dimensions for Ecommerce History

By iKawn Team / / 2 min read
Business team in a neutral office meeting with laptops and performance charts
iKawn viewBuilt for teams, not dashboards alone.
Updated

Quick answer

Slowly changing dimensions preserve selected historical ecommerce attributes so past orders can be analyzed using the classifications that applied at the time.

Share:

Definition

A slowly changing dimension strategy defines how an analytical system handles changes to descriptive attributes such as product category or account segment. A Type 2 approach adds a new versioned row instead of overwriting the previous value. Each version has its own surrogate key and effective period, allowing facts to retain the appropriate historical classification.

Why It Matters

  • Moving a product into a new category can otherwise silently rewrite the meaning of last quarter's category revenue.
  • Merchants may need both an as-sold view and a view using the current merchandising taxonomy.
  • A Commerce Intelligence OS benefits from explicit historical semantics when explaining changes across assortment and customer groups.

How It Works

  1. Identify which attributes need history and which are simple corrections. Document whether a report uses the historical or current classification.
  2. Create a version for a tracked change with an effective start, effective end, and stable business identity. Use nonoverlapping validity intervals and a distinct version key.
  3. Associate order facts with the version appropriate to their event time. Handle unknown records and late-arriving corrections through a documented reconciliation process.
  4. Test a product that changes category between two orders. Preserve separate reporting choices for historical classification and deliberate restatement under the current taxonomy.

Ecommerce Example

Context: Illustrative example: a bottle belongs to Travel until September 1, then moves to Outdoor. One order occurred in August and another in September.

Recommended move: An as-sold report assigns the August order to Travel and the September order to Outdoor. A current-taxonomy report can deliberately assign both to Outdoor.

Why it matters: Label the report clearly so the difference is understandable. This example describes a modeling choice, not a change to actual iKawn merchant data.

iKawn Framework

Describe

The iKawn ontology framework distinguishes stable entity identity from attribute versions.

Preserve

Retain selected historical classifications with validity periods.

Resolve

Attach facts to the intended version for each analysis.

Explain

Show whether an agent is discussing historical or current categories.

Concise Summary

History requires an explicit modeling choice. Version selected attributes and label historical versus current-taxonomy reporting so category changes do not become unexplained performance changes.

Related iKawn Pages

Frequently Asked Questions

No. Choose based on reporting needs; some corrections are intentionally overwritten.
No. Several version keys can represent the same stable product identity over time.
No. Historical model inputs may also require knowing when each fact became available to the system.
It gives the Commerce Intelligence OS framework a clear representation of changing commercial classifications.
Book a decision audit