Building interpretable campaign analytics, starting with a trustworthy analytical boundary.
Team lead · Data loaders & features · 6 people
Graduation project · In development
Python / PostgreSQL / FastAPI / Next.js
A change is a starting point for a question.
Prepared example · no live analysisSawakli AI aims to explain campaign performance through interpretable metrics, anomaly detection, forecasts, and recommendations. Before those modules can be useful, their inputs need consistent meaning and explicit organization scope.
This is a six-member graduation project, in development. Analytical modules and application infrastructure exist, while complete orchestration, persistence, and dashboard integration remain unfinished.
I lead the team and coordinate the AI track. My strongest implemented contribution is the organization-scoped PostgreSQL/CSV loading and feature pipeline:
Original anomaly detection and other analytical implementations are team work. They are not presented as my sole implementation.
In the inspected revision, analytical frontend services still return mock data, the Worker executor is simulated, and the AI orchestration entry point is empty. Implemented modules should not be mistaken for a complete end-to-end product.
Loaders require explicit organization boundaries. Analytical data for one business must not leak into another business’s features or reference context. Cross-organization validation makes that boundary testable.
Zero denominators, incomplete windows, and date gaps need explicit handling. An unavailable rate should remain unavailable rather than silently becoming evidence of good or bad performance.
CSV and database inputs share a typed contract. Equivalence validation checks that choosing a source does not change the analytical meaning of the same records.
The team’s anomaly ensemble combines robust Z-score, IQR, and Isolation Forest. Forecasting uses Random Forest, linear regression, and moving-average fallbacks, with rolling-origin backtests. Recommendation rules connect explanations to evidence.
The 360-record validation describes my feature-pipeline work. It is separate from the team’s synthetic anomaly benchmark and is not a production dataset or proof of business impact.
The saved team benchmark uses 60 campaigns across three organizations over 90 days: 5,400 observations per seed. At critical-alert threshold 0.80, the reserved-seed report records 144/152 anomalous days detected and 59/5,248 clean days flagged.
Those are controlled synthetic results. Retrospective forest fitting and the synthetic distribution limit their interpretation. They are not prospectively validated production accuracy, and the threshold is not a calibrated probability.
Status verified against the inspected October 2026 source snapshot. No model training, database mutation, original project tests, or full application execution was performed for this portfolio.
Select a synthetic observation. Inspect the numerator, denominator, prepared reference, and explanation—including a day where the rates cannot be calculated.
Prepared synthetic campaign observations, scoped to one fictional organization. No model ensemble runs here. Select an observation to inspect the values and their interpretation.
CTR is 2.00%; CPC is 0.50. This is one synthetic observation, not a complete rolling reference window.
| Observation | Impressions | Clicks | Spend |
|---|---|---|---|
| Day 01 | 10,000 | 200 | 100 |
| Day 02 | 10,000 | 190 | 100 |
| Day 03 | 10,000 | 70 | 100 |
| Day 04 | 0 | 0 | 0 |
Questions about the work, an engineering opportunity, or an idea to explore? I’d like to hear it.
Get in touch