Data Platform cho Retail: Inventory Optimization & Customer 360

Ngành bán lẻ tại Việt Nam đang trải qua cuộc cách mạng omnichannel. Khách hàng không còn mua sắm thuần online hay offline - họ research online, thử tại cửa hàng, mua trên app, và pick up tại cửa hàng gần nhất. Theo khảo sát của Carptech với 40+ chuỗi bán lẻ (F&B, thời trang, điện tử), 68% nhà bán lẻ đang "mù mờ" về customer journey xuyên suốt các kênh và 75% gặp vấn đề mất cân bằng tồn kho (cửa hàng này tồn thừa, cửa hàng kia hết hàng cùng SKU).

Bài viết này sẽ hướng dẫn chi tiết cách xây dựng Data Platform cho chuỗi bán lẻ, giải quyết 3 pain points lớn nhất: (1) Tối ưu tồn kho - giảm tồn thừa & hết hàng, (2) Customer 360 - góc nhìn thống nhất đa kênh, và (3) Hiệu suất cửa hàng - so sánh, benchmark, tối ưu từng cửa hàng. Kèm case study thực tế về chuỗi cafe 80 cửa hàng giảm tồn thừa từ 25% xuống 8%, tiết kiệm 800 triệu VNĐ/năm.

TL;DR - Tóm tắt nhanh

• Nguồn dữ liệu bán lẻ: POS (20-100+ cửa hàng), e-commerce, tồn kho, loyalty program, lượng khách vào cửa hàng
• Thách thức omnichannel: Thống nhất danh tính khách hàng giữa online/offline, theo dõi hành trình đa kênh
• Tối ưu tồn kho: Dự báo nhu cầu theo cửa hàng/SKU, mức tồn kho tối ưu, giảm 15-30% hao phí
• Customer 360: Phân khúc RFM, đề xuất hành động tiếp theo, khuyến mãi cá nhân hóa → tăng 20-35% tỷ lệ mua lại
• Kiến trúc: Mô hình hub-spoke (cửa hàng → kho trung tâm), đồng bộ tồn kho real-time
• ROI: Giảm 15-25% COGS, tăng 10-20% doanh thu, cải thiện 30-50% retention khách hàng

Data landscape bán lẻ: Thách thức đa cửa hàng & omnichannel

1. Point of Sale (POS) systems - Trái tim của bán lẻ

Mỗi cửa hàng có 1-5 POS terminals tạo dữ liệu real-time:

Transaction data:

{
  "transaction_id": "TXN-HN001-20250415-0123",
  "store_id": "HN001",
  "register_id": "REG-03",
  "timestamp": "2025-04-15T14:32:18+07:00",
  "cashier_id": "EMP-245",
  "line_items": [
    {
      "sku": "CF-LATTE-M",
      "product_name": "Latte Medium",
      "quantity": 2,
      "unit_price": 45000,
      "discount": 0,
      "subtotal": 90000
    },
    {
      "sku": "CAKE-TIRAMISU",
      "product_name": "Tiramisu Cake",
      "quantity": 1,
      "unit_price": 55000,
      "discount": 5500,  # 10% member discount
      "subtotal": 49500
    }
  ],
  "subtotal": 139500,
  "tax": 0,
  "total": 139500,
  "payment_method": "card",
  "loyalty_member_id": "MEMBER-8821",
  "loyalty_points_earned": 14
}

Challenges với multi-store POS:

• Inconsistent data: Different stores use different POS systems (older stores on legacy, new stores on modern cloud POS)
• Network issues: Store mất kết nối → Dữ liệu sync muộn (lag 1-24 hours)
• Data quality: Cashier errors (wrong SKU entry, manual discounts không có lý do)
• Scale: 50 stores × 1000 transactions/day × 365 days = 18M transactions/year

💡 Lưu ý: Khi lựa chọn POS system mới, ưu tiên các hệ thống cloud-based có API documentation rõ ràng (như KiotViet, Square) để dễ dàng tích hợp với Data Platform sau này. Legacy POS systems thường yêu cầu custom integration phức tạp hơn.

POS platforms phổ biến:

• International: Square, Lightspeed, Shopify POS
• Vietnam: MISA, VinaPOS, Fast POS, KiotViet

2. E-commerce platform - Online channel

Nếu retailer có online presence (website, app):

• Shopify, Magento, WooCommerce: E-commerce orders
• Mobile app: Native apps với in-app purchases
• Social commerce: Facebook Shop, TikTok Shop, Shopee/Lazada

Online data:

• Web analytics: Google Analytics (sessions, page views, bounce rate)
• Conversion funnel: Product views → Add to cart → Checkout → Purchase
• Customer accounts: Email, phone, address, order history

Omnichannel scenarios:

• Click-and-collect: Mua online, nhận tại store
• Reserve online, buy in-store: Check availability, reserve, pickup
• Return in-store: Mua online, trả hàng tại store

Challenge: Reconcile online vs offline data - Cùng customer nhưng different identifiers (email online, phone number tại store)

3. Inventory management - WMS & stock systems

Warehouse Management System (WMS):

• Central warehouse inventory: Incoming shipments, outgoing to stores
• SKU master data: Product catalog, attributes, costs

