Customer 360 Engine

The problem

Customer data lived in three places — the POS system, the e-commerce platform, and the loyalty program — with no shared key. The same person appeared as three customers; campaign audiences double-counted; lifetime value was unanswerable. And every seasonal analysis had a uniquely Saudi complication: commercial life runs on the Hijri calendar (Ramadan, the Eids) while finance reports Gregorian.

The architecture

• Identity resolution — deterministic matching first (phone, email, loyalty ID), then conservative fuzzy matching with human-reviewable confidence tiers, producing a persistent customer_key across all three systems. 2.7M raw records resolved into a clean identity graph.
• Dual-calendar dimension — one conformed date dimension carrying both calendars as first-class columns: every date knows its Hijri day, month, and whether it falls in Ramadan or Eid trading windows. Seasonal comparisons (“this Ramadan vs. last Ramadan”) became one-line filters instead of analyst spreadsheet projects.
• Serving — a customer_360 mart in ClickHouse exposing identity, transactions, channels, and RFM segmentation to Power BI and to campaign tooling.

What it changed

Marketing addresses one customer instead of three fragments; retention numbers survived their first audit; and Ramadan planning starts from data instead of memory. The dual-calendar model has since become the pattern other retail data teams in the region ask about — it’s also the subject of one of my talks.