[Demo] Understand if a customer has promoted orders

[popcornylu]

In this PR, we want to understand if a customer has ever had an promotion order.

1. I add a is_promotion in the stg_payment model, it is true if the method is coupon
2. The customer model would check if there are any order with payment is_promotion = true

We can see the stg_payment is a non-breaking change, it would not affect the downstream models (e.g. orders)

[ijac13]

The where condition at customers.sql line 68 should be removed.

Reasons

1. Adding has_promoted_orders in customers model should not impact to row counts.
   

2. The impact is due to the where condition that restrict the customers.sql only have customers who has_promoted_orders = true
   

[recce-cloud]

Summary

PR #44 adds promotion order tracking to the Jaffle Shop data model by introducing a new is_promotion boolean column in stg_payments (TRUE for coupon payments) and a corresponding has_promoted_orders flag in the customers table. All Recce checks pass with zero row count changes and 100% value integrity on existing customer data, confirming this is a non-breaking, fully backward-compatible feature addition. The changes are awaiting peer review with Recce Cloud integration active for continuous dbt model validation.

---

Key Changes

• stg_payments model - New IS_PROMOTION column: row_count_diff confirms 330,273 payment records remain unchanged. Profile analysis shows 11.6% of payments (approximately 38,312 records) are promotion-based (coupon method), while 88.4% are non-promotional. This represents a selective, well-targeted promotion population.

• customers model - New HAS_PROMOTED_ORDERS column: row_count_diff shows 1,856 customer records with stable counts (base: 1,856 → current: 1,856, 0% change). Profile analysis reveals 96.3% of customers (approximately 1,788 customers) have at least one promoted order, while 3.7% (approximately 68 customers) have never used promotions. This indicates strong promotion penetration across the customer base.

• Zero data transformations: value_diff check confirms 100% match on existing customer_id and customer_lifetime_value across all 1,856 records, proving the changes are purely additive with no existing data modifications.

---

Impact Analysis

graph LR
    raw_payments["raw_payments<br/>(source)"]:::unchanged
    stg_payments["stg_payments<br/>(view)"]:::modified
    stg_orders["stg_orders<br/>(view)"]:::unchanged
    stg_customers["stg_customers<br/>(view)"]:::unchanged
    customers["customers<br/>(table)"]:::modified
    orders["orders<br/>(table)"]:::unchanged
    customer_order_pattern["customer_order_pattern<br/>(table)"]:::impacted
    customer_segments["customer_segments<br/>(table)"]:::impacted
    orders_daily_summary["orders_daily_summary<br/>(incremental)"]:::impacted

    raw_payments --> stg_payments
    stg_payments --> customers
    stg_customers --> customers
    stg_orders --> customers
    customers --> customer_order_pattern
    customers --> customer_segments
    stg_orders --> orders
    stg_payments --> orders
    orders --> orders_daily_summary

    classDef modified fill:#fff3cd,stroke:#ffc107,color:#000
    classDef impacted fill:#fff,stroke:#ffc107,color:#000
    classDef unchanged fill:#fff,stroke:#d3d3d3,color:#999

Loading

• 🟨 2 models modified: stg_payments and customers - both receiving new boolean columns for promotion tracking
• 🟨 3 downstream models impacted: customer_order_pattern, customer_segments, and orders_daily_summary will inherit the new promotion data through their dependencies on modified models
• ✅ Stable dimensions: orders table experiences zero changes (280,844 rows, base → current 0% change), and stg_orders view is unaffected, ensuring no impact on fact table logic
• ✅ orders_daily_summary stability: Although marked as impacted in lineage_diff, row count stability in orders (280,844 records) means this incremental model will receive consistent, unchanged upstream data

---

☑️ Checklist

Name	Run Status	Impact Analysis
Query Diff - Customer Lifetime Value by First Order Week	✅ PASSED	✅ 102 weeks of weekly CLV calculations match perfectly between base and current; new HAS_PROMOTED_ORDERS does not affect CLV logic
Row Count - customers, orders, and modified table models	✅ PASSED	✅ All row counts stable: customers (1,856), orders (280,844), zero additions/deletions in modified models
Model Schema - customers, orders, and modified nodes	✅ PASSED	✅ Schema evolution is clean: 2 new columns added (HAS_PROMOTED_ORDERS, IS_PROMOTION), 0 removed, 0 type changes
Value Diff - customer_id and customer_lifetime_value	✅ PASSED	✅ 100% match on all 1,856 customer records - no existing values modified; changes are purely additive

---

🔍 Suggested Actions

• Review SQL logic in stg_payments.is_promotion calculation: Verify that the coupon method detection logic correctly captures all promotional payment types across different Snowflake SQL variations (note: PR includes 2 commits fixing equality operators for Snowflake compatibility)

• Profile the HAS_PROMOTED_ORDERS distribution by customer cohort: Run profile_diff on customers.has_promoted_orders grouped by customer acquisition month to identify if certain cohorts have higher/lower promotion adoption rates

• Validate customer_order_pattern outputs: Execute query_diff on customer_order_pattern to confirm the impacted downstream model produces expected promotion-segmented customer order patterns without unexpected distribution shifts

• Monitor customer_segments dimension changes: Run row_count_diff on customer_segments after this PR merges to verify that new promotion-based segments are created as expected (if customer_segments uses HAS_PROMOTED_ORDERS for segmentation logic)

• Approve and merge PR: All Recce checks pass with zero data quality issues. Consider approving this non-breaking feature addition given the stable upstream inputs and backward compatibility confirmation
  Please use the link below to launch your Recce Cloud session.

Launch Recce Cloud Session

---

Was this summary helpful? 👍 👎