Choosing the Right Technique and Where to Go Next

A request to use data is not yet an analysis plan. “Why did monthly revenue change?” asks for a report and monitoring. “Did the new checkout page increase conversion?” asks for a comparison that supports a decision. “Which borrowers may miss a payment?” asks for a prediction before a known outcome.

Before choosing a technique, restate every request as a question, name the decision it will support, and identify the unit of analysis. For loan default, one row may represent one loan application. For weekly demand, one row may represent one product in one week. For support triage, one row may represent one ticket.

The table weighs seven requests by the output they need and the first method family that fits.

This table shows why similar-looking requests separate into distinct jobs. Reporting describes or monitors. A/B tests compare alternatives. Regression and classifiers predict numeric or category outcomes. Clustering discovers groups without a target label. Forecasting extends a time series forward. Text analytics turns ticket text into usable inputs or labels, while recommenders rank unseen items for a person.

Follow the data-to-decision workflow

Once the output is clear, the same workflow turns a business request into an accountable result. Start with the business question, then use SQL to extract a query result table. Use pandas to create a cleaned DataFrame, inspect missing values and unusual records, and create a feature matrix only when the question requires one.

After preparation, compare against a baseline before choosing a model. Modeling is optional. A grouped KPI table may answer why monthly revenue drifted without any predictive model. A conversion decision may require an A/B test and a confidence interval, not a classifier.

The remaining stages make the result usable. Evaluation produces an evaluation table or chart. Interpretation explains what the result does and does not support. Packaging produces a reusable inference pipeline when repeated predictions are needed. The workflow is therefore:

• Question and decision

• SQL query result table

• Cleaned DataFrame

• Explored data and selected features

• Baseline or model

• Honest evaluation

• Explanation for the decision

• Reusable pipeline when appropriate

Choose from the decision backward

For missed loan payments, define the target as whether a borrower misses a payment within the next 30 days. The prediction horizon matters because a feature known after the application date cannot help make an application-time decision.

Next, state the cost of each error. A false negative approves a borrower who later misses payment. A false positive sends a lower-risk borrower to extra review or declines an application that would have repaid. Those costs determine whether recall, precision, or a threshold-based balance deserves priority.

A report of past missed payments cannot score a new application, and a fixed rule may ignore combinations of income, debt, and repayment history. Begin with a baseline such as one rule or the base rate. Then reserve a test set before model selection, use train and validation data for development, and evaluate a first-pass classifier against the baseline. The method family follows the decision, available features, and cost of errors. It does not follow a favorite algorithm.

Decision rule: Choose the output first, then choose the simplest method that can produce it and evaluate it against a baseline.

Run pre-flight trust checks

The choice is only credible when the evaluation matches how the result will be used. Before sharing a loan-risk model, a demand forecast, an A/B test, or a recommendation ranking, check the failure modes that can make a promising score misleading.

• Ask whether every feature was available at prediction time. A repayment status recorded after approval creates target leakage.

• Ask for the positive base rate before celebrating accuracy. When missed payments are rare, inspect the precision-recall curve and PR AUC.

• Ask whether the test set influenced tuning. If it did, the final score is no longer an independent check.

• Ask whether time order matters. Forecasts need walk-forward validation rather than random cross-validation.

• Ask what a p-value does and does not say. It measures compatibility with a null hypothesis under stated assumptions, not effect size or the probability that the hypothesis is true.

• Ask whether feature importance or a SHAP value proves a cause. These describe a fitted model’s associations, not causal effects.

Match each failure mode to the question that should block the result from being presented as trustworthy.

These checks turn evaluation into a gate rather than a final decoration. A classifier may require a train/validation/test split and PR AUC. A forecast requires time-respecting validation. An experiment requires its planned metric, stopping rule, and interpretation. A ranking system still needs held-out interactions and offline metrics before an online A/B test can test business impact.

Extend the workflow deliberately

The workflow now supports a broad range of data decisions, but some questions require a deeper specialization. Deep learning is a direction for learning representations from images, text, and sequences when manually designed features are not enough. It builds on the same framing, split, metric, and evaluation habits already used here. To go deeper on language models, the LLM Bootcamp covers prompt engineering, retrieval-augmented generation (RAG), fine-tuning with LoRA, and LLM evaluation.

Causal inference addresses effect questions such as whether changing a policy causes loan repayment to change. Experiments help when randomization is possible. Causal inference studies how to estimate effects when data is observational, but it depends on assumptions that prediction alone cannot verify.

Machine learning operations (MLOps) concerns reliable training, serving, and monitoring of models over time. Managed cloud platforms can support those operational tasks at larger scale, but they do not replace clear targets, valid splits, or cost-aware metrics.

Continue practicing with public datasets by repeating a compact cycle. Pick one decision, identify the row and target, define the error costs and metric, build a baseline, evaluate without leakage, and write a one-page narrative that states the recommendation and its limits. To strengthen the SQL, pandas, exploratory analysis, and storytelling skills behind that cycle, the Data Analytics Bootcamp covers data wrangling, statistical exploration, and data visualization in more depth. That repetition prepares us to approach harder data, causal questions, and production constraints without losing the discipline that made the first result trustworthy.