Data Mining for Business Analytics: A Practical Guide

Open Google Analytics 4 and try to compare this month against the same month three years ago at the event level. You cannot. A standard GA4 property stores event-level data for either 2 or 14 months, the longer option is a setting somebody has to go and change, and everything past the window is deleted rather than archived. No model recovers it. That radio button kills more analytics projects than any choice of algorithm. The hard part is almost never the mathematics.

Data mining for business analytics is the part of the job that has a name. It applies statistics and machine learning to large datasets to surface patterns a person would not find by eye, then points the result at a decision someone is going to make. What follows is the workflow, the techniques worth recognizing with the mistake each one invites, and every Google service in the stack rechecked against vendor documentation and pricing pages on 13 August 2026. Prices and limits move; the ones below carry the date they were read.

Data mining and business analytics: the method and the purpose

The two terms overlap enough that people swap them freely, and the swap costs money, because they answer to different owners.

• Data mining is the method: discovering patterns in data through clustering, classification, association rules, and the rest of the toolbox.
• Business analytics is the purpose: using data, often mined, to understand what happened, why, and what to do next in service of a goal somebody is accountable for.

Business analytics using data mining means aiming pattern-discovery methods at commercial questions. Which customers are about to churn. Which products sell together. Which channel drives revenue rather than merely appearing before it in the log. Analytics splits into three levels, and mining feeds all of them:

Every vendor deck draws those three as a maturity ladder, and they are not one. A prescriptive model on an unaudited dataset is worth less than a clean weekly report people trust.

For background, see what data mining is and how it differs from machine learning and the neighboring vocabulary.

Start from the decision, not from the data

Most failed analytics projects are technically fine. They answer a question nobody had. Four questions filter out most of them before anyone touches a dataset. What decision changes based on the answer? Who acts on it, and how often? What does being wrong cost in each direction, given that false positives and false negatives almost never cost the same? What would you do differently tomorrow?

The last one has arithmetic behind it. Take 100,000 subscribers and 3% monthly churn, so 3,000 leavers a month. A churn model flags 5,000 accounts and 900 of them genuinely would have left: precision 18%, recall 30%, respectable for a first attempt. Now attach the retention offer. At $30 per flagged account you have spent $150,000. If it saves a third of the people who would have gone, that is 300 customers at $200 of annual margin each, or $60,000. The model works and the program loses $90,000 a year.

None of that is fixed by better features. It is fixed by a $12 offer, by contacting only the top decile, or by not running the program. Precision is a business parameter wearing a statistics costume.

CRISP-DM: the workflow everybody cites

Most data mining projects follow some version of the CRISP-DM cycle, worth knowing because it prevents the classic failure of building a good model that answers the wrong question.

1. Business understanding. Define the decision the analysis supports. "Reduce churn" is a goal; "predict which subscribers cancel next month" is a data mining task; the four questions above sit here.
2. Data understanding. Gather and explore the raw material: internal databases, analytics exports, third-party feeds, and web data you collect yourself.
3. Data preparation. Clean, deduplicate, normalize, join. See data cleaning and data normalization.
4. Modeling. Apply the techniques below to find patterns or train a predictor.
5. Evaluation. Test whether the model answers the business question and generalizes to data it has not seen.
6. Deployment. Put the insight to work as a dashboard, an alert, or a pricing rule, then monitor it.

The numbering misleads people, and IBM's documentation, which hosts the reference guide inside the SPSS Modeler help, says so plainly: "The sequence of the phases is not strict. In fact, most projects move back and forth between phases as necessary." Deployment routinely sends you back to business understanding, because the first thing a live model exposes is the ambiguity in the original question.

A note on the model's own health. CRISP-DM gets called the industry standard everywhere, and the phrase does unearned work. The domain it was published under, crisp-dm.org, did not answer when checked on 13 August 2026, and the special interest group that was going to produce a version 2.0 never shipped one. What survives is a twenty-five-year-old vocabulary kept alive by the vendors who embedded it in their products. Useful, and not an actively governed standard.

The number this article used to quote was wrong. Earlier versions said data preparation is 60 to 80% of the work, simultaneously the most repeated figure in the field and the least supported. Leigh Dodds went looking for the source in 2020 and found no survey that says it. CrowdFlower's 2016 survey reached 60% for cleaning and organizing, and touches 80% only if you fold data collection in; its 2017 edition put the whole group at 51%. Kaggle's 2018 survey, which asked people to allocate time rather than rank annoyances, came out near 11% gathering and 15% cleaning. Preparation is still the largest single block of work in most projects, and planning as though it were two thirds of the year sets budgets wrong in both directions.

The techniques, and the mistake each one invites

