Skip to main content
Workforce LibreTexts

4.10: Best Practices in Data Cleaning and Preparation

  • Page ID
    48055
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\dsum}{\displaystyle\sum\limits} \)

    \( \newcommand{\dint}{\displaystyle\int\limits} \)

    \( \newcommand{\dlim}{\displaystyle\lim\limits} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \(\newcommand{\longvect}{\overrightarrow}\)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \(\newcommand{\ket}[1]{\left| #1 \right>}\)
    \(\newcommand{\bra}[1]{\left< #1 \right|}\)
    \(\newcommand{\braket}[2]{\left< #1 \vphantom{#2} \right| \left. #2 \vphantom{#1} \right>}\)
    \(\newcommand{\braopket}[3]{\left< #1 \vphantom{#2}\vphantom{#3} \right| #2 \vphantom{#1}\vphantom{#3} \left| #3 \vphantom{#1}\vphantom{#2} \right>}\)
    \(\newcommand{\qmvec}[1]{\mathbf{\vec{#1}}}\)
    \(\newcommand{\op}[1]{\hat{\mathbf{#1}}}\)
    \(\newcommand{\expect}[1]{\langle #1 \rangle}\)
    \(\newcommand{\dfn}[1]{\emph{\textbf{#1}}}\)

    \(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)

    Best Practices in Data Cleaning and Preparation

    Having discussed what to do and how to do it, it’s important to highlight some overarching best practices that experienced analysts and data engineers follow when cleaning and preparing data. These practices help produce cleaner data more reliably and efficiently:

    • Enforce Data Quality at the Source: Whenever possible, prevent bad data from entering your system in the first place. This means implementing validation rules, primary keys, foreign keys, and check constraints in the source databases or applications. For example, if a form feeds your database, add input validation (no letters in a phone number field, required fields cannot be blank, etc.). At the database level, use NOT NULL for required fields and define primary keys so duplicates are impossible to insert. It is much easier to stop garbage data at the source than to clean it later.

    • Understand the Context (Domain Knowledge): Cleaning decisions should be guided by an understanding of the data’s meaning. Domain knowledge can tell you what ranges are valid, which outliers are impossible versus merely rare, and how missing data should be interpreted. For instance, knowing that a temperature sensor cannot physically go below -50°C informs how you treat a -100 reading (clearly erroneous). Engage with subject matter experts if you’re unsure about business rules or the significance of data quirks.

    • Profile Data Early and Often: As soon as you receive a new dataset, do an initial data profiling – compute summary statistics, look at value distributions, check for nulls and duplicates. Tools can generate a data profile report (mean, median, most frequent values, etc.). This early scan will usually reveal the biggest data quality issues and give you a game plan for cleaning. Profiling isn’t one-and-done; after each major cleaning step, re-profile to see if issues have been resolved or if new ones emerged.

    • Use Incremental and Reproducible Cleaning Steps: Don’t do everything in one giant step. Break the cleaning into logical steps (maybe in code, multiple statements or in a tool, multiple recipe steps) focusing on one aspect at a time: e.g., Step 1: Handle missing values, Step 2: Fix types, Step 3: Remove outliers, etc. This makes it easier to troubleshoot if something goes wrong – you can pinpoint which step introduced an unintended change. Also, keep the process reproducible: if you had to start over with the raw data, you should be able to apply the same steps and get the same cleaned result. This often means scripting the steps (SQL script, Python script, or saving the transformation recipe in a tool).

    • Document and Justify Changes: Keep a record of what transformations you applied and why. This is crucial in an academic or professional setting to maintain data lineage and trust. If you decide to drop 5% of records due to missing fields, note that decision and the rationale (e.g., "Dropped 5% of rows where >3 fields were missing to ensure data completeness for analysis"). If you replace nulls with a default, mention that (and perhaps why that default). Documentation can be inline (comments in SQL or notebooks) and/or in a separate data cleaning log.

    • Preserve Raw Data: Always keep an untouched copy of the original data. Your cleaning process should create a new dataset rather than overwrite the original (unless you’re absolutely sure you want to permanently alter it). This way, if there’s a question later or if you accidentally over-clean (removing something that was actually real), you can recover from the raw source. It’s also useful for auditing – you might need to demonstrate how a specific raw record was transformed into its cleaned form.

    • Validate Against Expectations: After cleaning, verify that the data meets all the expectations (constraints and business rules) you are aware of. If you enforced them during cleaning, the final dataset should, for example, have no missing required fields, no duplicates on key fields, all values in valid ranges, etc. You could create a checklist and tick them off or even automate a suite of tests (sometimes called unit tests for data or assertions). One practical tip: if you have downstream analysis or models, do a dry run with the cleaned data to ensure nothing breaks (for instance, if a model expects a field to have no nulls and you missed one, it might error out).

    • Handle Outliers and Skew Appropriately: Don’t just remove outliers because they’re outliers; consider if they carry important information. The best practice is to examine outliers individually. If an outlier is due to data error, fix or remove it. If it’s legitimate but will unduly influence analysis, mark it and decide on analysis strategies (like use median or log transform). Transparency is key – for example, you might note "We observed 3 extremely high values which were valid entries (mega customers); analysis of central tendency uses median to avoid their influence."

    • Iterate and Collaborate: Data cleaning is often iterative. You might clean what you think is everything, start analyzing, and then notice something odd (maybe a particular category was overlooked). Be prepared to iterate: go back, refine the cleaning, and re-run. Additionally, collaborate with others – sometimes a fresh pair of eyes catches issues you missed. In professional settings, teams may do peer reviews of cleaning scripts or have multiple people test the data. This reduces the chance of a critical oversight.

    • Automate Recurrent Cleaning Tasks: If you receive data periodically (daily logs, monthly reports, etc.), invest time in automating the cleaning pipeline. This could mean scheduling an SQL script or using a data pipeline tool. Automation ensures consistency – you won’t forget a step on the 10th dataset that you did on the 1st. Automation should include automated quality checks so it can alert you if suddenly the incoming data breaks an assumption (for example, if one day 50% of data is missing a field, an alert should notify you rather than silently dropping half the data).

    • Keep Data Privacy and Security in Mind: When cleaning data, especially sensitive data, be cautious with how you handle it. For instance, removing outliers might inadvertently allow identification of a person (if one value is unique to them). Data preparation in secure environments like the cloud should follow compliance rules. If using a tool like Dataprep on cloud, ensure the data is properly protected (the tool itself handles security, but you need to manage who has access to the cleaning recipes and results). Anonymize or aggregate personally identifiable information (PII) if not needed at granular level.

      Data Cleaning Workflow — From Raw Data to Analysis-Ready Dataset. Details in caption.

    Figure \(\PageIndex{1}\): From Raw Data to Analysis-Ready Dataset. Outlines a systematic, step-by-step pipeline for data cleaning including profiling, handling missing values, type conversion, deduplication, validation, and documentation. (CC BY 4.0; Felix Amoruwa) Access to a detailed description of Figure \(\PageIndex{1}\)

    Applying these best practices leads to more reliable outcomes. As a rule of thumb: treat data cleaning as an integral part of the analytic process, not a perfunctory hurdle. It is often said that data preparation is 80% of the work in data science, and while that might be a slight exaggeration, it underscores the reality that this is where much of the critical thinking and effort goes. Embracing that fact and doing it systematically will improve the quality of any analysis that follows.


    By following the guidance in this chapter – understanding the importance of data cleaning (GIGO), checking for completeness, correctness, and consistency (NULLs, types, ranges, keys, etc.), leveraging the power of SQL and modern data prep tools, and adhering to best practices – students and professionals can ensure that their datasets are well-prepared for insightful analysis. Clean data is the bedrock of trustworthy analytics. Investing time and care in data cleaning and preparation yields dividends in the form of accurate results, robust models, and credible insights. Or, in simpler terms: clean data in, useful information out – the positive version of GIGO that every analyst should strive for.


    This page titled 4.10: Best Practices in Data Cleaning and Preparation was last modified on Wed, 16 Sep 2026 21:43:07 GMT and is shared under a CC BY 4.0 license and was authored, remixed, and/or curated by Felix Amoruwa.

    • Was this article helpful?