D467 Exploring Data is BUS 2770 in the WGU catalog and carries 3 competency units, covering the organization, preparation, transformation, cleaning and verification of data using spreadsheets and SQL. It is the least glamorous course in the analytics sequence and the one that most determines whether later work is trustworthy. Its distinctive scoring requirement is documentation: a cleaning decision that is not recorded cannot be evaluated, and every aspect needs a 2. D467 and BUS 2770 are the same course.
What D467 builds toward
Real business data arrives broken in predictable ways. Dates in three formats because three systems wrote them. Customer names duplicated with trailing spaces. Numbers stored as text so they will not sum. Categories that mean the same thing spelled four ways. Rows missing the one field the analysis needs. The course teaches the sequence for finding and fixing these, and the SQL half teaches the language that does it at scale when a spreadsheet stops being sensible.
The habit it is really building is verification: the assumption that a data set is wrong until you have checked, and the discipline of checking in a way you could show someone. That habit is what makes the analytical courses that follow, D466 Analyzing and Visualizing Data and D465 Data Applications, produce numbers anyone should believe.
Aspects that ask you to prove a process
The WGU catalog does not publish assessment types or task requirements; those live in the Course of Study inside your portal. If a performance assessment carries your version, note that preparation aspects are process aspects, and a process is demonstrated by a record rather than by a result. Plan to keep a log while you work, not to reconstruct one afterwards.
A worked example. Nine aspects: four covering cleaning and transformation steps, three covering SQL or query work, two covering verification, with a 1,700 word written component. Reserve 120 for the data description and 80 for the close, leaving 1,500. The four cleaning aspects take 190 each, giving 760. The three query aspects need explanation of about 170 each, giving 510. The two verification aspects take 115 each, giving 230. Sum: 760 plus 510 plus 230 equals 1,500. Alongside that, plan the log: one line per change, with the field, the rule applied, the number of rows affected and the reason. That log is not overhead, it is the evidence for at least four of the nine aspects.
A cleaning record an evaluator can follow
| Problem found | Rule applied | What to record |
|---|---|---|
| Duplicate records | The definition of a duplicate, and which copy is kept | Rows before, rows removed, the key fields compared |
| Inconsistent categories | The mapping from variants to a standard value | The full mapping table, not a summary of it |
| Missing values | Excluded, imputed, or flagged and reported | Count per field and the rule chosen for each |
| Wrong data types | Conversion applied and how failures were handled | How many values failed to convert and what happened to them |
| Out of range values | The plausible range and its justification | The bound used and the count outside it |
| Date normalization | The target format and the parsing assumption | Which ambiguous dates were interpreted and how |
| Verification | The checks run after cleaning | Row counts, totals reconciled, and spot checks against source |
Evidence in a data preparation task
The evidence is the audit trail. Keep the raw data untouched on its own sheet or table, do all work on a copy, and record every transformation. Counts are the currency: the number of rows before and after each step, the number of values changed, the number that failed. Those numbers let a reader confirm that nothing disappeared silently, which is the single most common way a data set gets quietly corrupted.
For SQL work, the query is the evidence and it should be readable: formatted across lines, with joins and filters visible, and a comment stating what it is intended to return. Include the row count the query produced, since a join that unexpectedly multiplies rows is the classic error and a count exposes it immediately. Where external data or methodology sources are used, cite them in APA. Submitted work is scanned through WGU's Similarity Checker where applicable, so write queries and documentation yourself rather than adapting published examples.
What passes in a preparation course
WGU records Competent or Not Competent, keeps no letter grades and no GPA, and each aspect requires a 2. D467 submissions return most often for undocumented decisions. A cleaned file is presented, it looks correct, and nothing in the document says what was changed or why, leaving several process aspects with nothing to score.
Passing submissions read like a lab notebook. Every change has a rule, every rule has a reason, and every step has a count attached. They also include at least one verification that could have failed: totals reconciled against the source, a sample of records checked by hand, or a sanity comparison against an external figure. Saying that a check was run and passed is worth more than an assertion that the data is now clean, because the first is evidence and the second is a claim. Comments on a returned task name each failing aspect, and resubmission carries no penalty.
Six mistakes that cost time in D467
- Cleaning the original file. Working in place destroys your ability to check, redo or explain, and one wrong step becomes permanent.
- Deleting rows silently. Removals without a stated rule and a count make every later total unverifiable.
- Joins that multiply rows. A join on a non-unique key inflates results, and without a row count nobody notices until the numbers are strange.
- Ambiguous dates guessed. A date that could be two different days needs a stated assumption, not a silent choice.
- Category mapping summarized. Saying variants were standardized is not the mapping, and the mapping is the evidence.
- No verification step. A preparation task with no check performed leaves the verification aspects unmet by definition.
Cleaning task with a documentation aspect
Send the rubric and the data file. The model submission comes back with a full cleaning log, readable queries and verification counts, mapped aspect by aspect.
SQL for people who came from spreadsheets
SQL frightens business students more than it should, because the mental model transfers almost directly from spreadsheet work. A table is a sheet. Selecting columns is choosing which columns to look at. A filter is the equivalent of hiding rows that do not meet a condition. Grouping and aggregating is a pivot. A join is a lookup that brings columns from a second table alongside the first.
The one concept without a clean spreadsheet analogue is the join type, and it is worth understanding properly because it causes most beginner errors. An inner join keeps only rows that matched in both tables, which silently drops records and is the reason a customer count sometimes shrinks after a join. A left join keeps every row from the first table and fills blanks where no match was found, which is usually what a business question wants, since customers with no orders are still customers. Choosing between them is an analytical decision, not a technical one, and stating which you used and why will satisfy query aspects that a bare result cannot.
The practical habit that prevents most trouble is to count before and after. Run a count on the base table, run the join, count again. If the number grew, the key was not unique and the result is duplicated. If it shrank more than expected, an inner join dropped records you needed. Two counts take ten seconds and catch the errors that would otherwise propagate through an entire analysis.
Three questions D467 students ask
How much cleaning is too much?
Do I need a database to practice SQL?
What does support look like on a preparation course?
Three CUs against a flat term
Preparation work is the most interruption-tolerant course in the analytics sequence, because the log carries your place: you can stop mid-clean, read the last line of the record, and resume. That makes D467 a good parallel course to run alongside a writing-heavy one inside the same six month flat-rate term. It is also the course whose habits speed up every later analytics course, so taking it early in the sequence pays twice. See the pacing page.
Where D467 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.