Having a record of how a data set evolved does three very important things.

• Recover data-cleaning errors
• Inform other users of changes
• Determine quality of data

What do engineers, writers, and data analysts have in common? Change.

Engineers use engineering change orders (ECOs) to keep track of new product design details and proposed changes to existing products. Writers use document revision histories to keep track of changes to document flow and edits. And data analysts use changelogs to keep track of data transformation and cleaning. Here are some examples of these:

Most software applications have a kind of history tracking built in. For example, in Google sheets, you can check the version history of an entire sheet or an individual cell and go back to an earlier version. In Microsoft Excel, you can use a feature called Track Changes. And in BigQuery, you can view the history to check what has changed.

Here’s how it works:

Google Sheets:

1. Right-click the cell and select Show edit history.
2. Click the left-arrow < or right arrow > to move backward and forward in the history as needed.

Microsoft Excel:

1. If Track Changes has been enabled for the spreadsheet: click Review.
2. Under Track Changes, click the Accept/Reject Changes option to accept or reject any change made.

BigQuery:

• Bring up a previous version (without reverting to it) and figure out what changed by comparing it to the current version.

A changelog can build on your automated version history by giving you an even more detailed record of your work. This is where data analysts record all the changes they make to the data. Here is another way of looking at it. Version histories record what was done in a data change for a project, but don't tell us why. Changelogs are super useful for helping us understand the reasons changes have been made. Changelogs have no set format and you can even make your entries in a blank document. But if you are using a shared changelog, it is best to agree with other data analysts on the format of all your log entries.

Typically, a changelog records this type of information:

• Data, file, formula, query, or any other component that changed
• Description of what changed
• Date of the change
• Person who made the change
• Person who approved the change
• Version number
• Reason for the change

Let’s say you made a change to a formula in a spreadsheet because you observed it in another report and you wanted your data to match and be consistent. If you found out later that the report was actually using the wrong formula, an automated version history would help you undo the change. But if you also recorded the reason for the change in a changelog, you could go back to the creators of the report and let them know about the incorrect formula. If the change happened a while ago, you might not remember who to follow up with. Fortunately, your changelog would have that information ready for you! By following up, you would ensure data integrity outside your project. You would also be showing personal integrity as someone who can be trusted with data. That is the power of a changelog!

Finally, a changelog is important for when lots of changes to a spreadsheet or query have been made. Imagine an analyst made four changes and the change they want to revert to is change #2. Instead of clicking the undo feature three times to undo change #2 (and losing changes #3 and #4), the analyst can undo just change #2 and keep all the other changes. Now, our example was for just 4 changes, but try to think about how important that changelog would be if there were hundreds of changes to keep track of.

A junior analyst probably only needs to know the above with one exception. If an analyst is making changes to an existing SQL query that is shared across the company, the company most likely uses what is called a version control system. An example might be a query that pulls daily revenue to build a dashboard for senior management.

Here is how a version control system affects a change to a query:

1. A company has official versions of important queries in their version control system.
2. An analyst makes sure the most up-to-date version of the query is the one they will change. This is called syncing
3. The analyst makes a change to the query.
4. The analyst might ask someone to review this change. This is called a code review and can be informally or formally done. An informal review could be as simple as asking a senior analyst to take a look at the change.
5. After a reviewer approves the change, the analyst submits the updated version of the query to a repository in the company's version control system. This is called a code commit. A best practice is to document exactly what the change was and why it was made in a comments area. Going back to our example of a query that pulls daily revenue, a comment might be: Updated revenue to include revenue coming from the new product, Calypso.
6. After the change is submitted, everyone else in the company will be able to access and use this new query when they sync to the most up-to-date queries stored in the version control system.
7. If the query has a problem or business needs change, the analyst can undo the change to the query using the version control system. The analyst can look at a chronological list of all changes made to the query and who made each change. Then, after finding their own change, the analyst can revert to the previous version.
8. The query is back to what it was before the analyst made the change. And everyone at the company sees this reverted, original query, too.

A changelog is a document used to record the notable changes made to a project over its lifetime across all of its tasks. It is typically curated, and the changes it records are listed chronologically across all the different versions of the project.