Store inventory:

• Real-time stock levels: Bao nhiêu units available tại mỗi store
• Stock transfers: Between stores hoặc từ warehouse
• Shrinkage: Theft, damage, expiry (đặc biệt quan trọng cho F&B)

Stock data structure:

CREATE TABLE inventory_snapshot (
  snapshot_date DATE,
  store_id VARCHAR(20),
  sku VARCHAR(50),
  quantity_on_hand INT,
  quantity_reserved INT,  # Ordered but not picked up yet
  quantity_available INT,  # on_hand - reserved
  cost_per_unit NUMERIC(10,2),
  retail_price NUMERIC(10,2),
  last_restock_date DATE,
  PRIMARY KEY (snapshot_date, store_id, sku)
);

Challenge: Inventory accuracy

• Physical count (định kỳ tháng 1 lần) thường khác với system count 5-15%
• Nguyên nhân: Theft, damage không được record, data entry errors

⚠️ Cảnh báo: Inventory accuracy dưới 90% sẽ làm hỏng mọi demand forecasting model. Trước khi triển khai Data Platform, bắt buộc phải thực hiện physical inventory audit và training nhân viên về data entry chuẩn.

4. Loyalty program & customer data

Loyalty systems:

• Points-based: Mua 100k → Earn 10 points
• Tier-based: Silver, Gold, Platinum dựa trên spend levels
• Benefits: Discounts, birthday vouchers, early access

Customer master data:

CREATE TABLE customers (
  customer_id UUID PRIMARY KEY,
  phone VARCHAR(15) UNIQUE,  # Primary identifier
  email VARCHAR(100),
  full_name VARCHAR(100),
  date_of_birth DATE,
  gender VARCHAR(10),
  registered_store_id VARCHAR(20),
  registration_date DATE,
  loyalty_tier VARCHAR(20),  # Silver, Gold, Platinum
  lifetime_points INT,
  current_points_balance INT,
  total_purchases NUMERIC(15,2),
  total_orders INT,
  first_purchase_date DATE,
  last_purchase_date DATE
);

Challenge: Customer deduplication

• Cùng customer, different phone numbers (personal + work)
• Name variations: "Nguyen Van A" vs "Nguyễn Văn A" vs "A Nguyen"
• Family members sharing phone number

💡 Mẹo: Phone number là identifier tốt nhất cho thị trường Việt Nam (96% penetration rate). Email thường không reliable vì nhiều người dùng email "rác" để nhận voucher. Bắt đầu matching bằng phone, sau đó dùng email và name+DOB làm secondary signals.

5. Additional data sources

Foot traffic counters:

• Cameras/sensors đếm số người vào store
• Dwell time: Trung bình khách ở trong store bao lâu
• Conversion rate: % visitors thực sự mua hàng

Weather data:

• Ảnh hưởng lớn đến retail: Coffee shops busy hơn khi lạnh, ice cream shops khi nóng
• APIs: OpenWeatherMap, Visual Crossing

Competitor data (nếu có):

• Pricing: Crawl competitor websites
• Promotions: Monitor campaigns

Social media:

• Reviews: Google, Facebook reviews
• Sentiment analysis: Positive/negative feedback

Architecture: Hub-spoke pattern cho multi-store

Overview diagram

Data replication strategy

Option 1: Batch replication (Most common)

• Frequency: Every 1-4 hours
• Method: Export from local POS DB → Upload to central via API/FTP
• Pros: Simple, works with legacy systems
• Cons: Lag (không real-time), potential data loss if connection fails

Option 2: Real-time CDC (Change Data Capture)

• Tool: Debezium
• Method: Monitor POS database transaction log → Stream changes to Kafka → Warehouse
• Pros: Real-time, reliable
• Cons: Requires modern POS system, more complex setup
• Tìm hiểu thêm: Real-time data pipeline với Kafka và CDC

Option 3: Hybrid

• Critical data (sales transactions): Real-time
• Reference data (product catalog): Batch (daily)

Real-time inventory sync

Challenge: Customer checks product availability online → Needs accurate stock levels across 80 stores

Solution:

Độ trễ: 1-5 giây (chấp nhận được cho hầu hết mô hình bán lẻ)

Ứng dụng thực tế #1: Tối ưu hóa tồn kho - Giảm overstock & stockout

Vấn đề: Mất cân bằng tồn kho

Tình huống điển hình:

• Cửa hàng A (khu trung tâm): Lượng khách cao, bán 20 ly Latte/ngày, nhưng chỉ còn 10 hộp sữa trong kho → Hết hàng lúc 3 giờ chiều
• Cửa hàng B (khu ngoại ô): Lượng khách thấp, bán 5 ly Latte/ngày, nhưng có 30 hộp sữa trong kho → Tồn kho thừa, hết hạn sau 3 ngày

Chi phí phát sinh:

• Hết hàng: Mất doanh thu (khách mua từ đối thủ), khách hàng không hài lòng
• Tồn kho thừa: Vốn bị ứ đọng, chi phí lưu trữ, hao hụt (hết hạn, hư hỏng)

Giải pháp: Dự báo nhu cầu theo cửa hàng × SKU

