SardineCon SF/2026

Learn More
Detection & metrics4 min de leitura

O que é Feature?

SUBSCRIBE

A feature is an input variable built from raw data and fed to a model or rule, such as transaction speed, device age, or how well a name matches an account. Feature quality and freshness drive detection performance more than the choice of algorithm, so most real modeling work is building good features.

What is a feature, in plain English?

A feature is a single, computed input that a model or rule looks at to make a decision. Raw data on its own, a timestamp, an IP address, a name string, is rarely useful. A feature turns that raw data into something predictive: the number of transactions in the last hour, the age of the device in days, the string similarity between the typed name and the account name.

Some features are simple lookups; many are aggregations over a window, like count, sum, average, or maximum over the last hour, day, or thirty days. Others are ratios and comparisons, such as this amount versus the customer's usual amount. Each one is a lens that makes a particular kind of risk visible to the model.

In the detection stack features are the raw material. A model or rule is only as good as the features feeding it, which is why teams talk about feature engineering as the core craft and treat the algorithm choice as secondary.

How a feature is built and used

A feature travels a path from raw event to live decision, and the same definition has to hold at every step or the model quietly degrades.

  1. Source — Raw data lands. An event arrives: a transaction, a login, a device signal, a name and account pair.
  2. Engineer — Compute the feature. Turn raw data into a variable: a velocity count, a device age, a name-match score.
  3. Train — Feed the model. The feature becomes one of many inputs the model learns from on historical labeled data.
  4. Serve — Score in real time. The same feature is computed live at decision time and must match the training definition exactly.

What it looks like in practice

In practice

A team adds a feature called "distinct cards seen on this device in seven days." In backtesting it is a star: it separates fraud from good traffic almost perfectly, and the model's scores jump. The team is ready to ship.

A reviewer catches that the seven-day window in training was computed with full hindsight, including cards that appeared after the transaction being scored. Live, the feature can only see the past, so its real value is far weaker. That is leakage: the feature secretly encoded the answer in testing and would have quietly underperformed in production.

Why features beat algorithms

Swapping in a fancier model usually buys a small, one-time lift. A well-designed feature that captures a real fraud behavior can move detection far more, because it gives the model something genuinely new to see. That is why experienced teams spend their time on features, freshness, and coverage rather than chasing the newest algorithm.

The flip side is that features are where the subtle failures live. Leakage makes a feature look brilliant offline and useless online. Features drift or go stale as behavior changes. And training-versus-serving mismatch, where the feature is computed one way in the lab and another way in production, degrades the model with no obvious alarm. Watching that parity closely is part of running any serious detection system.

What to watch in the data

  • Leakage. A feature that looks too good in testing often encodes the answer or uses future information it cannot see live.
  • Training-serving skew. The same feature computed differently offline and online silently erodes accuracy; check the definitions match exactly.
  • Staleness. Features that stop updating, or that rely on a source that has gone quiet, drift away from reality without throwing an error.
  • Coverage gaps. A feature that is null for a big slice of traffic gives the model nothing to work with on those cases.
  • Distribution shift. When a feature's values drift over time, its learned relationship to fraud may no longer hold, a common driver of model drift.

Quick questions

Is a feature the same as a signal?

In everyday use they overlap. A signal is any piece of evidence; a feature is that evidence turned into a concrete input variable for a model or rule. Most teams use the words loosely and interchangeably.

What is feature leakage?

Leakage is when a feature accidentally contains information about the outcome it is supposed to predict, often future data. It makes offline results look excellent and then fails live, so it is one of the most damaging and common mistakes.

Why does feature freshness matter so much?

Fraud behavior moves quickly, so a feature computed on stale data describes a world that no longer exists. Fresh, correctly windowed features are what let a model track current behavior.

Can rules use features too?

Yes. A rule like "block if velocity in the last hour exceeds a threshold" is just a feature plus a cutoff. Features feed both models and rules; they are not model-only.

What is training-serving skew?

It is when a feature is computed one way during training and a different way at serving time. The model was tuned on one definition and sees another in production, so it quietly gets worse with no alarm.

Go deeper

O que saber junto com Feature