The major benefit to using changelogs is that contributors and users connected with the project get a specific list of what important alterations have been made, when they were made, and sometimes, what version they were released for. It is an invaluable tool for communicating how the project has evolved over time to coworkers, management, and stakeholders.

A changelog for a personal project may take any form desired. However, in a professional setting, particularly when collaborating with others, readability is important. In light of this, you can follow the guiding principles that make the interpretation of the changelog accessible to others:

• Changelogs are for humans, not machines, so write legibly
• Every version should have its own entry
• Group the same types of changes. For example, "Fixed" should be grouped separately from "Added"
• Each change gets its own line
• Versions should be ordered chronologically starting with the latest
• Release date of each version should be noted

Types of changes usually fall into one of the following categories. All the changes for each category should be grouped together.

• Added: new features introduced
• Changed: changes in existing functionality
• Deprecated: features about to be removed
• Removed: features that have been removed
• Fixed: bug fixes
• Security: lowering vulnerabilities

Examine the figure below for an example of a changelog.

# Changelog
This file contains the notable changes to the project

Version 1.0.0 (02-23-2019)
## New
    - Added column classifiers (Date, Time, PerUnitCost, TotalCost, etc. )
    - Added Column “AveCost” to track average item cost

## Changes 
    - Changed date format to MM-DD-YYYY
    - Removal of whitespace (cosmetic)

## Fixes
    - Fixed case where exception was thrown when cases didn’t match for category labels
    - Fixed SUM to run over entire column instead of partial

In the final course in this certification program, you’ll have the opportunity to complete a capstone project. This is a great chance to demonstrate your ability to organize a project like a professional data analyst by keeping your own changelog. You can do this using a simple companion text file that can be included with the project write-up.

In the log, you will want to record the various changes, additions, fixes, etc. that were discussed above. Arrange them using bullets or similar with one change per bullet. Group similar changes together with a label describing the change immediately above them.

Use different version numbers for each milestone reached in your project. Within each version, place the logged changes that were made since the previous version (milestone). Dates are not generally necessary for each change, but they are recommended for each version.

Keep this in mind when you reach the capstone project in a later course.

Use this knowledge to create and maintain a changelog for your data cleaning capstone project. It will help you stay organized and make collaborating with others much easier.

• What makes for a good changelog?
• How do you decide if a change is significant enough to include in the changelog?

A good changelog should indicate the notable changes to a project. If you perform any of the following changes to the dataset while cleaning, you should capture those changes in the changelog:

• Treated missing data
• Changed formatting
• Changed values or cases for data

Chances are that you have made some of these changes while cleaning the data. Also, any other substantial changes should be included. As a rule-of-thumb, when in doubt about the significance of a change, you should enter it into the changelog.

In this reading, you will learn about some advanced functions that can help you speed up the data cleaning process in spreadsheets. Below is a table summarizing three functions and what they do:

The IMPORTRANGE function in Google Sheets and the Paste Link feature (a Paste Special option in Microsoft Excel) both allow you to insert data from one sheet to another. Using these on a large amount of data is more efficient than manual copying and pasting. They also reduce the chance of errors being introduced by copying and pasting the wrong data. They are also helpful for data cleaning because you can “cherry pick” the data you want to analyze and leave behind the data that isn’t relevant to your project. Basically, it is like canceling noise from your data so you can focus on what is most important to solve your problem. This functionality is also useful for day-to-day data monitoring; with it, you can build a tracking spreadsheet to share the relevant data with others. The data is synced with the data source so when the data is updated in the source file, the tracked data is also refreshed.

If you are using IMPORTRANGE in Google sheets, data can be pulled from another spreadsheet, but you must allow access to the spreadsheet the first time it pulls the data. The URL shown below is for syntax purposes only. Don't enter it in your own spreadsheet. Replace it with a URL to a spreadsheet you have created so you can control access to it by clicking the Allow access button.

Refer to the Google support page for IMPORTRANGE for the sample usage and syntax.

