Feature

Catching spam accounts used to mean writing the conditions down by hand. At Pagedeck, Theo stacked up rules like "lock the account if it creates more than 50 documents on day one." By the twelfth rule, legitimate accounts were getting caught, and every exception he added let more spam slip through. As long as a person picks the conditions, that tug of war never ends.

So the job shifts: instead of a person choosing the conditions, the data finds them. That's supervised learning — hand over records with the answer already attached and let the program work out where the boundary sits. But handing them over turned out to be the hard part, because there is no way to pass "this account" to a program. An account is a signup timestamp, a list of documents, an invitation history and a login trail, all tangled together, and none of it can be read as is.

What a program can work with is numbers sitting in fixed positions. So one account gets rewritten as a handful of numbers: days since signup, average documents created per day, people invited, share of links pointing outside the workspace. Each of those rewritten values is a feature. The program now searches for the conditions, but a person still decides what material it gets to search through.

Rewrite each record as the same fixed set of values and the whole dataset becomes one table with rows and columns. A row is one account; a column is one feature. If the training data holds 48,000 accounts, the table has 48,000 rows, and the columns usually number in the dozens to the low hundreds.

The values come in three shapes.

1. Numbers — days since signup, average documents per day, anything already usable as a quantity.
2. Categories — the plan name, the signup channel, anything naming a kind rather than an amount. These get split into columns like "is on the free plan," holding 0 or 1, because a program reads any number as a magnitude. Encode free, team and enterprise as 1, 2 and 3 and the table now claims enterprise is three times free.
3. Derived — values calculated from things the raw record never stored. Divide documents by active days for a daily average, or divide this week's logins by last week's for a trend.

How a value is framed matters as much as which one you pick. Swap average documents per day for cumulative documents and every healthy team in its second year gets pushed toward the spam side. They have many documents because they've been around a while, but the table only shows a large number.

One mistake deserves its own warning: never use a value that isn't knowable at the moment of prediction. Put "date the account was suspended" in a column and training accuracy jumps to 99 percent, because only suspended accounts have a value there and the model is copying the answer. On a brand new account that column is empty and the model has nothing. A model that only performs on the data it learned from is overfitting, and here the cause sits in the table rather than in the model.

The first place is model building. On a classification task like spam or not spam, where the answer is one of a fixed set of buckets, which columns go in moves the score more than which algorithm does. Swapping models might lift precision and recall by two points while adding a single column for invitations sent lifts it by eight. Precision is the share of flagged accounts that really were spam; recall is the share of real spam that got flagged. Both depend on the quality of the material.

They stay in view after the model ships. Model drift, the slow decay of a model's accuracy over time, usually starts with these values rather than with the model. Launch a new feature that pushes the average documents per day across all accounts from 3 to 9, and a model trained around 3 hasn't changed — the world has. So monitoring covers the distribution of the inputs, not only the predictions coming out.

Product teams inherit work from this too. A column can only hold something that was recorded, so the moment Mia decides which actions get logged, she has already fixed what material a model will have months later. If "clicked the invite button" was never logged, that column can't be built, and starting to log it today leaves it blank for the 48,000 records already collected.

"Before we swap models, let's take another look at the features."

Reworking the inputs is a better bet for the score than changing the algorithm.

"You can't use that one — the value only exists after suspension."

It isn't knowable at prediction time, so it inflates the training score and nothing else.

"Building that feature means logging something new, so it's two months out."

The record it needs doesn't exist yet, which makes collection the prerequisite.

When Pagedeck started flagging spam, Theo and Mia stood at a whiteboard. Theo asked Mia to say everything she knew about how spam accounts differed from real ones, and she rattled off more than a dozen things. They create documents but never open them. They invite nobody but paste a lot of links. They use the product hard for a day and vanish. Theo went down the list asking which of them could be written as a number, and the eight that survived became the first table's columns.

It's easy to assume more columns make a better model. More information leads to better judgment, which holds for people, so the assumption is natural. In practice, every column unrelated to the answer gives the model another place to find a coincidence. Among 48,000 records, accounts that signed up around 3 a.m. happened to include a few more spam accounts, and that coincidence hardens into a rule. Left alone, the training score climbs while real accounts get judged worse, and the team burns weeks looking for the problem inside the model. Before adding a column, be able to say in one line why that value relates to the answer.

The other mistake is treating this as technical work the data person handles alone. They write the code that builds the table, so it looks that way. But deciding what belongs in a column comes from whoever knows the product. Nothing in the data says spam accounts don't send invitations — that lives in the head of someone who has been looking at accounts every day. Skip that step and the team builds a table out of a few obvious values, then spends months cycling through models wondering why the score won't move.