You do not need to implement any of these yourself. You do need to recognize which one a question calls for, and what it will quietly do to you.

• Classification assigns records to categories: spam or not, will churn or will not, fraud or ordinary. Its standing trap is the base rate. At 3% monthly churn, a model that predicts "nobody churns" is 97% accurate and worthless. Accuracy is the wrong headline metric for any imbalanced problem, and almost every interesting business problem is imbalanced. Ask for precision and recall at the threshold you will actually run.
• Regression predicts a continuous value: next month's demand, a lifetime value, a delivery time. Easy to evaluate badly, by reporting error on the rows you fit.
• Clustering groups similar records with no labels, which is how customer segments get built. See clustering in data mining for the mechanics. The trap is that clustering always succeeds. Ask k-means for six segments and you get six segments, whether or not your customers come in six kinds. Rescale one variable and the segments move. Before showing clusters to anyone, check they survive a re-run on a different sample.
• Association-rule mining finds items that co-occur, the classic market-basket analysis, and the source of the most repeated anecdote in the field. The story says a retailer found beer and diapers selling together, moved them side by side, and watched sales jump. Daniel Power traced it and The Register published the reconstruction in August 2006. The analysis was real: run in 1992 by a Teradata team under Thomas Blischok over roughly 1.2 million baskets from Osco Drug, and it did show the two co-purchased between 5pm and 7pm. The rest is invention. No age or gender correlation was established, and the chain does not appear to have moved the products. Keep the technique and drop the story, then watch the metric you rank on: confidence alone hands you rules about whatever you sell most of, so rank on lift.
• Anomaly detection flags the unusual: fraud, outages, a competitor's sudden price move. Its failure mode is alert fatigue, a product problem rather than a modeling one.
• Text mining pulls structure and sentiment out of reviews, tickets, and open survey fields. Language models made the extraction close to free and did nothing about the sampling problem: the people who write reviews are the tail of your customers, not your customers.

Where the data comes from, including the web

Analytics is only as good as its inputs, and the inputs that change a decision usually sit outside your own systems: competitor prices, catalogs, marketplace listings, reviews, public registers. Internal data tells you what your own bubble did. It cannot tell you whether you lost share because your prices moved or everyone else's did.

Some of it needs no collecting. Google Dataset Search indexes datasets published with structured metadata across government, academic, and commercial sources, and it is the least known of Google's analytics-adjacent services.

The rest is a web scraping problem, and collection is the easy quarter of it. Keeping a feed clean, deduplicated, matched to your own SKUs, and refreshed on schedule is what consumes a team. That is where the build-or-buy line falls: a one-off extract is a script, a live external dataset is an operations commitment. If it is not your team's job, our data as a service offering delivers analysis-ready datasets on a schedule, competitor price monitoring covers rival pricing specifically, and sites that fight collection are where a managed extraction service earns its keep.

Public does not mean unregulated, and one case gets cited backwards constantly. hiQ Labs v. LinkedIn is quoted everywhere for the proposition that scraping public data is legal. Both Ninth Circuit rulings were preliminary-injunction decisions about likelihood of success. On the merits hiQ lost. LinkedIn won summary judgment on breach of contract in November 2022, and that December hiQ accepted a $500,000 judgment and a permanent injunction barring it from scraping LinkedIn at all. Separately, the GDPR does not care whether personal data was public when you collected it. Neither point stops external data collection. Both change what you should collect, and both belong in the business understanding phase rather than in a lawyer's inbox later.

Google services for business analytics, checked in August 2026

Several of Google's tools are still the default rungs of a business analytics stack. Here is what is current, with real limits attached, and the dead ones named.

Google Trends: a sampled index, not a search count

Google Trends shows relative search interest for a term over time and geography, and compares several terms at once. For analytics it is a fast read on demand and seasonality, and a sanity check on whether a market is growing before you commit budget.

Read Google's own FAQ before you put a Trends number in a board deck. The service states that "only a sample of Google searches are used in Google Trends." Each data point is divided by total searches for its geography and time range, then "scaled on a range of 0 to 100." Low-volume terms "appear as '0.'" And the data carries "statistical noise that includes small and random fluctuations that don't represent actual search behavior." A Trends value of 40 is therefore not forty of anything. It is a proportion of a proportion, sampled, rescaled, and floored at zero for anything niche. A term reading 0 may still have thousands of monthly searches.

Google announced a Trends API in alpha in July 2025, the first supported route to the data after two decades of people scraping the CSV export. That announcement page does not render for automated readers, so confirm access terms yourself.

Google Search Console: three months by default, 25,000 rows by API

Formerly Google Webmaster Tools, Search Console reports the queries that bring people to your site, with impressions, click-through rate, and average position. It connects what people search for to what they do on arrival.