An analyst monitoring a fundraiser needs to track and ensure that matching funds are distributed. They use IMPORTRANGE to pull all the matching transactions into a spreadsheet containing all of the individual donations. This enables them to determine which donations eligible for matching funds still need to be processed. Because the total number of matching transactions increases daily, they simply need to change the range used by the function to import the most up-to-date data.

On Tuesday, they use the following to import the donor names and matched amounts:

=IMPORTRANGE(“https://docs.google.com/spreadsheets/d/1cOsHnBDzm9tBb8Hk_aLYfq3-o5FZ6DguPYRJ57992_Y”, “Matched Funds!A1:B4001”)

On Wednesday, another 500 transactions were processed. They increase the range used by 500 to easily include the latest transactions when importing the data to the individual donor spreadsheet:

=IMPORTRANGE(“https://docs.google.com/spreadsheets/d/1cOsHnBDzm9tBb8Hk_aLYfq3-o5FZ6DguPYRJ57992_Y”, “Matched Funds!A1:B4501”)

Note: The above examples are for illustrative purposes only. Don't copy and paste them into your spreadsheet. To try it out yourself, you will need to substitute your own URL (and sheet name if you have multiple tabs) along with the range of cells in the spreadsheet that you have populated with data.

The QUERY function is also useful when you want to pull data from another spreadsheet. The QUERY function's SQL-like ability can extract specific data within a spreadsheet. For a large amount of data, using the QUERY function is faster than filtering data manually. This is especially true when repeated filtering is required. For example, you could generate a list of all customers who bought your company’s products in a particular month using manual filtering. But if you also want to figure out customer growth month over month, you have to copy the filtered data to a new spreadsheet, filter the data for sales during the following month, and then copy those results for the analysis. With the QUERY function, you can get all the data for both months without a need to change your original dataset or copy results.

The QUERY function syntax is similar to IMPORTRANGE. You enter the sheet by name and the range of data that you want to query from, and then use the SQL SELECT command to select the specific columns. You can also add specific criteria after the SELECT statement by including a WHERE statement. But remember, all of the SQL code you use has to be placed between the quotes!

Google Sheets run the Google Visualization API Query Language across the data. Excel spreadsheets use a query wizard to guide you through the steps to connect to a data source and select the tables. In either case, you are able to be sure that the data imported is verified and clean based on the criteria in the query.

Check out the Google support page for the QUERY function with sample usage, syntax, and examples you can download in a Google sheet.

Link to make a copy of the sheet: QUERY examples

Analysts can use SQL to pull a specific dataset into a spreadsheet. They can then use the QUERY function to create multiple tabs (views) of that dataset. For example, one tab could contain all the sales data for a particular month and another tab could contain all the sales data from a specific region. This solution illustrates how SQL and spreadsheets are used well together.

The FILTER function is fully internal to a spreadsheet and doesn’t require the use of a query language. The FILTER function lets you view only the rows (or columns) in the source data that meet your specified conditions. It makes it possible to pre-filter data before you analyze it.

The FILTER function might run faster than the QUERY function. But keep in mind, the QUERY function can be combined with other functions for more complex calculations. For example, the QUERY function can be used with other functions like SUM and COUNT to summarize data, but the FILTER function can't.

Check out the Google support page for the FILTER function with sample usage, syntax, and examples you can download in a Google sheet.

Link to make a copy of the sheet: FILTER examples

TOTAL POINTS 3

Why is it important for a data analyst to document the evolution of a dataset? Select all that apply.

• To identify best practices in the collection of data
• To inform other users of changes
• To recover data-cleaning errors
• To determine the quality of the data

Correct. It is important to document the evolution of a dataset in order to recover data-cleaning errors, inform other users of changes, and determine the quality of the data.

Fill in the blank: While cleaning data, documentation is used to track _____. Select all that apply.

• bias
• errors
• changes
• deletions

Correct. While cleaning data, documentation is used to track changes, deletions, and errors.

Documenting data-cleaning makes it possible to achieve what goals? Select all that apply.

• Keep team members on the same page
• Visualize the results of your data analysis
• Demonstrate to project stakeholders that you are accountable
• Be transparent about your process

Correct. Documenting data-cleaning makes it possible to be transparent about your process, keep team members on the same page, and demonstrate to project stakeholders that you are accountable.