# What I Learned and What I Did

## Project overview

I completed an applied machine-learning project for **content refresh prioritization**. The goal was to help an editor decide which pages should be reviewed first when it is not possible to review every page at the same time.

The output is a ranked review queue and decision-support workflow. It is **not** an automatic publishing system, a causal study, or a guarantee of future traffic or Google rankings.

## What I did

1. **Framed the problem**
   - Converted a broad SEO/content question into a practical ranking problem.
   - Defined the user decision: which content deserves human review first.
   - Considered the costs of false positives and false negatives.

2. **Inspected and documented the data**
   - Used the public-safe anonymized starter dataset.
   - Worked with content, search, engagement, age, freshness, and performance fields.
   - Kept pseudonymous IDs for grouping and validation only, never as model features.
   - Documented the data contract, percentage scales, missing values, and limitations.

3. **Prepared features**
   - Cleaned numeric values and missing data.
   - Created log-transformed traffic features such as impressions, clicks, and sessions.
   - Cleaned average position values where zero represented missing information.
   - Created flags such as whether a page had clicks and whether it had measurable opportunity.
   - Excluded identifiers and fields that could leak the label.

4. **Created a transparent baseline**
   - Built a staleness-plus-visibility rule.
   - Prioritized older pages and pages with greater visibility.
   - Used the baseline as a simple benchmark that a machine-learning model needed to beat.

5. **Audited leakage**
   - Found that using recent and previous comparison-window fields could reconstruct the decline label almost perfectly.
   - Recognized that this was circular rather than a genuine predictive result.
   - Removed the label-window fields from the honest model.

6. **Trained a machine-learning model**
   - Compared the baseline with a Random Forest classifier.
   - Used 200 trees, maximum depth 8, and random seed 42.
   - Used profile and historical aggregate features rather than the fields that directly defined the label.

7. **Validated the model honestly**
   - Used five-fold `GroupKFold` validation grouped by client.
   - Compared the model and baseline on the same held-out folds.
   - Measured Precision@50 as the main queue metric and ROC-AUC as a secondary metric.

8. **Evaluated and explained results**
   - Produced aggregate metrics, feature importance summaries, and charts.
   - Converted model output into a ranked review queue.
   - Added practical reason codes and human-review recommendations.

9. **Created reports and communication materials**
   - Generated Markdown and PDF report artifacts.
   - Wrote limitations and no-go rules.
   - Prepared a five-minute demo outline, social-post summary, and project summary.

10. **Kept the project reproducible and safe**
    - Used a fixed random seed.
    - Kept metrics receipts in `work/outputs/`.
    - Avoided committing datasets and private client information.
    - Used careful language such as *observed*, *measured*, *directional*, and *decision-support*.

## What I learned

### Machine learning

- Machine learning starts with a clear decision and target, not with choosing an algorithm.
- A simple baseline is essential because it provides an understandable comparison.
- A high score is not automatically a good result; it may indicate data leakage.
- Features that define the label must not be used as if they were independent predictors.
- Grouped validation is important when records belong to repeated clients or organizations.
- Precision@K is useful when a team can only review a limited number of items.
- Feature importance can help explain a model, but it does not prove causation.
- A model can be useful as a ranking aid even when it is not a calibrated forecast.

### Data analysis

- Data contracts make assumptions explicit before modeling.
- Percentages and missing-value conventions must be understood correctly.
- Cross-sectional data cannot establish time-forward prediction or causal impact.
- Small-volume observations are less reliable and should be treated cautiously.
- Aggregate charts and metrics are safer public outputs than row-level data dumps.

### Responsible engineering

- An anonymized or hashed identifier is still pseudonymous data and must be handled carefully.
- Private client data should not be sent to unapproved third-party tools.
- A responsible model includes limitations, monitoring, and no-go cases.
- Human review is required before changing, deleting, redirecting, canonicalizing, deindexing, or rewriting content.
- The strongest finding can be a negative result: detecting and removing leakage improved the honesty of the analysis.

## Programming language used

### Python

The project was implemented primarily in **Python**. Python was used for:

- Data loading and cleaning
- Feature engineering
- Exploratory analysis
- Baseline scoring
- Machine-learning training
- Cross-validation
- Metric calculation
- Chart generation
- Markdown/PDF report generation
- Notebook execution and pipeline automation

### Supporting formats and technologies

- **Jupyter Notebook / IPython** for interactive analysis and documentation
- **Markdown** for reports, documentation, and project notes
- **JSON** for reproducible metric receipts and configuration-like outputs
- **CSV** for the anonymized input data and generated queue artifacts
- **Bash/command line** for running the pipeline and notebook verification
- **Git/GitHub** for version control and project submission

## Libraries and tools used

### Python libraries

| Library | Use |
|---|---|
| `pandas` | Tabular data loading, cleaning, grouping, and summaries |
| `numpy` | Numerical operations, transformations, and missing-value handling |
| `scikit-learn` | Random Forest modeling, grouped cross-validation, and ROC-AUC evaluation |
| `matplotlib` | Model comparison and age-band charts |
| `reportlab` | Shareable PDF report generation |
| `DuckDB` | Available for querying larger analytical datasets without loading everything into memory |
| `huggingface_hub` | Available for approved access to the hosted dataset release |
| Python `json` | Reading and writing metric receipts |
| Python `pathlib` | Portable file and directory handling |
| Python `subprocess` | Running the multi-step reference pipeline |
| Python `warnings` | Controlling non-critical notebook warnings |

### Project tools

- **Jupyter**: Executed the capstone notebook from top to bottom.
- **Google Colab**: Supported notebook-based development and reproducible execution.
- **Git and GitHub**: Managed source files, notebooks, documentation, and outputs.
- **Command line**: Ran scripts and verification commands.
- **The repository pipeline**: Connected preparation, baseline scoring, training, evaluation, and reporting.
- **DuckDB workflow**: Provides a path for querying the much larger warehouse release without downloading the full dataset.

## Main project workflow

```text
Problem framing
    ↓
Data contract and safety review
    ↓
Data cleaning and feature engineering
    ↓
Transparent baseline
    ↓
Leakage audit
    ↓
Honest Random Forest model
    ↓
Client-grouped validation
    ↓
Precision@50 and ROC-AUC evaluation
    ↓
Ranked review queue
    ↓
Charts, Markdown report, and PDF report
```

## Main measured result

On the completed capstone notebook's same client-grouped five-fold evaluation:

- Dataset size: **30,000 rows**
- Grouping: **32 pseudonymous clients**
- Decline-label base rate: **0.5421**
- Baseline Precision@50: **0.5640**
- Honest Random Forest Precision@50: **0.7880**
- Honest Random Forest ROC-AUC: **0.6728**
- Precision lift over baseline: **0.2240 points**
- Precision relative to the base rate: **1.45x**

These are measured results for this anonymized snapshot and validation design. They should not be interpreted as proof of causal refresh impact or as a guarantee on future data.

## Important limitation

The dataset is a snapshot containing comparison windows, not a reliable daily time-series experiment. The next stronger version should use the approved daily warehouse panel, define features from the past, seal a genuinely future outcome label, and use time-forward validation. Measuring the effect of actually refreshing content would require a matched or experimental design.

## Final takeaway

The most important lesson was that a responsible machine-learning project is more than training a model. It requires a well-defined decision, safe data handling, a transparent baseline, leakage detection, honest validation, explainable recommendations, and clear limits on how the result may be used.

#Github link & Live deploy
https://arbazshah52.github.io/Week1-internship-/
https://github.com/arbazshah52/Week1-internship-.git