STAR Summary
- Situation
- Leaders needed one reliable way to compare security incidents, theft hotspots, and sales signals without stitching together separate reports.
- Task
- Led the analysis: SQL modeling/ETL, anomaly detection, and reporting.
- Action
-
- Modeled incident, sales, and HR data in SQL so stores, regions, time periods, and risk measures use consistent definitions.
- Built Python reporting views that separate frequency, severity, and sales context for faster investigation planning.
- Used anomaly detection to flag outlier stores, regions, and associate patterns for review.
- Result
-
- Supported analytics-driven investigations that reduced inventory loss by 24%.
- Improved theft reporting by 57.6% through clearer dashboards and workflow redesign.
- Narrowed broad incident data into a short, explainable list of hotspots worth investigating.
- Stack
- SQL · Python · AWS
- Status
- Live interactive demo
Personal notes
- Why I built it
- I wanted to turn scattered incident and sales data into a short, explainable list of stores worth investigating.
- What surprised me
- Raw incident volume was misleading; sales context and normalization changed which stores looked genuinely unusual.
- What I’d try next
- I’d calibrate alert thresholds against reviewed cases and add drift monitoring so the ranking stays useful over time.
Demo
Compare store-level incident signals against sales metrics using tabs and filters.
- Pick a region to filter incidents and trends.
- Switch sales metrics (Total, Online, Drive-up) to change the sales view.
- Switch incident metrics (Count vs. Proven $) to change the incident view.
- Use “Reset view” to return to the default slice.
Links
Notes
Store, state, and employee identifiers are anonymized; risk rankings normalize incident signals with sales context so high-volume stores are not treated as high-risk by volume alone.