Dữ liệu đầu vào cho mô hình:

• Historical sales: Last 90 days, granular (store, SKU, day level)
• Seasonality:
  • Day of week: Weekends vs weekdays
  • Time of day: Morning rush, lunch, afternoon, evening
  • Month: Summer vs winter (seasonal products)
• Events: Holidays, promotions, store events
• Weather: Temperature, rain (coffee sales ↑ when cold/rainy)
• Store features: Location type (mall, street, office building), size, parking availability

Phương pháp dự báo:

Phương án 1: Trung bình động đơn giản (cơ sở)

# 7-day moving average
forecast_tomorrow = df.groupby(['store_id', 'sku'])['quantity_sold'] \
    .rolling(window=7).mean().shift(1)

Option 2: Prophet (handles seasonality well)

from prophet import Prophet
import pandas as pd

# Prepare data for a specific store × SKU
df_train = df[(df['store_id'] == 'HN001') & (df['sku'] == 'CF-LATTE-M')]
df_train = df_train[['date', 'quantity_sold']].rename(columns={'date': 'ds', 'quantity_sold': 'y'})

# Add regressors
df_train['is_weekend'] = (df_train['ds'].dt.dayofweek >= 5).astype(int)
df_train['is_promotion'] = df_train['ds'].isin(promotion_dates).astype(int)
df_train['avg_temperature'] = weather_df['temperature']

# Fit model
model = Prophet(
    yearly_seasonality=True,
    weekly_seasonality=True,
    daily_seasonality=False
)
model.add_regressor('is_weekend')
model.add_regressor('is_promotion')
model.add_regressor('avg_temperature')
model.fit(df_train)

# Forecast next 7 days
future = model.make_future_dataframe(periods=7)
future['is_weekend'] = (future['ds'].dt.dayofweek >= 5).astype(int)
future['is_promotion'] = future['ds'].isin(future_promotion_dates).astype(int)
future['avg_temperature'] = weather_forecast['temperature']

forecast = model.predict(future)
forecast[['ds', 'yhat', 'yhat_lower', 'yhat_upper']].tail(7)

Option 3: LightGBM (best for accuracy, handles interactions well)

import lightgbm as lgb

# Feature engineering
features = df.copy()
features['day_of_week'] = features['date'].dt.dayofweek
features['week_of_year'] = features['date'].dt.isocalendar().week
features['is_weekend'] = (features['day_of_week'] >= 5).astype(int)
features['is_holiday'] = features['date'].isin(holidays).astype(int)

# Lag features (past sales)
for lag in [1, 7, 14]:
    features[f'lag_{lag}'] = features.groupby(['store_id', 'sku'])['quantity_sold'].shift(lag)

# Rolling statistics
for window in [7, 14, 30]:
    features[f'rolling_mean_{window}'] = features.groupby(['store_id', 'sku'])['quantity_sold'] \
        .rolling(window=window).mean().reset_index(0, drop=True)

# Weather
features = features.merge(weather_df, on='date')

# Train/test split (temporal)
split_date = '2025-03-01'
X_train = features[features['date'] < split_date][feature_cols]
y_train = features[features['date'] < split_date]['quantity_sold']
X_test = features[features['date'] >= split_date][feature_cols]
y_test = features[features['date'] >= split_date]['quantity_sold']

# Train model
model = lgb.LGBMRegressor(
    n_estimators=500,
    max_depth=6,
    learning_rate=0.05,
    num_leaves=31
)
model.fit(X_train, y_train)

# Evaluate
from sklearn.metrics import mean_absolute_error, mean_squared_error
y_pred = model.predict(X_test)
mae = mean_absolute_error(y_test, y_pred)
rmse = mean_squared_error(y_test, y_pred, squared=False)

print(f"MAE: {mae:.2f} units")  # Target: <15% of mean demand
print(f"RMSE: {rmse:.2f} units")

Model performance benchmark:

• Baseline (7-day average): MAE ~30% of mean demand
• Prophet: MAE ~20-25%
• LightGBM: MAE ~15-20%

💡 Quick win: Bắt đầu với Prophet cho 80% SKUs (easy to deploy, good accuracy), chỉ dùng LightGBM cho top 20% SKUs (high revenue, worth the extra effort). ROI của forecasting accuracy tăng từ 20% lên 15% MAE thường không justify complexity increase cho long-tail products.

Demand forecasting workflow

Optimal stock levels: Safety stock calculation

Formula:

Optimal stock = Expected demand + Safety stock
Safety stock = Z-score × σ(demand) × √(lead_time)

Where:

• Expected demand: Model forecast
• Z-score: Desired service level (95% = 1.65, 99% = 2.33)
• σ(demand): Standard deviation of forecast errors
• Lead time: Days between ordering và receiving stock

Example:

• Store HN001, SKU CF-LATTE-M
• Expected demand: 20 units/day
• Forecast std error: 5 units
• Lead time: 2 days (order today, receive tomorrow)
• Service level: 95% (accept 5% stockout rate)

expected_demand_per_day = 20
forecast_std = 5
lead_time_days = 2
z_score_95 = 1.65

