Data analyst portfolio
Five data problems,
worked end to end.
I'm a data analyst who works across the full pipeline — raw files and SQL at one end, a dashboard someone actually opens at the other. SQL, PostgreSQL, Excel, Python, Databricks, Alteryx, Power BI and Tableau, applied to payment fraud controls, drug shortages, retail revenue, lending risk, and inventory data.
Noida, India · Open to relocation · Available to join immediately
Curious by nature. Analytical by training.
I graduated with a B.Tech in Computer Science in 2023 and I'm building my career in data analytics. I like connecting the technical work — cleaning data, writing queries, building models — to the actual business question it needs to answer.
I currently hold a contract role at Innodata evaluating AI-generated dashboards, charts and reports for accuracy — which has made me considerably more careful about the details in my own work.
I'm HackerRank certified in SQL (Advanced), Python (Basic) and R (Intermediate), with 5-star Gold badges in SQL and Python — verify on HackerRank.
I'm looking for a Data Analyst, BI Analyst, Tableau or Power BI Developer, or risk and data-assurance analytics role where I can contribute with SQL, Python, Excel, Tableau, Power BI and reporting that people actually use.
Explore my GitHub-
01
Start with the business question
Define what matters, who needs the answer, and which metrics will help.
-
02
Make the numbers trustworthy
Validate the data, document assumptions, and reconcile results across tools.
-
03
Make the insight usable
Build clear dashboards and explain the decisions the analysis can support.
What I work with
Pulled straight from the tools actually used across the five projects below — nothing listed here that isn't demonstrated in a repo.
Languages & querying
BI, visualization & tools
Data engineering
Applied methods
Risk & data assurance · Databricks, SQL, Alteryx, Python, Power BI
Payment Transaction Controls & Fraud Risk Analytics
Can this payment data be trusted, how well do simple rule-based controls catch fraud, and does a model add anything the rules miss? Using the public PaySim synthetic mobile-money dataset (6,362,620 transactions, 8,213 of them fraud), I built the full trail: a reconciled cloud pipeline, data-assurance checks, five tested controls, and a leakage-aware model comparison.
What this shows
- Built a Databricks Bronze → Silver → Gold pipeline, hashed account IDs with a salted SHA-256 in Silver, and reconciled row count, total amount and fraud count across every layer.
- Ran six data-assurance checks and logged exceptions instead of deleting rows. Two checks failed on 56.6% of transactions with almost no fraud (a simulator artifact), while receiver-balance mismatches carried a 1.57% fraud share — about 12× the baseline.
- Tested five rule-based controls for precision and recall: two caught about half of all fraud at 65–70% precision, while one caught 97.55% of fraud at only 0.67% precision. Rebuilt two controls in Alteryx and matched the SQL counts exactly.
- Trained logistic regression and a random forest on a time-based split and flagged the forest's perfect score as leakage from PaySim's balance logic. Re-testing the controls on the same test window changed the story: the two best rules reached 100% and 98.65% precision against 52.16% for logistic regression, but caught only about half the fraud the models did (97%+). The real trade-off is recall, not precision.
- Hand-reviewed a stratified sample of 25 flagged transactions in an Excel control-testing workpaper (7 were fraud, all from the two strongest rules), and back-tested an hourly fraud-count forecast: regression beat a seasonal baseline, MAE 4.38 vs 5.92.
- Wrote a one-page research memo on rules vs. machine learning, drawing on RBI's FAQ on the fraud risk management directions and its FREE-AI report (August 2025).
What I'd recommend: Keep the two strongest rules as primary controls, retire or redesign the rule that flagged 2.49M transactions for 45 frauds, and use logistic regression to prioritize alerts instead of the leaky random forest.
Healthcare data · PostgreSQL, Google Sheets, Excel, Python, local GenAI
FDA Drug Shortage Analysis
Which US drugs are in shortage, for how long, and can the data behind the answer be trusted? Using the FDA Drug Shortages list (1,605 records, public domain), I analysed it in Google Sheets, rebuilt it as a PostgreSQL database run like a small production system, tested how accurately a local AI model reads the list's free-text notes, and wrote an oncology brief that adds FDA's NDC Directory.
What this shows
- Cleaned the FDA list with formulas in a separate tab so the raw import was never edited, counted distinct drugs as well as product records, and logged every check. Counting records alone would have hidden that Pediatric medicines are the most widely affected area.
- Built a normalised PostgreSQL database: 6 tables with primary and foreign keys, CHECK rules and a natural-key UNIQUE constraint. PostgreSQL refused the raw file over blank lines and 4 unescaped inch marks that Google Sheets had accepted, so a script writes a corrected copy for loading.
- Ran 23 logged data-quality checks, set up a read-only analyst role limited to four reporting views, tested indexes with EXPLAIN ANALYZE, and verified a pg_dump backup by restoring it and comparing a checksum of every record.
- Applied a newer FDA download in one transaction with an audit trigger: 39 records updated, 2 deleted, and the database matched the new file exactly afterwards.
- Tested a local LLM (Qwen3 4B via Ollama) on 60 sampled notes: 57 of 60 recovery dates matched. A format check caught two broken dates, but only the comparison with a reference caught the date it missed.
- Ran Fisher's exact test at the drug level: pediatric drugs are not significantly more likely to have a fully unavailable product (p = 0.27).
- Built an oncology brief combining the shortage list with 216 marketed products from FDA's NDC Directory, in an Excel model with adjustable weights. Flurazepam, a sleep medicine tagged Oncology by FDA, was kept in the data but excluded from scoring.
What I'd recommend: Shortlist streptozocin and pentostatin, which have no generic supplier, for a feasibility study; in crowded markets such as carboplatin, compete on reliable supply rather than entry; and re-run the screen monthly as the list changes.
Retail analytics · Python, Snowflake, Tableau (LOD, data blending, Cloud), local GenAI
Customer Revenue & Retention Analytics
Using the public UCI Online Retail II dataset from a UK-based online retailer, I asked which customers actually drive revenue, how much cancellations cost, and whether first-time buyers come back. The project analyzes 1,033,036 cleaned transactions from December 2009 through December 2011 to answer it.
What this shows
- Built a 3-layer Snowflake warehouse — RAW, STAGING, ANALYTICS — and reconciled row counts and revenue totals across every layer before building a single dashboard.
- Combined two overlapping source files (1,067,371 rows), removed 34,335 duplicates, and flagged a suspected £38,970 entry error instead of deleting it.
- Ran RFM segmentation on 5,852 identified customers; the "Champions" segment is 24.74% of them but generates 74.04% of identified-customer net revenue.
- Added a segment dashboard using all three LOD types: FIXED for revenue share and a country benchmark, INCLUDE for revenue per country, and EXCLUDE for UK share. High-Value Active is the only segment that earns most of its revenue outside the UK (54.30%).
- Blended the Python RFM table with the Snowflake segment mart in Tableau to reconcile revenue shares; every segment matched within 0.05 percentage points, the rounding in the export.
- Published the workbook to a Tableau Cloud developer site with Analyst and Viewer groups and locked project permissions, denied data downloads for viewers, and tested it by signing in as the viewer.
- Built monthly cohort retention curves — retention drops sharply after month 1, then stabilizes near 20–23% through month 12.
- Classified 4,725 products into 12 categories using a locally-hosted LLM (Qwen3:4B via Ollama), so no transaction data left the machine and no paid API was needed.
- Summarised the findings and recommendations in a 7-slide PowerPoint deck with native charts and speaker notes.
What I'd recommend: Weight retention effort toward Champions, test a follow-up within 30 days of the first order, and start capturing cancellation reason codes.
Credit risk analytics · Power BI, Power Query, DAX, row-level security
Loan Default Risk Analysis
A single blended default rate hides where the risk is. Using a public Kaggle loan-default dataset (via a Udemy course, with an added loan-date column), this dashboard asks which borrower segments carry the most risk and how much loan value that risk represents, breaking down 255,347 loans by credit score, income, employment, interest rate, and dependent status.
What this shows
- Modeled a star schema (date and loan-purpose dimensions), a centralized measures table, and time-intelligence DAX (YTD, YoY) rather than relying on flat aggregates.
- Added static and dynamic row-level security (USERPRINCIPALNAME with a security table) and tested both roles in Power BI Desktop with View as. The report is not published to the Power BI Service, which needs a work account.
- Compared loan purposes with ALLSELECTED, REMOVEFILTERS and RANKX measures, plus a measure that writes the page's takeaway sentence, so it stays correct when slicers or security change what a user sees.
- Built a field-parameter so one visual pivots between co-signer, mortgage, and dependent status without duplicating pages.
- Used a decomposition tree so a viewer can investigate defaulted exposure by any borrower characteristic themselves.
- Separated default rate (by loan count) from defaulted amount share (by loan value): 11.61% vs 13.15%, so counting loans alone understates the value at risk.
- Caught a wrong denominator in my own first version (each group's defaults divided by all loans), rebuilt it as one reusable default-rate measure, and checked every KPI against the source data.
What I'd recommend: Size exposure by loan value, not only by count, and test tighter approval criteria or risk-based pricing for the highest-risk segments.
Inventory analytics · SQL Server, MySQL, Power BI
Inventory Demand & Supply Analysis
Before this could be a Power BI story, it was a data-trust problem: could the inventory data even be relied on? The project validates the data first, simulates a reporting migration from SQL Server to MySQL, then quantifies exactly where shortages are costing revenue.
What this shows
- In a simulated production environment, caught a referential data-quality issue — two product IDs that didn't exist in the product master — and followed a documented detect → investigate → escalate → confirm → correct → validate workflow before touching the report.
- Simulated a migration of the reporting pipeline from SQL Server to MySQL, reapplied every data-quality correction, and re-validated that the numbers still matched.
- Modeled fulfillment rate, revenue at risk, and value fulfillment rate as DAX measures, not simple row counts.
- Showed that the products with the highest unfulfilled demand aren't always the ones with the highest revenue at risk — shortage quantity and financial exposure need to be prioritized separately.
What I'd recommend: Set reorder points for the top 10 products by revenue at risk, and track demand and value fulfillment together as paired KPIs.
Compare the work
The same skill set applied five different ways — a cloud risk-and-controls pipeline, a PostgreSQL database built around public health data, cloud warehousing plus Tableau, the Microsoft BI stack, and a migration bridging both.
Click a project name to isolate what it actually used.
| Skill / technique | Fraud Controls | Drug Shortages | Revenue & Retention | Loan Default Risk | Inventory |
|---|---|---|---|---|---|
| Python & Pandas | ✓ | ✓ | ✓ | — | — |
| SQL (Databricks / Snowflake / SQL Server / MySQL / PostgreSQL) | ✓ | ✓ | ✓ | — | ✓ |
| Power BI & DAX | ✓ | — | — | ✓ | ✓ |
| Power BI row-level security & star schema | — | — | — | ✓ | — |
| Tableau | ✓ | — | ✓ | — | — |
| Tableau LOD expressions & data blending | — | — | ✓ | — | — |
| Tableau Cloud publishing & permissions | — | — | ✓ | — | — |
| Cloud data warehousing (layered / medallion) | ✓ | — | ✓ | — | — |
| Database migration | — | — | — | — | ✓ |
| Local GenAI / LLM classification & extraction | — | ✓ | ✓ | — | — |
| RFM & cohort retention analysis | — | — | ✓ | — | — |
| Data-quality remediation (simulated production) | — | — | — | — | ✓ |
| Excel workpaper | ✓ | — | — | — | — |
| Databricks & PySpark | ✓ | — | — | — | — |
| Alteryx | ✓ | — | — | — | — |
| Control testing & data assurance | ✓ | — | — | — | — |
| Machine learning (scikit-learn) | ✓ | — | — | — | — |
| Time-series forecasting | ✓ | — | — | — | — |
| PostgreSQL design, roles, backup & audit trail | — | ✓ | — | — | — |
| Google Sheets analysis & Excel scoring model | — | ✓ | — | — | — |
| Hypothesis testing | — | ✓ | — | — | — |
At a glance
| Project | Business question | Dataset | Primary tool | Headline result |
|---|---|---|---|---|
| Payment Fraud Controls | Can the data be trusted, and do the fraud controls work? | PaySim (public, synthetic) · 6,362,620 transactions, 8,213 frauds | Databricks + SQL + Alteryx | Best control reached 70.46% precision against a 0.13% baseline; a perfect-scoring model was flagged as leakage, not reported as a win |
| FDA Drug Shortages | Which drugs are short, for how long, and can the data and an AI model be trusted? | FDA Drug Shortages list (public) · 1,605 records; FDA NDC Directory for the oncology brief | PostgreSQL + Google Sheets + Excel | 69 drugs in current shortage, median 4.9 years on the list; the local LLM matched 57 of 60 recovery dates |
| Revenue & Retention | Who drives revenue, and who comes back? | UCI Online Retail II (public) · 1,033,036 transactions, 5,852 customers | Snowflake + Tableau | 72.35% of identified customers are repeat buyers, driving 96.74% of identified-customer sales |
| Loan Default Risk | Which borrower segments actually carry default risk? | Public loan dataset · 255,347 loans | Power BI + DAX | 11.61% default rate overall, up to 19.71% in the riskiest segment |
| Inventory Demand & Supply | Where does unmet demand become a business risk? | 99 product-level inventory records | SQL Server → MySQL + Power BI | $97.37K in revenue at risk identified down to the SKU |