Training a Model on Spreadsheet Data Without Writing Code

A no-code AutoML tool will train a genuinely competent model on a spreadsheet in about fifteen minutes, and for a large class of problems that model is good enough to act on. Knowing exactly where it stops being good enough is the difference between using the tool well and being surprised by it in production.

A dataset you can actually download

Use the Bank Marketing dataset created by S. Moro, P. Rita and P. Cortez and hosted by the UCI Machine Learning Repository, introduced in their 2014 Decision Support Systems paper on predicting the success of bank telemarketing. The repository lists 45,211 instances and 16 features, and ships several variants: a bank-additional-full.csv with 41,188 examples and 20 inputs, and 10% samples of each for faster experimentation. The target, y, records whether the client subscribed a term deposit.

It is a good teaching dataset for this specifically because it is realistic in the ways that break naive workflows: mixed numeric and categorical columns, a heavily imbalanced target, and — in the full variant — at least one column that leaks. Start with the 10% sample so a full pass takes minutes, and compute the positive rate yourself as the first thing you do, because every metric below is read relative to it.

Preparing the sheet

Almost all of the work is here, and none of it requires code.

1. One header row, one row per record, no merged cells. No blank spacer rows, no subtotal rows, no notes in the margin. Anything a human added for readability is a parsing failure. If the sheet has a title block above the headers, delete it.
2. Delete the leaking column. In the additional variants, duration is the call length in seconds, and the repository’s own documentation warns that it is not known before a call is performed and that it should be discarded for a realistic predictive model — a call that lasted eleven minutes almost certainly ended in a subscription. This is the single most important step on the page and no tool will do it for you, because the tool cannot know what is available at prediction time. The general test is in detecting target leakage.
3. Fix the types before upload. Ensure dates are real dates and numbers do not carry currency symbols or thousands separators, and make sure any identifier column is either removed or explicitly excluded. Most no-code tools infer types with the cascade described in automatic column type detection, and they inherit all of its failure modes.
4. Export as CSV with UTF-8 encoding. This resolves most of the mysterious import errors, and it also prevents the spreadsheet’s display formatting from being mistaken for the underlying values.

The training path

Every no-code platform — the AutoML features in the major cloud consoles, spreadsheet-native prediction add-ons, standalone drag-and-drop tools — presents the same five decisions, so the path generalises even though the buttons differ.

1. Upload and confirm the inferred types. Do not skip this screen. This is where you catch the postcode read as an integer and the identifier read as a feature.
2. Choose the target column and the problem type. With y as a two-value column, this is binary classification. If the tool offers a positive class, set it to yes explicitly rather than accepting alphabetical order.
3. Set the split. Take the random split only if the rows are genuinely exchangeable. This dataset is a campaign over time, so a random split lets the model see later calls while predicting earlier ones — the reason a time-ordered split is the honest choice here, and the wider topic of tabular cross-validation strategies.
4. Set the training budget and start. The tool searches over model families and hyperparameters; a longer budget searches more. Diminishing returns arrive quickly on a dataset this size.
5. Read the evaluation, then export. Both the model and the preprocessing recipe. A model without its recipe cannot be reproduced, and the recipe is the part you will need when the tool is outgrown.

Reading the result honestly

The evaluation screen is where no-code tools most reliably mislead, because their headline metric is accuracy.

On an imbalanced target, accuracy is close to meaningless: a model that predicts “no” on every row scores whatever the negative rate happens to be, and on this dataset that is a number high enough to look like success. Ignore it and read precision, recall and precision-recall AUC for the positive class, and read the confusion matrix as counts rather than percentages so that “recall 0.34” becomes a specific number of missed customers. If the tool exposes a decision threshold, that is the control worth spending time on — the reasoning is in imbalanced classification with gradient boosting, and it applies identically whether or not you wrote the code.

Then apply the one check that catches most disasters: if a metric looks excellent, assume leakage until proven otherwise. Look at the feature importance list the tool produces, find the top feature, and ask whether its value is genuinely known at the moment you would need the prediction. If duration was left in, it will be at the top and the model will look superb.

Where the no-code path breaks

The limit is not really row count — most tools ingest hundreds of thousands of rows without complaint, and the row-count ceilings that do exist are product limits that move. The real limits are four things these tools structurally cannot do, and they start to bind as soon as the problem stops being a single flat table.

• Feature engineering across tables. The strongest predictor is usually something like “number of contacts in the previous 90 days”, which requires a windowed aggregation over a second table. No-code tools take one flat file, so that feature has to be built before upload — and building it is exactly the code you were avoiding.
• A validation scheme that matches the data. Grouped splits so that the same customer cannot appear on both sides, nested cross-validation so that selection is not scored on its own validation set, time-series splits that respect a gap between train and test. Most tools offer random and sometimes chronological, and nothing else.
• Anything that must be reproducible or audited. A hosted model behind a UI is difficult to version, to diff, to retrain deterministically, or to explain to a reviewer twelve months later. If the model informs a lending, hiring, medical or other regulated decision, that is a hard stop rather than an inconvenience, and the requirement is a documented, reviewable pipeline with human accountability — not a faster tool.
• Deployment on your terms. The exported artefact may be in a format only that platform serves, and latency, cost per prediction and data residency are then the vendor’s decisions rather than yours.

None of that argues against starting here. A no-code baseline in fifteen minutes tells you whether the signal exists at all, which is the question worth answering before anybody writes a pipeline. Treat it as the fastest available answer to “is this predictable”, and move to code when the answer is yes and the four limits above start to bind.