Data Science and Business Analytics

01Purpose and scope

• This manual supports the course Data Science and Business Analytics. It describes how practitioners in companies, public agencies, and nonprofits move from a business question to a tested answer that someone is willing to act on.
• The scope covers descriptive reporting, predictive modeling, experimentation, and prescriptive analysis such as optimization. It does not teach deep statistical theory or general software engineering, although it notes the points where an analyst needs to understand them. Regulated decisions in lending, insurance, healthcare, and employment need additional review. This guidance does not replace qualified professional judgment, approved procedures, or required authorization.
• Practice changes with context. A retail team forecasting weekly demand works with fast feedback and low cost errors, while an analyst supporting credit policy works with slower validation, model governance, and formal sign-off. The same sequence of steps applies in both settings, but the depth of testing and documentation differs a great deal.

02Core principles

• Start from the decision, not the dataset. Before any query is written, the team should be able to name the decision, the people who make it, the options available, and roughly what a better choice would be worth.
• Keep the question stable and the method flexible. Business questions often shift during a project as stakeholders learn more. Write each change down and reconcile it with the original goal instead of quietly redefining success.
• Prefer models that people can understand over models that only perform well on paper. A logistic regression that operations staff can trace may deliver more value than a boosted ensemble nobody trusts. Added complexity needs a reason tied to accuracy the decision actually requires.
• Treat data as a product with an owner. Source systems change, fields get reused, and definitions drift over time. Every metric should have a written definition, a named source, and a steward who answers questions about it.

03Planning and preparation

• Begin with a short problem statement that includes the decision, the unit of analysis, the time horizon, and the action threshold. A subscription business might ask which customers with a renewal in the next thirty days are likely to cancel, and whether a retention offer costing a fixed amount per customer would pay for itself.
• Inventory data sources early. List each table or file, the system it comes from, its refresh schedule, known gaps, and who can grant access. Access requests often take longer than the modeling itself, so start them in parallel with scoping rather than after.
• Agree on success measures before modeling. Choose one primary measure tied to value, such as incremental margin or avoided cost, and a few guardrail measures such as false positive rate or complaint volume. Define the baseline, which is usually the current process or a simple rule of thumb.
• Decide the minimum deliverable. The output might be a dashboard, a scored list, a recommendation memo, or an automated feature in a application. Each implies different testing, ownership, and maintenance, so settle the form before the work starts.

04Recommended workflow

1. 1
   : Frame the question with the decision owner. Confirm who holds decision rights, what information they need, and what they will do with each possible answer. Write the problem statement and get it approved in writing.
2. 2
   : Extract and profile the data. Check row counts, null rates, duplicate keys, and date coverage against what the business expects. Compare totals with a finance or operations report that the audience already trusts.
3. 3
   : Build the analytic dataset with a documented, rerunnable script. Record every join, filter, and derived field along with the reason for it. Keep raw extracts unchanged so that the work can be audited later.
4. 4
   : Explore the data to understand distributions, seasonality, and relationships. Look specifically for leakage, meaning fields that only become known after the outcome has already occurred.
5. 5
   : Analyze or model. Descriptive work needs reproducible summaries with stated definitions. Predictive work should split data by time where outcomes depend on time, fit a simple baseline first, then compare one or two candidates on held out data.
6. 6
   : Translate results into the decision. Convert predicted probabilities or forecast ranges into expected value using the actual cost of errors, and show how sensitive the recommendation is to the main assumptions.
7. 7
   : Deliver, monitor, and hand over. Provide the output with a named owner, a refresh plan, a review interval, and monitoring for input drift and outcome performance. Confirm that the people who will operate the output have been trained on it.

05Quality checks, risk controls and compliance

• Reconcile key numbers against a trusted source before presenting anything. A revenue figure that differs from finance by a small amount may be acceptable if the definitions differ, but the difference must be explained in writing.
• For predictive models, validate on data the model did not see during training. Check performance across important segments such as region, product line, or customer tenure, because overall accuracy can hide a group where the model fails badly.
• Control for leakage, label errors, and overfitting. Keep a final holdout set locked until the last comparison, and record how many candidate models or variants were tried so that the reported result is not overstated.
• Privacy and fairness rules depend on jurisdiction and sector. Personal data handling may fall under laws such as the EU General Data Protection Regulation or the California Consumer Privacy Act, and health and financial data have their own sector rules. Confirm the current requirements with your privacy office and legal counsel, and treat their text as the governing source rather than this manual.
• Limit access by role, mask identifiers where the analysis does not need them, and keep an audit trail of who pulled which extract and when it was pulled. Do not store extracts on personal drives or in unapproved tools, even for convenience.

06Collaboration and documentation

• Name roles explicitly. A decision owner accepts the risk, an analyst builds the work, a data engineer maintains pipelines, a domain expert checks whether results make operational sense, and a reviewer challenges the method. Small teams may combine roles, but accountability should stay clear.
• Hold a short review at each point where scope could shift. Bring the decision owner, the domain expert, and whoever will operate the output. Record decisions and open questions in a shared project log rather than in meeting memory.
• Document with enough detail that a colleague can rerun the work. Include the problem statement, data lineage, code location, assumptions, metric definitions, model version, and known limits. A one page summary for executives should link to this fuller record.
• Write results in terms the decision owner can act on. State the recommendation, the expected effect with a range, the main risks, and the conditions that would change the answer. Lead with the decision and keep model names out of the headline.

07Measures and continuous improvement

• Track measures at three levels: project outcome, model or report quality, and operational health. Project outcome might be realized lift against a control group. Model quality includes calibration and error rates by segment. Operational health covers refresh success, latency, and the share of records failing quality checks.
• Use controlled experiments where feasible. A holdout group that keeps the old process gives the cleanest estimate of impact. When randomization is not possible, use a clearly described quasi-experimental method and state its assumptions plainly.
• Review drift on a set schedule. Compare input distributions and realized outcomes with the training period. When drift crosses a threshold agreed in advance, retrain, recalibrate, or stop using the output until it is fixed.
• Hold a retrospective after each project. Record what the team expected, what happened, and what would change next time. Feed the lessons into templates and reusable code so they persist after the people involved have moved on.

08Common mistakes and how to prevent them

• Optimizing a metric that does not match the decision. A model with strong ranking accuracy may still recommend actions that cost more than they save. Prevent this by converting outputs into expected value early and reviewing the threshold with the decision owner.
• Training on information that arrives too late. A feature such as a support ticket created after a cancellation can make a model look excellent in testing and useless in production. Prevent this by recording when each feature becomes available and filtering accordingly.
• Trusting a dashboard without reconciling it. Duplicate joins and silently changed filters can inflate totals by a wide margin. Prevent this with row count checks and a standing comparison against a trusted report.
• Skipping the handover. Analysis that lives in one person's notebook decays quickly once that person changes roles. Prevent this by requiring a named owner, a runbook, and a scheduled review before the project is closed.
• Presenting point estimates without uncertainty. A single number invites overreaction to noise. Show ranges and the conditions under which the recommendation would reverse.

09Practical checklist

• Written decision, decision owner, and action threshold agreed before analysis begins.
• Data sources inventoried with access granted and known gaps recorded.
• Primary success measure and guardrail measures defined with a baseline.
• Analytic dataset built by a rerunnable script with raw extracts preserved.
• Totals reconciled against a trusted report and the reconciliation documented.
• Validation done on held out or future data, with segment level results reviewed.
• Privacy, access, and sector rules confirmed with the appropriate internal authority.
• Output handed over with an owner, refresh plan, review interval, and drift monitoring.

★Learning sources

• Micro Degree: Data Science and Business Analytics
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics