The Data Analysis Process

An order date, a customer comment and a delivery time are all data. They record something observed or captured. A single fact is a datum; an organized collection is a dataset. The meaning of a value depends on what it describes and how it was recorded.

Read the structure of a dataset

In a typical table, each row is one record and each column is an attribute of that record. An orders table might have one order per row and columns for order number, date and quantity. Before calculating, identify what one row represents. Counting rows only counts orders if each row really is one order.

Quantitative data records counts or measurements: 3 items or a delivery time of 42 minutes. Qualitative data records categories or descriptions: a product color or the comment “the app froze at checkout.” Digits alone do not decide the type. A postal code identifies an area; averaging postal codes would not describe a meaningful average location.

Turn records into an insight

Data analysis collects, transforms and organizes data to draw conclusions, make predictions and support decisions. Its useful result is an insight, an understanding that helps someone act. A table of shoe returns is data; learning that most returns of one model concern sizes that run small is an insight that can guide a size-chart change.

Data analytics names the broader field of processes, tools and techniques for managing, exploring and using data. Analysis is the work on a particular question within that field. The words often overlap in job descriptions, so use the surrounding task to understand what someone means.

Data science often uses statistics, programming and machine learning to model what is unknown. An analyst might investigate which product lines lost customers last quarter. A data scientist might build a model estimating which current customers will leave next month. These are typical tasks, and the fields overlap; job titles do not create a fixed boundary.

Follow the ecosystem around the table

A data ecosystem combines people, hardware and software. In a hospital, lab instruments produce results, databases store them, analysts build reports and clinicians use them. A failure in any part can affect what the report means: a missing instrument feed can look like a fall in test activity.

The cloud provides storage and software on remote servers reached over the internet. It lets teams work with shared data from several locations. Shared access still needs controls over who may see or change information.

Data is a record of what was captured, including gaps and mistakes. No sales on a public holiday could mean the shop was closed. Check how and when records were collected before interpreting an empty or zero value as a statement about demand.

The same dataset can support several kinds of questions. The four common types of analytics separate a summary of events, an investigation of reasons, an estimate of what comes next and a choice of action. Identify the question before selecting a method.

Match the question to the output

Gartner popularized this four-type model. The types involve different demands, but a question is not improved just by choosing a more complex type.

Descriptive analytics summarizes past or current data. An online store shipped 12,400 orders in March and 11,480 in February. The increase is 920 orders. Dividing 920 by 11,480 gives about 0.080, or 8%. That describes the change without explaining its cause.

Diagnostic analytics breaks the result into groups and compares them. Splitting those orders by sales channel shows that nearly all the growth came through a new social-media campaign, while returning-customer orders stayed flat. This narrows the investigation. A pattern linked to a campaign still needs checks before the campaign is named as the proven cause.

Predictive analytics uses past patterns to estimate future or unknown values. “About 13,000 orders in April, probably between 12,000 and 14,000” communicates a forecast and its uncertainty. A prediction is an estimate, so a manager should not treat the central value as a guaranteed total.

Prescriptive analytics compares actions against a goal and practical limits. Expected April orders can help a manager decide how many temporary staff to schedule, alongside staff availability and capacity. A recommendation can use descriptive, diagnostic or predictive work and known conditions; it does not require a forecasting model in every case.

Follow one situation through all four

A bike-share program records 52,000 rentals in May and 41,600 in June. The fall is 10,400 rentals, or 20% of May's total: this is descriptive. A comparison by day links most of the fall to June's 14 rainy days: this is diagnostic work. A forecast using similar weather and last July's pattern is predictive. Scheduling repairs for forecast rainy days, when fewer bikes are needed outside, is prescriptive.

Before reporting rain as the cause, investigate other changes such as a fare increase or a bike-lane closure. Choosing a useful analytics type and judging the strength of the evidence are separate decisions. A reliable total can answer a manager's question completely; an elaborate forecast built on poor records cannot repair those records.

A decision is data-driven when evidence from analysis changes or guides the choice. Collecting figures after a decision merely to defend it does not give the evidence that role. The first question is what the decision-maker needs to choose, followed by what evidence could change that choice.

Give the decision a common yardstick

Data can show what is happening, compare options on the same basis and make the effect of a decision measurable afterward. Library staff may believe that “hardly anyone comes in the evening.” If entrance records show 18% of weekly visits happen after 6 p.m., cutting evening hours has a larger effect than their impression suggests.

The measure needs to match the aim. If a call center rewards short calls alone, staff can lower average call length by ending calls before problems are solved. The number improves while service gets worse. Ask what the measure leaves out and whether people can improve it without improving the outcome the organization cares about.

Combine evidence with knowledge of the work

A subject-matter expert understands a field or process through experience. A warehouse supervisor can explain why an apparent jump in dispatch time occurred during a stock move. An analyst brings the pattern; the expert supplies context, identifies impossible values and suggests explanations to check.

Some organizations call this balance data-informed decision-making: evidence is a major input alongside experience, ethics and context. Human judgment is still needed to decide what matters and what trade-offs are acceptable.

Gut instinct is an intuitive judgment made without conscious reasoning. It can provide a starting idea, such as “customers leave because of our prices.” Turn that hunch into a question the data can examine, for example how cancellation rates changed around the last price change. Also seek evidence that would challenge the hunch, because a familiar explanation can feel stronger than it is.

Let evidence change a proposal

A gym chain considers closing its smallest club. The initial idea is that a small club must matter least. Records show that its members visit more often than members of any other club and that 70% have never used another club in the chain. Those findings suggest many could cancel instead of moving. The chain chooses to keep the club and review the decision next year.

Check who is represented before generalizing. A delivery-area decision based on app orders misses customers who order by phone. Incomplete, old or biased data can direct resources away from the people the decision affects. Fairness requires examining both whose data is present and who could be disadvantaged by the recommendation.

The analyst gives stakeholders clear evidence and explains its limits. The manager, client or board usually owns the decision. A forecast of likely cancellations helps that judgment only when the uncertainty is visible; presenting it as certain would hide part of the choice.

The data life cycle follows data over its whole existence. The Google certificate teaches six stages: plan, capture, manage, analyze, archive and destroy. An online store's order records show why each stage needs attention even after a report is finished.

Plan and capture

During plan, decide what to collect, how it will be collected and managed, who is responsible and how long it will be kept. The store chooses order number, date, items, quantity, amount paid and delivery postal code. The operations team takes responsibility for these records.

During capture, data enters the system. A completed checkout writes an order record to a database. Other sources could be a survey, a sensor or a file received from another organization. Capture concerns acquiring records, not yet drawing conclusions from them.

Manage and analyze

During manage, keep data accurate, available and protected. Choose suitable storage, control access, maintain the records and back them up. For example, customer addresses may be visible only to customer-service staff, with the order database backed up each night.

During analyze, use data to answer questions and support decisions. An analyst might review a year of orders to identify the products returned most often. The same order data could later support a different analysis of delivery times; one dataset can serve many projects.

Keep records or remove them

During archive, move records out of everyday use into long-term storage so they can still be found. An archive preserves records for future reference. A backup is a copy used to restore data after loss or damage. The reason for keeping them differs: an old invoice archive and last night's recovery copy serve different needs.

During destroy, permanently remove data with no remaining purpose and no rule requiring its retention. A retention policy sets how long each kind is kept. Privacy rules can require deletion of personal data that is no longer needed; accounting rules can require some records to be kept for a minimum period. The applicable purpose and rules determine the period, so there is no universal retention time for every dataset.

Secure destruction makes data unrecoverable using an appropriate method, such as securely wiping or physically destroying storage. Moving a file to a recycle bin is not secure destruction.

Connect the life cycle to projects

The stages do not happen just once across the whole organization. New orders are captured while older records are analyzed, archived or destroyed. A missing field discovered during analysis can lead to a revised collection plan.

A six-phase analysis project follows the work needed to answer a question. It can touch several life-cycle stages: gathering survey responses captures data, while storing and documenting a cleaned dataset manages it. Finishing the project does not end the dataset's life.

Stage names vary because organizations use models for different purposes. A research agency emphasizes preserving and sharing reusable data; an analysis team emphasizes answering a question and putting the answer to work. Compare what happens at a stage before deciding that two models disagree.

Recognize the USGS life-cycle model

The U.S. Geological Survey (USGS) uses plan, acquire, process, analyze, preserve and publish/share. Three activities continue across all stages:

• Describe: create and update metadata and documentation.
• Manage quality: check that data is collected, handled and used reliably.
• Back up and secure: protect it from loss and unauthorized access.

Metadata explains a dataset: who collected it, when, how, what its columns mean and which units they use. A column called “temp” is unclear without this information. It might mean temperature in degrees Celsius, temperature in another unit or a temporary value. Documentation makes reuse possible without guessing.

The USGS model ends with publishing and sharing because scientific data can be useful to other researchers. Its emphasis differs from a life cycle that explicitly names destruction. Neither set of headings removes the need to care for records across their existence.

Compare analysis project models

OpenStax's data science cycle names five activities: problem definition, data collection, data preparation, data analysis and data reporting. They broadly match defining a task, obtaining records, cleaning them, finding an answer and communicating it.

CRISP-DM, short for Cross-Industry Standard Process for Data Mining, was developed by a group of companies in the late 1990s. It names business understanding, data understanding, data preparation, modeling, evaluation and deployment. Modeling can build predictive models or descriptive ones, such as groups of customers with similar characteristics. A project that only summarizes records may not need a separate model-building task.

The six phases ask, prepare, process, analyze, share and act overlap with these models. Ask resembles problem definition or business understanding. Prepare and process overlap with collection, understanding and preparation. Analyze overlaps with analysis or modeling and evaluation. Share concerns reporting, while act concerns putting results into practice. The mapping is approximate: OpenStax does not name a separate act phase, and CRISP-DM gives evaluation explicit space.

Use a model as a shared checklist

A circle or a sequence in a diagram does not force work to proceed without revision. A missing month discovered during analysis sends the team back to find data. A result may change the business question. Use the team's model so stage names have a shared meaning, and explain the activity when speaking to someone who uses a different framework.

An analysis project begins with a decision to support and ends with action and follow-up. The Google certificate's six phases, ask, prepare, process, analyze, share and act, make that work visible. Each phase hands a concrete product to the next.

Know what each phase produces

For a chain of three bakeries, the owner starts with “Help us reduce bread waste.” Ask turns this into a task about waste at each shop on each weekday. Prepare identifies production logs and sales records. Process fixes checked errors and records those changes. Analyze calculates waste rates and weekday patterns. Share explains the important pattern to the owner. Act puts an approved baking trial into practice and measures its effect.

The phases are connected by their products. A chart needs trustworthy findings. Findings need clean, relevant data. Relevant data is defined by a clear task. Choosing a tool first can reverse that logic: an attractive chart may answer a question nobody needed answered.

Return to the phase that resolves the problem

The phases form a loop. Suppose analysis reveals that a shop's records are absent for one week. Go back to prepare to locate them, then process and analyze the completed dataset. If “waste” means different things to the owner and shop managers, return to ask to agree on the measure before comparing results.

Returning to a phase is part of the process. It does not mean starting every task from the beginning. Keep the source description and cleaning log so revisions can be traced and later work can use the corrected inputs.

Plan for work beyond calculations

Preparing and cleaning data often take more time than calculating and charting it. A schedule needs room to locate sources, resolve missing records and check unusual values. It also needs time for stakeholders to understand the findings and decide what to do.

An analyst's work continues after a presentation. The owner may need help planning the trial, and the new results need the same measure as the starting results. If waste falls but shelves empty too early, that outcome becomes the next question. One project can involve planning, capturing, managing and analyzing data, while the data itself continues through its longer life cycle.

“Look into our bread waste” is a starting request, but it does not yet specify what an answer should enable. The ask phase turns that request into a clear business task. The prepare phase then finds the data needed to answer it.

Agree on the task and the people affected

A stakeholder can have invested time, money or responsibility, influence the project, or be affected by its outcome. In the bakery case, the owner decides baking quantities, shop managers implement changes and customers can be affected if bread runs out. Their interests are related but not identical.

Ask what problem must be solved, who will use the answer, what decision they will make, what success looks like and when the answer is needed. Confirm the goal with the person responsible for the decision. A manager might want less waste, while customers also need bread available until closing.

The business task becomes: “Find how much bread each shop throws away and on which weekdays, so the owner can adjust daily baking quantities and cut waste without shops running out before closing.” It names a measurable issue, the required breakdown and the decision it supports. “Is the bakery doing well?” needs a definition of “well” before analysis can answer it.

Find records that fit the task

The analyst needs two sources for the last four weeks: production logs for loaves baked and the point-of-sale system for loaves sold, by shop and day. Three shops over 28 days give 84 shop-days. This expected coverage provides a practical check: an absent day is a gap to investigate, not automatically a day with zero production.

Data collected by the bakery itself is first-party data. A supermarket partner's own bread-sales records, shared directly with the bakery, are second-party data. Market data obtained from an outside aggregator that did not collect it directly is third-party data. These labels describe the source relationship; they do not prove quality. More distance from original collection can make records harder to verify.

Check before relying on a source

Check whether the records cover every place and period needed, are current, and could be biased by how they were collected. Check that privacy rules and licenses allow this use. Shop C's production log is missing day 17. Record that gap during preparation so it can be resolved and documented during processing.

Collect the fields that serve the task. Customer addresses do not help calculate shop-level bread waste from daily totals. Extra fields create more cleaning work and can expose personal information without adding an answer. A source list should explain where the records came from, the period they cover and any gaps still awaiting resolution.

The bakery's two source systems do not automatically make a reliable analysis table. Process makes the records usable and traceable. Analyze then uses the checked records to answer how much waste occurs, where it occurs and on which days.

Clean with a record of changes

Processing finds and fixes errors, removes confirmed duplicates, handles missing values and makes formats such as dates, units and shop names consistent. Check the cleaned data against its sources. Keep a cleaning log explaining what changed, why and how.

Two confirmed duplicate entries for shop A on day 9 are removed and logged. Shop C's missing baked count on day 17 is filled from the oven schedule after checking with the manager, and that source is logged. A row showing 130 sold and 120 baked needs investigation: it could be an entry error or bread from another source. Guessing a replacement would create an unsupported value.

Calculate waste for each shop

The waste rate measures the share of production that went unsold:

For A, subtract 3,780 from 4,200 to get 420, then divide by 4,200 to get 0.10. Shop C has both the largest waste count and the highest rate, so it deserves closer investigation.

The chain rate uses the totals: 1,155 divided by 10,500 is 11%. The simple average of 10%, 5% and 20% is about 11.7%, which gives every shop equal weight despite different production volumes. The total-based rate answers what share of all the chain's loaves was wasted.

Break the result down by weekday

Shop C's eight Mondays and Tuesdays account for 800 baked and 520 sold. Subtract to get 280 wasted, then divide by 800 to get 35%. On its other 20 days, 2,000 baked and 1,720 sold also give 280 wasted, but the rate is 14%. Equal waste counts can therefore conceal different production patterns.

This identifies where and when the problem is concentrated. It does not establish why. The manager suggests fewer office workers pass the shop early in the week; that explanation needs confirmation. Report it separately from the measured weekday pattern.

A finding becomes useful when the right people understand it and can choose an action. Share communicates the answer and its limits. Act puts a decision into practice and collects the evidence needed to judge its effect.

Start with the answer the audience needs

The owner needs the key numbers and a recommendation on one page. A shop manager needs that shop's weekday pattern. A reviewing analyst needs the source description and cleaning log. Tailor the detail to the decision or review each person must make.

An owner-facing summary could read: “Over four weeks, the chain wasted 1,155 of 10,500 loaves, or 11%. Shop C produced 560 wasted loaves, about 48% of chain waste. Half of C's waste occurred on Mondays and Tuesdays, when 35% of its bread went unsold.” A few clear charts can support this message; showing every exploratory chart can hide it.

A finding describes evidence: “Shop C wastes 20% of its bread.” A recommendation proposes action: “Reduce shop C's baking on Mondays and Tuesdays.” Label them clearly so a proposal is not mistaken for an observed result.

Make the recommendation testable

A specific proposal is a four-week trial with 30% fewer loaves baked on Mondays and Tuesdays at shop C. The starting total for those days is 800 loaves. A 30% reduction is 240, leaving 560. If sales remain at 520, only 40 would go unsold on those days.

Keep the other days at 2,000 baked and 1,720 sold. For the whole trial, projected production is 2,560 and sales remain 2,240. Waste would be 320 loaves:

This is a projection under a sales assumption, not a measured outcome. Success is a waste rate below 15%, with bread sold out before closing on no more than one day a week. The second measure prevents lower waste from disguising poor availability.

Put the change into practice and follow it

The owner decides whether to approve the trial. The analyst can help plan the change and provide a weekly waste report. Shop C's team changes production and records what happens, including early sellouts.

Share relevant limits: the starting evidence covers four weeks, and one day's missing value was recovered from the oven schedule. These details affect how confidently the owner can generalize the pattern. Hiding them would make the evidence look stronger than it is.

After the trial, analyze the new records with the same waste-rate calculation and check availability. If waste improves but bread sells out too early, the next analysis asks how to balance the two outcomes. Follow-up gives the next round of ask, prepare and analysis a concrete starting point.

Analytical skills help you solve problems using facts. The Google certificate groups five skills as curiosity, understanding context, a technical mindset, data design and data strategy. They develop through practice, and they support the work across an entire project.

Ask and understand

Curiosity leads you to follow up on a surprising result. If returns of a product double, ask what changed: the supplier, the size chart or the product photo. The increase is the starting observation. Curiosity turns it into further questions that could explain it.

Understanding context means knowing where, when, how and why the data was collected. A rise in umbrella sales during a rainy week means something different from a rise during a store-wide discount. Context also includes missing parts: a regional total needs a check that every store was included.

To apply these skills together, first notice the unusual result, then ask about the conditions around it. A conversation with someone who knows the work can reveal a change the table itself does not record. That explanation still needs evidence before it becomes a conclusion.

Break the problem into steps

A technical mindset is an organized way of solving a problem. Suppose website sign-ups fall. Check whether fewer people visited, whether fewer visitors reached the sign-up page and whether fewer of those who reached it completed the form. Each check narrows where the fall occurred.

This mindset is different from knowing many software features. Randomly trying spreadsheet functions does not create a logical investigation. Someone working through the same stages on paper can show a strong technical mindset before learning the software.

Organize the information and the work

Data design concerns the structure of information. An order can contain several products, so one useful structure is a row per order line with separate columns for order number, date, product and quantity. The repeated order number connects lines belonging to the same order. A cell containing all of a customer's purchases as free text would be harder to total or update reliably.

Data strategy concerns the people, processes and tools used in analysis. A team might agree that sales records load into a shared database each night, name who maintains the load and decide that analysts work from that shared source. This avoids separate private copies that drift apart.

Data design makes the records workable; data strategy makes the team’s use of them organized. A well-structured table can still be misused if nobody knows which version is current. A shared process can still struggle if quantities and product names are mixed in one field.

Analytical thinking means defining a problem and solving it with data in an organized way. Five aspects help guide that thinking: visualization, strategy, problem orientation, correlation, and big-picture and detail-oriented thinking. They work together as habits, not as five steps completed once.

See a pattern and keep it relevant

Visualization represents information graphically, using a chart, map or diagram. A line chart of 365 daily website-visit totals can reveal a weekly rhythm that is difficult to see in a long table. The chart supports the investigation by making a pattern visible.

Strategy keeps the intended result in view. If the goal is to understand falling sign-ups, an interesting pattern in product colors may not deserve investigation. Decide which next step helps answer the business task and which would send the work away from it.

Problem orientation starts from the problem that needs solving. Having a large dataset is not by itself a reason to calculate every possible measure. First identify the decision or difficulty, then ask how a proposed calculation or chart helps address it.

Separate a relationship from a cause

Correlation means two variables tend to change together. In a positive relationship, both tend to rise or fall together. In a negative relationship, one tends to rise as the other falls. Neither direction proves that one variable causes the other.

Over a year, ice cream sales and clinic-treated sunburn cases rise and fall together. Hot, sunny days increase both. Weather is a confounding variable, a third factor influencing the two variables. Restricting ice cream sales would not address the cause of sunburn shown by this explanation.

A diagnostic pattern helps identify candidate causes. It does not remove the need to examine other explanations. Before acting on an apparent relationship, ask what changed around both variables and what evidence could distinguish the competing accounts.

Move between the whole and the detail

Big-picture thinking places a problem within the larger goals and situation. Detail-oriented thinking examines the particular facts that could explain it. A product that seems to vanish from a monthly report is a broad result. A retyped product code can split its records into two labels and explain that result.

An analyst can move through this example in both directions. The business question establishes why the missing product matters. A close check of codes and source rows tests whether it really disappeared. Correcting a confirmed labeling issue can then change the wider report.

A symptom shows that something is wrong. A root cause explains the underlying reason it happens. Structured questions help you follow evidence from the visible problem to a supported cause, while gap analysis shows how far a current result is from a target.

Follow a chain of whys with evidence

The five whys technique starts with a problem and asks why it happened. Each answer becomes the next question. Check each answer against records or observations before building another explanation on it. Five rounds is a guide; the evidence determines how far the chain needs to go.

Consider late deliveries:

1. Deliveries arrive late because drivers leave the depot late.
2. Drivers leave late because vans are loaded late.
3. Loading is late because orders reach the warehouse only after 10 a.m.
4. Orders arrive then because the system sends the morning's orders in one batch at 9:45 a.m.
5. That batch time remains from a period when there were far fewer orders.

Departure times, loading records and system timestamps can test this account. The supported underlying problem is an outdated batch schedule. Sending orders continuously or in several morning batches addresses it. Telling drivers to hurry would leave the delayed order flow in place.

Do not stop just because an early answer suggests something easy to change. Equally, do not invent a fifth reason when the evidence supports a shorter chain. The aim is to reach a supported underlying cause and choose an action that addresses it.

Measure the gap to a target

Gap analysis names the current state, the desired state and changes that can bridge them. A clinic currently answers 82% of calls within two minutes and wants to reach 95%. The difference is 13 percentage points:

A percentage-point difference subtracts the two percentages. A relative percentage increase compares the change with the starting rate:

Calling the gap “13%” confuses those two measures. To plan improvement, the clinic also needs to investigate the process behind unanswered or delayed calls. The gap itself measures the shortfall; it does not identify its cause.

Test the first explanation

Confirmation bias is the tendency to notice and believe evidence that supports an existing view. If you begin with “the drivers are careless,” you may notice the late departures and overlook the delayed order batch. Decide what evidence would change your mind and actively look for it.

Useful questions include “What did we not consider?” and “Where are the gaps in the process?” They help broaden the investigation without replacing evidence. A convincing story and a measurable shortfall are useful starting points, but the proposed change should follow the cause the records support.

Data teams divide work according to what needs to be built, understood and communicated. Job titles vary between organizations, so the responsibilities and outputs provide a more reliable guide than the title alone.

Connect systems, tables and answers

A data engineer builds and maintains pipelines, databases and data warehouses. Pipelines move data from sources to where it is needed. A data warehouse combines cleaned data from multiple sources for analysis and reporting. Reliable arrivals and storage let others work from a dependable base.

An analytics engineer turns raw warehouse data into clean, documented tables that analysts can query. A data architect designs the overall structure of the organization's data systems. A data steward looks after quality, shared definitions and access rules. These responsibilities address different layers of the same ecosystem.

A data analyst collects, cleans, investigates and presents data to answer specific questions. Reports, charts and recommendations are common outputs. Marketing analyst, operations analyst and healthcare analyst name areas in which this work is applied.

Make ongoing reports and models useful

A business intelligence (BI) analyst or developer builds and maintains recurring reports and dashboards. The output gives people continuing access to figures, such as sales by region every Monday. A data analyst may also build a dashboard; the distinction is a typical focus, not an exclusive permission to do the task.

A data scientist uses statistics, programming and machine learning to build models of outcomes or complex patterns and designs experiments to test changes. A machine learning engineer puts models into working software and keeps them running. Building a model and operating it reliably are related responsibilities with different practical demands.

Follow the handoffs in one question

A streaming service wants to understand cancellations. The data engineer brings billing and viewing records into the warehouse daily. The data analyst finds that cancellations are highest after a price change and among people who watch less than two hours a month. The BI developer adds cancellations to the weekly dashboard. The data scientist builds a model estimating which subscribers are likely to cancel.

The analyst discusses the pattern with stakeholders and subject-matter experts. Clear questions and plain explanations matter because the decision-makers must understand both the finding and what it cannot establish. A correlation after a price change is evidence to investigate, not automatic proof of the cause.

In a small organization one person may do several of these jobs; a larger organization may separate them into teams. Across all roles, people must protect personal information, use it for appropriate purposes and check whether conclusions or actions unfairly disadvantage groups.

Spreadsheets make a table visible and easy to explore. SQL retrieves data from relational databases. Many projects use SQL to select a manageable result and a spreadsheet to investigate it, so choosing one does not exclude the other.