safety_stock = z_score_95 * forecast_std * math.sqrt(lead_time_days)
# = 1.65 × 5 × 1.41 ≈ 12 units

optimal_stock = (expected_demand_per_day * lead_time_days) + safety_stock
# = (20 × 2) + 12 = 52 units

# Reorder point
reorder_point = expected_demand_per_day * lead_time_days + safety_stock
# = 52 units (when stock drops to this level, place order)

Automated replenishment recommendations

Daily workflow (runs at 6 AM):

-- Identify SKUs needing restock per store
WITH current_inventory AS (
  SELECT store_id, sku, quantity_available
  FROM inventory_snapshot
  WHERE snapshot_date = CURRENT_DATE()
),

demand_forecast AS (
  SELECT store_id, sku, forecasted_demand_7d, reorder_point
  FROM metrics_inventory_forecast
  WHERE forecast_date = CURRENT_DATE()
),

replenishment_needs AS (
  SELECT
    i.store_id,
    i.sku,
    i.quantity_available as current_stock,
    f.forecasted_demand_7d,
    f.reorder_point,
    CASE
      WHEN i.quantity_available < f.reorder_point
        THEN f.reorder_point * 2 - i.quantity_available  # Restock to 2x reorder point
      ELSE 0
    END as qty_to_order
  FROM current_inventory i
  JOIN demand_forecast f USING (store_id, sku)
)

SELECT * FROM replenishment_needs
WHERE qty_to_order > 0
ORDER BY store_id, qty_to_order DESC;

Kết quả (gửi cho quản lý cửa hàng hàng ngày):

Store-to-store transfers

Tình huống: Cửa hàng A tồn kho thừa, cửa hàng B hết hàng cùng SKU → Chuyển hàng thay vì đặt thêm

Tối ưu hóa:

# Find transfer opportunities
overstock_stores = inventory[inventory['qty_available'] > inventory['reorder_point'] * 2]
stockout_stores = inventory[inventory['qty_available'] < inventory['reorder_point']]

# Match by SKU
for sku in stockout_stores['sku'].unique():
    stockout = stockout_stores[stockout_stores['sku'] == sku]
    overstock = overstock_stores[overstock_stores['sku'] == sku]

    if len(overstock) > 0:
        # Find closest overstock store to stockout store (minimize transfer cost)
        for _, need in stockout.iterrows():
            closest = overstock.iloc[(overstock['lat'] - need['lat'])**2 + (overstock['lon'] - need['lon'])**2).idxmin()]

            transfer_qty = min(need['qty_needed'], closest['excess_qty'])
            print(f"Transfer {transfer_qty} units of {sku} from {closest['store_id']} to {need['store_id']}")

ROI:

• Reduce shrinkage (waste) 10-20%
• Reduce stockouts 40-60%
• Improve capital efficiency 15-25%

Ứng dụng thực tế #2: Customer 360 - Góc nhìn thống nhất đa kênh

Thách thức: Nhiều danh tính khách hàng

Tình huống:

• Khách hàng Nguyễn Văn A:
  • Online: Tài khoản với email nguyenvana@gmail.com, user_id: WEB-12345
  • Cửa hàng HN001: Thành viên loyalty với số điện thoại 0912345678, member_id: MEM-8821
  • Cửa hàng HCM03: Giao dịch với số điện thoại 0987654321 (điện thoại công ty), không có member ID

Câu hỏi: Đây là 1 khách hàng hay 3 khách hàng khác nhau?

Giải pháp: Xác định danh tính khách hàng

Bước 1: Quy tắc khớp dữ liệu

-- Match by exact email
SELECT * FROM online_customers oc
JOIN offline_customers ofc ON oc.email = ofc.email;

-- Match by phone (normalized)
SELECT * FROM online_customers oc
JOIN offline_customers ofc
  ON REPLACE(REPLACE(oc.phone, ' ', ''), '-', '') = REPLACE(REPLACE(ofc.phone, ' ', ''), '-', '');

-- Match by name + DOB (fuzzy)
SELECT * FROM online_customers oc
JOIN offline_customers ofc
  ON SOUNDEX(oc.name) = SOUNDEX(ofc.name)  -- Phonetic matching
  AND oc.date_of_birth = ofc.date_of_birth;

Bước 2: Tạo bảng khách hàng thống nhất

CREATE TABLE core_customers_unified AS
WITH customer_matches AS (
  -- All potential matches from different sources
  SELECT DISTINCT
    COALESCE(oc.customer_id, ofc.customer_id, lm.member_id) as source_id,
    'email' as match_type,
    oc.email as match_value
  FROM online_customers oc
  JOIN offline_customers ofc ON oc.email = ofc.email
  -- ... similar for phone, name+DOB
),

identity_clusters AS (
  -- Group matched IDs into clusters (graph algorithm)
  SELECT
    source_id,
    MIN(source_id) OVER (PARTITION BY match_value) as unified_customer_id
  FROM customer_matches
)

SELECT
  unified_customer_id,
  MAX(email) as email,  -- Take non-null value
  MAX(phone) as phone,
  MAX(full_name) as full_name,
  MAX(date_of_birth) as date_of_birth,
  MIN(first_seen_date) as first_seen_date,
  ARRAY_AGG(DISTINCT source_id) as linked_identities