The Performance report opens on the last three months, and the interface is the wrong tool past the first hundred rows. The Search Analytics API takes a rowLimit between 1 and 25,000, against a default of 1,000. Its documentation is unusually frank: the API "does not guarantee to return all data rows but rather top ones." Rare queries are dropped for privacy before you see them, so summing query rows never reconciles with total clicks.

The escape hatch is bulk data export to BigQuery, which writes searchdata_site_impression, searchdata_url_impression, and an ExportLog table once per day, retained forever by default. It is how you build a query history longer than the interface will show, and it only starts accumulating from the day you switch it on.

Google Analytics 4: the retention clock runs on your raw data

Google Analytics 4 is the current generation of Google's web and app analytics: an event-based model covering interactions, acquisition channels, conversions, and funnels, with explorations for slicing behavior by segment. Universal Analytics is gone rather than deprecated, and the retired-tools list below has the dates.

The detail that shapes every GA4 analysis is retention. Standard properties choose 2 or 14 months for event data; Analytics 360 properties choose 2, 14, 26, 38, or 50. Google's documentation on data retention draws the line precisely: "the data retention setting does not affect standard aggregated reports (including primary and secondary dimensions) in your Google Analytics property, even if you create comparisons in the reports. The data retention setting only affects explorations and funnel reports."

That sentence settles an argument that happens in every analytics team. Your year-over-year sessions chart still works, because standard reports read pre-aggregated tables. Your exploration of what those sessions did stops dead at the retention boundary, because explorations read event-level data that has been deleted. When a standard property crosses into Google's "Large" tier, retention drops to 2 months automatically and older data is, in Google's phrasing, permanently deleted. Growth silently shortens your memory.

BigQuery: where the mining becomes literal

When your questions outgrow a dashboard, BigQuery is Google Cloud's serverless warehouse. GA4 exports raw events into it, so you can run SQL over billions of rows and join web behavior against sales data. Prices read from Google's BigQuery pricing page on 13 August 2026, US multi-region:

Storage untouched for 90 consecutive days drops to the long-term rate automatically, roughly half price, with no action from you. Editions pricing swaps on-demand billing for reserved capacity, which pays off once your monthly scan volume is large and predictable.

BigQuery ML trains models where the data already sits. The documentation lists linear and logistic regression, k-means, matrix factorization, principal component analysis, and the ARIMA_PLUS and TimesFM time-series families as trained inside BigQuery, with deep neural networks, boosted trees, random forests, and AutoML trained externally, plus imported ONNX, TensorFlow, and XGBoost models.

Check the price line before falling in love with the convenience. Creating a built-in model is billed at $312.50 per TiB, fifty times the $6.25 that evaluation and prediction cost. A training query scanning 500 GiB is about $152; the same scan for prediction is about $3. Filter your training set into a materialized table first, and never point a CREATE MODEL statement at a raw events export.

Looker Studio: free, and $9 when it is not

Formerly Data Studio, Looker Studio turns those sources into shareable dashboards, connecting to GA4, Search Console, BigQuery, Sheets, and hundreds of third-party sources. Google's own page says it is "available at no charge for creators and report viewers." Looker Studio Pro is $9 per user per project per month and buys Cloud support and customer-managed encryption keys.

OpenRefine: the tool that stopped being Google's and stayed alive

The tool once called Google Refine is now the community-maintained, BSD-3-Clause OpenRefine. It handles the unglamorous half of every project: clustering near-duplicate values, splitting and reconciling messy columns, enriching records against external references. That is exactly the shape of scraped data and public government datasets.

It is genuinely maintained, which you cannot say about most tools with a decade of history. Version 3.10.0 landed on 26 February 2026 and 3.10.1 on 4 March 2026, the latter described in its release notes as "identical to 3.10.0 in every way except that the Mac build is notarized." Its old companion Freebase is long gone; reconciliation moved to Wikidata.

Retired, and still listed in other people's guides

• Google Correlate, which found search terms whose curves matched a real-world time series, was shut down on 15 December 2019, and nothing replaced it.
• Google Optimize and Optimize 360 are, in Google's words, "no longer available as of September 30, 2023." Google pointed users at AB Tasty, Optimizely, and VWO and opened its APIs so any testing tool can integrate with Analytics. The free A/B rung of this stack no longer exists.
• Universal Analytics stopped processing data on 1 July 2023 for standard properties and 1 July 2024 for 360. The historical data went with it.

What breaks at scale

A demo pulls a thousand rows through an API and looks fine. Production pulls the same data hourly across forty properties for two years, and every number below becomes a constraint.