Read a sheet and its calculations

A spreadsheet such as Excel, Google Sheets or LibreOffice Calc stores values in cells. Columns have letters and rows have numbers: B2 is column B, row 2. A range such as B2:B4 includes B2, B3 and B4.

A formula starts with an equals sign and calculates a value. A function is a named, ready-made calculation such as SUM, AVERAGE, COUNT, MIN or MAX. =SUM(B2:B4) adds three cells. References let formulas recalculate when input values change.

Put the bakery's shops A, B and C in rows 2–4, baked counts in B and sold counts in C. In D2, =B2-C2 gives A's 420 wasted loaves from 4,200 baked and 3,780 sold. In E2, =D2/B2 gives 0.1; percentage formatting displays 10%. =SUM(B2:B4) gives the chain's 10,500 baked loaves.

Sorting orders rows by a field, such as waste from highest to lowest. Filtering displays matching rows, such as only shop C. A pivot table groups and summarizes records, such as total waste for each shop and weekday.

Read a simple SQL query

A relational database stores tables linked through shared fields such as a customer number. SQL, Structured Query Language, requests and manages data in these systems. A query is a written request:

SELECT shop, baked, sold
FROM daily_sales
WHERE shop = 'C';

SELECT names the returned columns. FROM names the table. WHERE keeps only rows meeting the condition. This query returns shop, baked and sold for shop C, and only reads the table; it does not change the stored records.

Database systems use SQL dialects, including PostgreSQL, MySQL, SQL Server, SQLite and BigQuery. Core commands are shared, while functions and details can differ.

Choose according to the work

A spreadsheet suits a small or medium dataset, a quick one-time calculation and an audience comfortable with files. SQL suits existing database data, large tables and recurring questions. An Excel sheet has at most 1,048,576 rows and 16,384 columns; a Google Sheets file has at most 20 million cells. Files may become slow before reaching a limit.

Manual copying and overwriting can be hard to repeat or audit. Sheet protection, permissions and validation can reduce errors. A relational database adds structured columns, types and rules for shared records. Both need careful use; their structures and controls differ.

The right tool depends on the task, the data and the people who need the result. Business intelligence tools make figures accessible over time. Python and R let analysts write repeatable processing and analysis steps, including work too large for a spreadsheet.

Give people an ongoing view

BI and visualization tools such as Tableau, Power BI and Looker Studio connect to spreadsheets, databases and cloud services. They turn records into interactive charts and dashboards. A dashboard brings key figures and charts together on one screen to monitor a situation.

Freshness depends on the connection and refresh process. A dashboard using imported data may show yesterday's values until a scheduled or manual refresh succeeds. A live connection can query current source data, but the displayed view may also need updating. Check freshness before interpreting the displayed number.

A sales dashboard refreshed each morning can let managers filter by region, product and date themselves. It suits a repeated question shared by many people. Building a new one-off presentation each morning would require the analyst to repeat work that the dashboard can provide.

Repeat complex work with code

Python is a general-purpose programming language used for software, automation and machine learning as well as analysis. Libraries such as pandas handle tables and Matplotlib makes charts. R was designed for statistics and graphics; ggplot2 and the tidyverse are common additions, and RStudio is a common environment for using it.

Both languages can load, clean, analyze and visualize data. A script can be run on fresh input without repeating manual edits. A notebook, such as Jupyter, combines code, output and explanatory text in one document.

Reproducibility means someone else can repeat the analysis and obtain the same result. Code helps by recording its steps, but a shared script is not enough if the analyst also changed data manually. Include every processing step, the input data, software versions and settings needed for the run.

Build a suitable tool chain

For a manager's one-time regional sales question from a 2,000-row export, a spreadsheet pivot table can be enough. For a team's weekly figures from a database, SQL feeding a BI dashboard supports a recurring need. For 40 million sensor readings cleaned and modeled every month, Python or R can support processing at scale, with SQL extracting records where needed.

Ask where the data lives, how large it is, how often the work repeats, who will use the output, whether others must check it and what the organization supports. A complicated tool cannot compensate for an unclear question or unreliable records.

AI assistants can suggest formulas, queries or summaries in many tools. Check a suggestion against the data and understand what it does before relying on it; a convincing-looking output can still use the wrong field, filter or calculation.