FROM identity_clusters
GROUP BY unified_customer_id;

Kết quả: 1 unified_customer_id đại diện cho cùng một người xuyên suốt các kênh

Cross-channel journey tracking

Ví dụ về hành trình khách hàng:

Day 1: Browse products online (web session)
  ↓
Day 2: Visit store, ask staff (foot traffic, no purchase)
  ↓
Day 5: Receive email with promo code
  ↓
Day 7: Purchase online with promo code
  ↓
Day 8: Pick up at store (click-and-collect)

Data model:

CREATE TABLE customer_journey (
  journey_id UUID PRIMARY KEY,
  unified_customer_id UUID,
  touchpoint_timestamp TIMESTAMPTZ,
  channel VARCHAR(50),  -- web, mobile_app, store, email, social
  touchpoint_type VARCHAR(50),  -- browse, add_to_cart, purchase, visit, email_open
  store_id VARCHAR(20),  -- if applicable
  transaction_id VARCHAR(100),  -- if purchase
  attributed_revenue NUMERIC(15,2)
);

Visualize journey:

import matplotlib.pyplot as plt
from matplotlib.patches import FancyBboxPatch

# Fetch journey for a customer
journey = fetch_customer_journey(customer_id='CUST-123')

fig, ax = plt.subplots(figsize=(14, 4))

for i, step in enumerate(journey):
    color = {'web': 'lightblue', 'store': 'lightgreen', 'email': 'lightyellow'}[step['channel']]
    box = FancyBboxPatch((i*2, 0), 1.8, 0.8, boxstyle="round,pad=0.1", facecolor=color)
    ax.add_patch(box)
    ax.text(i*2 + 0.9, 0.4, f"{step['touchpoint_type']}\n{step['channel']}", ha='center', va='center')

    if i < len(journey) - 1:
        ax.arrow(i*2 + 1.8, 0.4, 0.15, 0, head_width=0.1, head_length=0.05, fc='gray')

plt.xlim(-0.5, len(journey)*2)
plt.ylim(-0.2, 1)
plt.axis('off')
plt.title(f"Customer Journey: {customer_id}")
plt.show()

RFM segmentation for personalization

RFM Model Flow:

RFM scoring (same as e-commerce, but across channels):

WITH rfm_scores AS (
  SELECT
    unified_customer_id,
    DATE_DIFF(CURRENT_DATE(), MAX(purchase_date), DAY) as recency,
    COUNT(DISTINCT transaction_id) as frequency,
    SUM(total_amount) as monetary,
    NTILE(5) OVER (ORDER BY DATE_DIFF(CURRENT_DATE(), MAX(purchase_date), DAY) DESC) as r_score,
    NTILE(5) OVER (ORDER BY COUNT(DISTINCT transaction_id)) as f_score,
    NTILE(5) OVER (ORDER BY SUM(total_amount)) as m_score
  FROM (
    -- Combine online + offline transactions
    SELECT unified_customer_id, transaction_id, purchase_date, total_amount FROM online_orders
    UNION ALL
    SELECT unified_customer_id, transaction_id, purchase_date, total_amount FROM pos_transactions
  )
  GROUP BY unified_customer_id
)

SELECT
  unified_customer_id,
  CASE
    WHEN r_score >= 4 AND f_score >= 4 AND m_score >= 4 THEN 'Champions'
    WHEN r_score >= 3 AND f_score >= 3 THEN 'Loyal'
    WHEN r_score <= 2 AND f_score >= 3 THEN 'At risk'
    WHEN r_score = 3 AND f_score <= 2 THEN 'Need attention'
    WHEN r_score >= 4 AND f_score = 1 THEN 'New'
    ELSE 'Churned'
  END as segment
FROM rfm_scores;

Personalized actions by segment:

ROI:

• Open rate targeted emails: 25-35% (vs 10-15% mass emails)
• Conversion rate: 8-12% (vs 2-4%)
• Repeat purchase rate increase: 20-35%

Ứng dụng thực tế #3: Đánh giá hiệu suất cửa hàng

Các chỉ số quan trọng theo cửa hàng

Bảng điều khiển hàng ngày cho từng cửa hàng:

Sales metrics:

• Total revenue: Today, WoW, MoM
• Transaction count: Number of bills
• Average basket size: Revenue per transaction
• Units per transaction: Items per bill
• Conversion rate: Transactions / Foot traffic

Product mix:

• Top 10 SKUs: By revenue, by units
• Category breakdown: Coffee 60%, Food 30%, Merchandise 10%
• New product penetration: % customers buying new items

Operational:

• Shrinkage rate: (Expected stock - Actual stock) / Expected stock
• Staff productivity: Revenue per employee per hour
• Peak hours: Busiest times (for staffing optimization)

Comparative analysis

Same-store sales growth:

SELECT
  store_id,
  SUM(CASE WHEN purchase_date >= '2025-04-01' THEN total_amount ELSE 0 END) as current_month_sales,
  SUM(CASE WHEN purchase_date >= '2024-04-01' AND purchase_date < '2024-05-01' THEN total_amount ELSE 0 END) as same_month_last_year,
  (current_month_sales - same_month_last_year) / NULLIF(same_month_last_year, 0) * 100 as yoy_growth_pct
