Encoding categorical columns

Most machine-learning models and a good number of analytics operations cannot work with raw text — they need numeric input. Encoding is the step that converts a categorical column such as priority or region into numbers a model can consume. Dotwave offers two encoding strategies in Step 3, Preprocess, and choosing the right one for each column is one of the more consequential decisions in the pipeline, because a poor encoding can invent relationships in your data that do not exist. This article explains both methods, when each fits, and how Dotwave protects you from high-cardinality mistakes.

Why encoding matters

Algorithms operate on numbers. A regression, a clustering routine, or a tree-based model has no concept of the word "Medium" — it needs a numeric representation before it can compute distances, splits, or coefficients. Several analytics tools share the same constraint. Encoding bridges that gap by mapping each category to a number or set of numbers. The catch is that the mapping you choose tells the algorithm something about the categories, so you want that implied message to be true. The two methods below encode very different assumptions.

Label encoding

Label encoding assigns a single integer to each unique value, ordered alphabetically. Applied to a priority column, Dotwave produces:

• High → 0
• Low → 1
• Medium → 2

The column stays a single column, which keeps your dataset compact. But notice what the numbers imply: the model now reads Medium (2) as "greater than" Low (1), which is greater than High (0). That ordering is imposed by the alphabet, not by meaning, and here it is nonsense. Label encoding is therefore the right tool for ordinal data — values that genuinely have an order, such as sizes, ratings, or education levels — but a trap for nominal data where the categories are arbitrary labels with no rank. Use it when the numeric order matches a real order in the world, and avoid it when it does not.

One-hot encoding

One-hot encoding sidesteps the false-order problem by creating a new binary column for each unique value. A region column with values North, South, and East becomes three 0/1 columns — region_North, region_South, region_East — where exactly one holds a 1 for each row. No category is numerically greater than another, so no phantom ordering is introduced. This makes one-hot encoding the correct choice for nominal data: product types, categories, countries, and any field where the values are simply different rather than ranked.

The cost is width. Every unique value adds a column, so one-hot encoding is unsuitable for high-cardinality fields. Dotwave caps one-hot encoding at 50 unique values to stop a single column from exploding your dataset into hundreds of sparse binary columns.

High cardinality warning

Cardinality is the number of distinct values in a column. When a column exceeds 20 unique values, Dotwave raises a high-cardinality warning, because both encodings become awkward at that point. One-hot encoding a 50-plus-category column would create 50-plus columns — a wide, sparse table that slows training and dilutes signal. The recommended fix is to group rare categories first: fold the long tail of infrequent values into a single "Other" bucket, or consolidate near-duplicates, so the column carries a manageable number of meaningful categories before you encode it.

Work column by column rather than applying one method to everything. Ask of each field whether its categories have a real order — if yes, label encode; if no, one-hot encode, and if the cardinality is high, group first. Every encoding you apply becomes a step in your cleaning recipe and is recorded in the audit trail, so the transformations travel with your data and can be reviewed later.