The GA4 export cap is a ceiling, not a throttle. Standard properties have a daily BigQuery export limit of 1 million events; Analytics 360 properties go to 20 billion. A busy retail site passes a million on a promotion day without anyone noticing until that day's table is missing, and the remedy Google offers is filtering events out of the export first. Streaming export, for same-day data, costs $0.05 per gigabyte, and Google puts a gigabyte at roughly 600,000 events.

There is no re-export. Google's documentation is blunt: "Once you export data from Analytics to BigQuery, you cannot re-export it." The export produces rows from the day you enable it. Turn it on for every property you own, today, whether or not you have a use for the data yet. An unused export costs a few dollars of storage. A missing one costs a year of history that does not exist.

The reporting API has a budget, and it is smaller than it looks. The Analytics Data API quotas give a standard property 200,000 core tokens per day, 40,000 per hour, and 10 concurrent requests, against 2,000,000, 400,000, and 50 for Analytics 360. Tokens are consumed by query complexity rather than request count, so one request with four dimensions and a wide date range can cost what fifty simple ones do.

High-cardinality dimensions get eaten by (other). When a report exceeds its row limit, GA4 keeps the common dimension values and folds the rest into a single (other) bucket. Google's guidance is that "any dimension with more than 500 values should be considered a high-cardinality dimension," which covers page paths, product IDs, search terms, and most custom dimensions worth having. The exact per-report row limits are not published. That is a real boundary of knowledge: from outside you cannot predict when (other) appears, only detect it afterwards. The raw export is the only place the long tail survives intact.

The scan bill compounds quietly. On-demand BigQuery bills what a query reads, not what it returns, and SELECT * reads everything. A 200 GiB events table scanned in full by an hourly dashboard refresh is about 4.7 TiB a day, roughly $29 a day, near $890 a month, from one dashboard. The free 1 TiB monthly allowance covers about five hours of that. Partition on date, cluster on the columns you filter, and materialize what the dashboard reads.

Where data mining stops working

Your measuring instrument changes under you. The canonical demonstration is Google's own. Google Flu Trends inferred influenza prevalence from search queries, was briefly the poster child for big data, and then drifted. The Parable of Google Flu: Traps in Big Data Analysis ran in Science on 14 March 2014. Lazer, Kennedy, King, and Vespignani reported that Google Flu Trends "overestimated the prevalence of flu in the 2012-2013 season and overshot the actual level in 2011-2012 by more than 50%." Worse, "from 21 August 2011 to 1 September 2013, GFT reported overly high flu prevalence 100 out of 108 weeks." Their diagnosis names two causes. One is "big data hubris," the assumption that big data substitutes for traditional collection. The other is algorithm dynamics: Google kept improving its search product, and each change altered the data the model was reading.

That failure mode is not historical. Every long GA4 trend line partly measures Google's own product decisions: consent requirements, modeled conversions, changed session definitions, cookie policies. Before you explain a shift in the data, check whether what changed was the world or the meter.

Correlation still does not survive contact with intervention. Mining tells you that customers who use feature X churn less. It cannot tell you that pushing everyone toward feature X reduces churn, because the people who found X may simply be the engaged ones. Only an experiment settles that, and with Optimize retired you now pay for a testing tool or build server-side assignment yourself. Without it, predictive work quietly becomes a description of the customers you already have.

Aggregates lie in a specific, repeatable way. A metric can move up in every segment and down in total, purely because the mix of segments changed. Any headline number that surprises you deserves a split by channel, device, and geography first.

Most business questions are not modeling questions. A well-written query against clean data answers more of them than any classifier will. Reach for prediction when the question is genuinely about the future, not because a model looks better in a deck than a table.

Putting it together

A workable stack in 2026 is unremarkable, and that is its virtue. Collect from GA4, Search Console, your own databases, and external web data. Warehouse and prepare in BigQuery and OpenRefine. Mine with SQL, BigQuery ML, or a notebook. Act through dashboards, alerts, and scoring rules.

Then check whether you need any of it. Everything above assumes volume most companies do not have. A year of GA4 events for a mid-sized site exports to a few gigabytes of Parquet. DuckDB 1.5.5, released 22 July 2026 under the MIT license, runs the same SQL over those files on a laptop. No cloud bill, no scan charge. scikit-learn 1.9.0, released June 2026, covers every technique named above. The warehouse earns its place when the data stops fitting on one machine, or when several teams need the same governed copy.

The tools rotate. Correlate is gone, Universal Analytics is gone, Optimize is gone, Data Studio became Looker Studio, Google Refine became OpenRefine and outlived its parent. The shape of the work has not moved in twenty-five years: understand the decision, get the data clean, choose the smallest technique that answers the question, and check what your instrument was doing while you were reading it.

Start from the decision. Everything downstream is arithmetic.