FROM transactions
GROUP BY store_id
ORDER BY yoy_growth_pct DESC;

Sales per square meter (retail efficiency):

SELECT
  s.store_id,
  s.store_size_sqm,
  SUM(t.total_amount) as monthly_revenue,
  SUM(t.total_amount) / s.store_size_sqm as revenue_per_sqm
FROM stores s
JOIN transactions t USING (store_id)
WHERE t.purchase_date >= '2025-04-01'
GROUP BY s.store_id, s.store_size_sqm
ORDER BY revenue_per_sqm DESC;

Benchmark tiers:

Root cause analysis: Why store X underperforms?

Hypothesis testing:

Hypothesis 1: Location issue (low foot traffic)

• Metric: Foot traffic count
• Compare: Similar-sized stores in different locations
• If confirmed: Marketing campaigns (local ads, promotions), or consider relocation

Hypothesis 2: Poor product mix (wrong inventory for local demographics)

• Metric: Sales by category vs other stores
• Example: Store in university area should have more budget items, less premium
• If confirmed: Adjust inventory allocation

Hypothesis 3: Operational issues (slow service, poor CX)

• Metrics: Average transaction time, customer satisfaction scores, staff turnover
• Compare: Against top performers
• If confirmed: Staff training, process improvements

Hypothesis 4: Pricing (too high vs competitors)

• Metric: Price index vs nearby competitors
• Data: Competitor pricing (manual survey or web scraping)
• If confirmed: Local pricing adjustments (if allowed by HQ)

Cohort analysis: Store opening performance

Track new stores:

import pandas as pd
import matplotlib.pyplot as plt

# Stores opened in 2024
new_stores_2024 = stores[stores['opening_date'].dt.year == 2024]

# Monthly sales for each store (normalized to months since opening)
cohorts = []
for store_id in new_stores_2024['store_id']:
    store_sales = transactions[transactions['store_id'] == store_id]
    opening_date = stores[stores['store_id'] == store_id]['opening_date'].iloc[0]

    for month in range(12):
        month_start = opening_date + pd.DateOffset(months=month)
        month_end = month_start + pd.DateOffset(months=1)
        monthly_revenue = store_sales[(store_sales['purchase_date'] >= month_start) &
                                       (store_sales['purchase_date'] < month_end)]['total_amount'].sum()
        cohorts.append({
            'store_id': store_id,
            'months_since_opening': month,
            'revenue': monthly_revenue
        })

df_cohorts = pd.DataFrame(cohorts)

# Plot cohort curves
for store_id in new_stores_2024['store_id']:
    store_cohort = df_cohorts[df_cohorts['store_id'] == store_id]
    plt.plot(store_cohort['months_since_opening'], store_cohort['revenue'], label=store_id)

plt.xlabel('Months since opening')
plt.ylabel('Monthly revenue (VND)')
plt.title('New Store Ramp-up Curves (2024 cohort)')
plt.legend()
plt.show()

Thông tin rút ra:

• Quá trình phát triển điển hình: Đạt 70% doanh thu cửa hàng trưởng thành vào tháng thứ 6
• Xác định cửa hàng phát triển nhanh (đạt 80% vào tháng 3) so với chậm (<50% vào tháng 6)
• Bài học: Cửa hàng phát triển nhanh làm tốt điều gì? (vị trí? marketing? nhân sự?)

Case study: Coffee chain 80 stores - Giảm overstock 70%, tiết kiệm 800M VND/năm

Bối cảnh:

• Doanh nghiệp: Chuỗi cafe cao cấp, 80 cửa hàng tại Hà Nội & HCM
• Doanh thu: ~300 triệu VNĐ/tháng mỗi cửa hàng, 24 tỷ VNĐ/năm
• Sản phẩm: Cà phê, trà, bánh ngọt, món ăn nhẹ - 150 SKU

Các vấn đề:

1. Inventory imbalance:
   • 25% overstock rate (inventory sitting >7 days)
   • 15% stockout rate (can't fulfill customer orders)
   • Shrinkage 8% (waste due to expiry, especially perishables)
2. Manual ordering: Store managers order based on "gut feeling"
3. Siloed data: POS data stays at store level, HQ has no visibility

Giải pháp: Data Platform + Dự báo nhu cầu (16 tuần)

Phase 1: Data integration (Weeks 1-6)

POS integration:

• 80 stores sử dụng KiotViet POS (cloud-based, có API)
• Airbyte connector KiotViet → BigQuery
• Frequency: Every 2 hours (near real-time)

Inventory integration:

• Daily inventory snapshots: Each store exports CSV at closing time (9 PM)
• Auto-upload to GCS (Google Cloud Storage) → BigQuery

Other data:

• Product master from HQ (Google Sheets → BigQuery)
• Weather API (OpenWeatherMap) for Hà Nội & HCM
• Store metadata (location, size, opening date)

Data warehouse schema (theo kiến trúc data modeling best practices):

-- Staging
staging_pos_transactions: Raw transactions from all stores (10M rows, 18 months)
staging_inventory_snapshot: Daily inventory (80 stores × 150 SKUs × 540 days = 6.5M rows)

-- Core
core_transactions: Cleaned transactions với product info
core_inventory: Daily inventory với stockout/overstock flags

-- Metrics
metrics_daily_sales: By store, SKU, day
metrics_demand_forecast: 7-day rolling forecast per store × SKU

Phase 2: Demand forecasting model (Weeks 7-12)

Modeling approach: LightGBM regression (separate model per SKU category)

Features (45 features total):

• Time: Day of week, week of year, is_weekend, is_holiday
• Lags: Sales 1 day ago, 7 days ago, 14 days ago
• Rolling stats: 7-day average, 14-day average, 30-day average
• Store: Store ID (categorical), store size, location type
• Weather: Temperature, rainfall (coffee sales ↑ when cold/rainy)
• Promotions: Binary flags for active campaigns

Training data: 12 months historical sales

Model performance (tested on last 2 months):

• MAE: 18% of mean demand (acceptable, given variability)
• Top-selling SKUs (Latte, Cappuccino): MAE 12-15% (better accuracy)
• Low-volume SKUs (seasonal cakes): MAE 25-35% (higher variance)

Business rule overlay:

• Model forecast × 1.2 for weekend days (conservative, avoid stockouts)
• Model forecast × 0.8 if promotion ends (prevent over-ordering)

Phase 3: Automated replenishment system (Weeks 13-16)

Daily workflow (automated via Airflow):

5 AM:

• Update inventory snapshot (yesterday's closing stock)
• Update sales data (yesterday's transactions)

6 AM:

• Run forecasting models for all stores × SKUs
• Calculate optimal stock levels (forecast + safety stock)
• Generate replenishment recommendations

7 AM:

• Send reports to store managers (email + mobile app notification)
  • Restock list: SKUs to order, quantities
  • Overstock alert: SKUs with excess inventory
  • Transfer opportunities: Inter-store transfers

Store managers:

• Review recommendations
• Adjust if needed (local knowledge, upcoming events)
• Submit orders to central warehouse (1-click approval)

Central warehouse:

• Consolidate orders from 80 stores
• Prepare shipments
• Deliver next day

Results after 6 months

Financial impact (annual):

Cost savings:

• Reduced waste (shrinkage 8% → 4%): 24B revenue × 40% COGS × 4% = 384M VND saved
• Freed capital (inventory 45M → 30M per store): 80 stores × 15M = 1.2B VND freed up
  • Opportunity cost saved (10% interest): 120M VND/year

Revenue increase:

• Reduced stockouts (15% → 5%): Captured 10% more demand
• Estimated lost sales before: 24B × 15% × 20% (customer leaves if stockout) = 720M VND
• After: 24B × 5% × 20% = 240M VND
• Recovered revenue: 480M VND/year

Total impact: ~1B VND/year (4% of revenue)

Additional benefits:

• Store managers freed up from manual ordering → Focus on customer service
• Better customer experience → Increased repeat rate 12% → 15%
• Reduced emergency orders (costly same-day delivery) → 200M VND saved

Lessons learned

What worked well:

• Start with top SKUs (80/20 rule): 20% SKUs = 80% revenue. Perfect forecasting for these first.
• Empower store managers: Give recommendations, not mandates. Local knowledge matters.
• Quick wins: Overstock alerts had immediate impact (first month), built trust in system

💡 Key Insight: Biggest mistake là cố forecasting tất cả 150 SKUs từ đầu. Top 30 SKUs chiếm 75% revenue - nên focus 100% effort vào nhóm này trước. Long-tail SKUs có thể dùng simple rules (e.g., maintain 7 days stock) mà không cần ML.

Challenges:

• Data quality: Some stores had incorrect inventory counts initially → Required physical audits
• Model drift: Accuracy degraded after 3 months → Implemented monthly retraining
• Change management: Older store managers hesitant to trust "algorithm" → Training, gradual rollout

⚠️ Cảnh báo Change Management: 30% thành công của Data Platform phụ thuộc vào technology, 70% phụ thuộc vào people adoption. Đầu tư thời gian training store managers, explain logic behind recommendations, và thu thập feedback để improve system.

Future enhancements (roadmap):

• Real-time inventory (currently daily) → Prevent intraday stockouts
• Dynamic pricing (reduce price when overstock approaching expiry)
• Customer-level recommendations (upsell/cross-sell at POS)

Kết quả nhanh: 5 phân tích nên triển khai đầu tiên

Nếu bạn mới bắt đầu với Data Platform cho bán lẻ, hãy ưu tiên các ứng dụng sau (ROI cao, công sức thấp):

1. Bảng điều khiển hiệu suất sản phẩm (1 tuần)

Các chỉ số:

• Top 10 sản phẩm theo doanh thu (tháng này so với tháng trước)
• Top 10 theo số lượng bán
• Bottom 10 (cân nhắc ngừng kinh doanh)
• Xu hướng bán hàng theo danh mục

Tác động: Xác định sản phẩm bán chạy/ế ẩm, tối ưu danh mục Công sức: Thấp (nếu có dữ liệu POS)

2. Phân khúc khách hàng (RFM) (2 tuần)

Các phân khúc: Champions, Loyal, At risk, New, Churned Hành động: Khuyến mãi nhắm mục tiêu theo từng phân khúc Tác động: Tăng 20-30% hiệu quả chiến dịch marketing Công sức: Trung bình (cần bảng khách hàng thống nhất)

3. Cảnh báo hết hàng (1 tuần)

Logic: Nếu tồn kho < dự báo 7 ngày, gửi cảnh báo Cách thức: Email hàng ngày cho quản lý cửa hàng Tác động: Giảm 30-50% tình trạng hết hàng Công sức: Thấp (SQL đơn giản + email)

4. Tăng trưởng doanh thu cùng kỳ (1 tuần)

Chỉ số: Doanh thu tháng này so với cùng kỳ năm trước (theo từng cửa hàng) Trực quan hóa: Biểu đồ cột xếp hạng tất cả cửa hàng Tác động: Xác định cửa hàng yếu kém, điều tra nguyên nhân Công sức: Thấp

5. Hiệu quả chương trình khuyến mãi (2 tuần)

Phân tích: Doanh thu trong thời gian khuyến mãi so với nền Chỉ số: Doanh thu gia tăng, ROI của khuyến mãi Quyết định: Khuyến mãi nào nên lặp lại, khuyến mãi nào nên dừng Tác động: Cải thiện 15-25% ROI khuyến mãi Công sức: Trung bình (cần tính toán nền)

Implementation checklist

Data infrastructure:

• Choose Data Warehouse (BigQuery recommended for startups, Snowflake for enterprises)
• Setup POS integration (Airbyte connectors for KiotViet, MISA, etc.)
• Setup e-commerce integration (Shopify, Magento)
• Loyalty program integration
• Inventory snapshot automation (daily exports)

Data modeling:

• Customer identity resolution (unify online/offline)
• Transaction fact table (all sales, all channels)
• Inventory snapshot table (daily stock levels)
• Product master table (catalog, attributes)
• Store master table (location, size, metadata)

Core metrics:

• Daily sales by store, by product
• Customer RFM segments (updated weekly)
• Inventory turnover by SKU
• Stockout & overstock rates
• Store performance metrics (revenue/sqm, basket size, conversion)

Advanced analytics:

• Demand forecasting model (start with top 20% SKUs)
• Automated replenishment recommendations
• Customer lifetime value calculation
• Store performance benchmarking

Dashboards & reporting:

• Executive dashboard (company-level KPIs)
• Store manager dashboard (store-level metrics, real-time)
• Inventory planner dashboard (restock recommendations)
• Marketing dashboard (campaign performance, customer segments)

Automation:

• Daily data pipelines (scheduled)
• Automated alerts (stockouts, anomalies)
• Weekly email reports (to HQ, store managers)

Kết luận: Data platform = Lợi thế cạnh tranh đa cửa hàng

Chuỗi bán lẻ với 10+ cửa hàng không thể quản lý hiệu quả bằng bảng tính và cảm tính. Data Platform mang lại tầm nhìn rõ ràng, tính nhất quán, và tối ưu hóa xuyên suốt các cửa hàng - biến vận hành bán lẻ từ "nghệ thuật" thành "khoa học".

Lợi ích chính:

• Tối ưu tồn kho: Giảm 15-30% COGS, giảm 40-60% tình trạng hết hàng
• Customer 360: Tăng 20-35% retention, hiệu quả chiến dịch tăng 2-3 lần
• Hiệu suất vận hành: Giải phóng thời gian quản lý cửa hàng, quyết định nhanh hơn, thực thi tốt hơn
• Khả năng mở rộng: Thêm cửa hàng mới mà không tăng chi phí quản lý theo tỷ lệ

ROI điển hình:

• Đầu tư: 200-500 triệu VNĐ (triển khai ban đầu + vận hành năm đầu)
• Hoàn vốn: 6-12 tháng cho chuỗi quy mô trung bình (20-50 cửa hàng)
• Giá trị lâu dài: Cải thiện 10-20% lợi nhuận

Các bước tiếp theo:

• Đánh giá mức độ trưởng thành dữ liệu hiện tại (bạn đã có tích hợp POS? Database khách hàng?) - Tham khảo 5 dấu hiệu doanh nghiệp cần Data Warehouse
• Xác định pain point lớn nhất (tồn kho? giữ chân khách hàng? hiệu suất cửa hàng?)
• Bắt đầu với 1-2 kết quả nhanh (xem phía trên)
• Xem thêm về Modern Data Stack 2025 để chọn công nghệ phù hợp
• Đặt lịch tư vấn miễn phí với Carptech để được tư vấn kiến trúc Data Platform phù hợp với chuỗi bán lẻ của bạn

Tài liệu tham khảo:

• Airbyte POS Connectors
• BigQuery for Retail
• Prophet Forecasting Documentation
• RFM Analysis Guide

Bài viết này là phần của series "Data Platform theo ngành". Đọc thêm về E-commerce, Fintech, và Sản xuất.

Carptech - Giải pháp Data Platform cho doanh nghiệp Việt Nam. Liên hệ tư vấn miễn phí.