Feature Engineering Basics

By Kokil Thapa | Last reviewed: September 2026

Feature engineering basics decide whether a model works in production or fails quietly after launch. Raw database rows, API payloads, and clickstream logs rarely map directly to what a classifier or regressor needs. You must derive, clean, encode, and time-bound inputs so the model learns signal instead of noise. This guide walks through the process from an application developer's view—where data pipelines meet web systems and where AI features ship inside real products.

What is feature engineering and why does it matter?

Feature engineering is the process of creating input variables that a machine learning model can consume. A model never sees your Laravel Eloquent models or WooCommerce order tables directly. It sees vectors: order count in 30 days, days since last login, product category one-hot columns, or text embeddings from a review field.

Bad features waste compute and produce confident wrong answers. Good features let a simple linear model beat a deep network fed with raw IDs. On client projects where teams integrate LLM APIs or scoring services, I have seen the same pattern repeat. The API call works fine. The business outcome fails because nobody engineered inputs that reflect real user behaviour.

Think of features in three layers:

• Raw fields: timestamps, amounts, categories, free text, device type.
• Derived fields: rolling averages, ratios, binning, interaction terms.
• Encoded fields: one-hot vectors, target encoding, embeddings, normalized numerics.

Your application database holds layer one. Layers two and three belong in a pipeline that training and inference both share. That overlap with feature stores is not accidental. Once feature count grows past a handful, you need versioning and reuse across models.

How do you transform raw application data into ML features?

Start with a prediction target and work backward. If you want to predict cart abandonment, define the label first. Did the user complete checkout within 24 hours? Only then list candidate inputs available before checkout ends.

Step 1: Audit available fields

Export a sample from production or staging. For a Laravel eCommerce system, typical raw columns include user_id, session_id, cart_total, item_count, payment_method, and created_at. Document which fields exist at prediction time versus after the outcome.

Step 2: Define feature specs

Write each feature as a named specification with type, source query, and refresh window. A spec prevents the "works in notebook, breaks in API" problem.

# feature_specs.yaml (example)
features:
  - name: orders_last_30d
    type: integer
    source: orders
    sql: COUNT(*) WHERE user_id = ? AND created_at >= NOW() - INTERVAL 30 DAY
  - name: cart_total_npr
    type: float
    source: carts
    transform: log1p(amount)
  - name: device_is_mobile
    type: boolean
    source: sessions
    transform: user_agent matches mobile pattern

Step 3: Build a reproducible pipeline

Notebook experiments are fine for discovery. Production needs a script or job you can rerun. Python with pandas is the usual choice for batch jobs. PHP can compute simple features at request time when latency allows.

For batch extraction from MySQL 9.7 or PostgreSQL 18:

SELECT
  u.id AS user_id,
  COUNT(o.id) AS orders_last_30d,
  COALESCE(AVG(o.total), 0) AS avg_order_value,
  EXTRACT(DAY FROM NOW() - MAX(o.created_at)) AS days_since_last_order
FROM users u
LEFT JOIN orders o
  ON o.user_id = u.id
  AND o.created_at >= NOW() - INTERVAL '30 days'
GROUP BY u.id;

Validate output with a JSON formatter or schema checker before feeding a model service. Silent type drift—string amounts, null categories—breaks inference fast.

Step 4: Version and test features

Treat feature code like application code. Unit-test edge cases: new users with zero orders, cancelled transactions, timezone boundaries around midnight Nepal time. Add integration tests in your testing pipeline when features feed customer-facing scores.

What are the most common feature engineering techniques?

Most production work uses a small set of patterns. Master these before chasing exotic embeddings.

Numeric transformations

Scale skewed values with log1p or Box-Cox. Bin continuous age or income into buckets when the relationship is non-linear. Clip outliers at the 99th percentile so one Rs 500,000 order does not dominate a florist site's averages.

Categorical encoding

One-hot encoding suits low-cardinality fields like payment_method. High-cardinality product SKUs need target encoding, hashing, or embeddings. Never feed raw UUIDs as integers—the model will memorize noise.

Datetime features

Split timestamps into hour_of_day, day_of_week, is_weekend, and is_festival_season. For Nepal operations, Dashain and Tihar spikes are real signals in booking and retail data. A Nepali date converter helps when source systems store Bikram Sambat strings separately from Gregorian dates.

Text features

For legal-tech intake forms or support tickets, extract length, language, keyword flags, or embedding vectors. Full NLP pipelines belong in a separate service. See natural language processing basics for text-specific steps.

Aggregation and window features

Rolling counts, sums, and ratios over 7/30/90-day windows capture behaviour trends. "Orders in last 7 days divided by orders in last 90 days" often beats a single count for churn models.

How do you avoid data leakage when engineering features?

Data leakage is the fastest way to build a model that looks brilliant offline and fails live. Leakage means your features include information from the future or from the label itself.

Classic mistakes I have seen on production applications:

1. Computing target encoding using the entire dataset including test rows.
2. Including post-checkout fields—payment_status, refund_flag—in a cart abandonment model.
3. Using "days until churn" as a feature when predicting churn.
4. Normalizing with global mean and std that include holdout data.

Fix leakage with strict point-in-time joins. For each training row at time T, aggregate only events where event_time < T. Scikit-learn's preprocessing docs stress fitting transformers on training folds only—a pattern described in the scikit-learn preprocessing guide.

Train-serve skew

Train-serve skew is leakage's sibling. Training uses SQL batch jobs; serving uses PHP at request time with slightly different null handling. The model sees a different distribution and accuracy drops.

Mitigations that work in practice:

• One shared library or SQL template for each feature.
• Golden-file tests comparing batch output vs online output for the same user ID.
• Explicit NULL and default policies documented in the feature spec.

How do you productionize features in a web application?

Production feature engineering sits between your database and your model endpoint. You have two common architectures: batch precompute and online compute.

Batch precompute

A nightly job writes feature rows to a table or Redis 8.10 cache. Inference reads precomputed values at request time. This suits recommendation scores, credit-like risk tiers, or marketing segments on a grocery delivery platform where sub-second latency matters but features can lag by hours.

Online compute

Features are calculated on each API request. Use this when freshness is critical—fraud checks during checkout, dynamic pricing, or session-based prompts. Keep the code path thin. Heavy joins belong in read replicas or materialized views.

Calling external model APIs

When you buy rather than train models, your job is still feature engineering. You assemble JSON payloads, attach metadata, and enforce schema. Prompt fields are features too—document temperature, token limits, and redaction rules under responsible AI governance.

Example Laravel job that prepares features and calls a scoring API:

// app/Jobs/ScoreCartAbandonmentRisk.php
public function handle(ScoringClient $client): void
{
    $cart = Cart::with('items.product.category')->find($this->cartId);

    $features = [
        'item_count'       => $cart->items->count(),
        'cart_total_npr'   => log1p($cart->total),
        'is_mobile'        => $cart->session->is_mobile,
        'hour_local'       => now()->timezone('Asia/Kathmandu')->hour,
        'category_diversity' => $cart->items->pluck('product.category_id')->unique()->count(),
    ];

    $score = $client->predict('cart_abandon_v2', $features);
    $cart->update(['abandon_score' => $score]);
}

Wire this through your queue worker on PHP 8.3+ with Laravel 12 or 13. Log feature payloads in staging only. Never log PII in production unless policy allows it.

Monitoring and drift

Track feature distributions weekly. If avg_order_value suddenly doubles, your scaler may produce out-of-range inputs. Alert on null-rate spikes and schema mismatches. For high-volume catalog sites like florist eCommerce, category cardinality changes when seasonal SKUs arrive—your encoders must handle unseen levels with an explicit "unknown" bucket.

How do feature engineering basics differ from prompt engineering?

They overlap in one sense: both shape inputs to get better outputs. Feature engineering targets structured numeric and categorical vectors for traditional ML models. Prompt engineering targets natural language context for LLMs.

On a legal-tech portal, structured features might score lead quality from form fields and visit patterns. Prompt features might summarize a user's question with retrieved statute snippets. Many 2026 products combine both paths inside an custom application. Read prompt engineering playbook for the LLM side; this article covers the tabular side.

Google's machine learning guidance describes feature creation as the highest-ROI step for many tabular problems—a view echoed in the Google ML crash course. That matches what I see on client work. Teams chase model architecture while ignoring input quality.

Key Takeaways

• Define labels and prediction time first, then engineer only features available before that moment.
• Document every feature in a spec with type, source, transform, and default for nulls.
• Use one shared implementation for training batch jobs and online serving to prevent train-serve skew.
• Fit scalers and encoders on training data only; use time-based splits for evaluation.
• Monitor null rates, cardinality changes, and distribution drift after deployment.
• Start with simple aggregates and encoding; add embeddings only when simpler features plateau.

People Also Ask

What is the difference between feature engineering and feature selection?

Feature engineering creates new inputs from raw data—ratios, bins, encodings, window counts. Feature selection chooses which existing inputs to keep or drop. You usually engineer first, then select to remove redundant or low-importance columns before training.

Do you need feature engineering for deep learning?

Deep networks on raw images or text learn representations internally. Tabular business data—orders, sessions, form fields—still benefits heavily from explicit feature engineering. Most production scoring on web application data uses gradient boosting or logistic regression with engineered columns, not raw IDs.

How many features should a model have?

There is no universal number. Start with 10–30 well-understood features tied to the business question. Add complexity only when validation metrics improve on a time-based holdout. Hundreds of sparse columns increase maintenance cost and leakage risk without guaranteed gain.

Can PHP applications do feature engineering?

Yes. PHP suits online feature computation at request time—aggregations, boolean flags, simple math. Heavy batch transforms and model training usually run in Python jobs triggered by cron, GitLab CI, or queue workers. The split is normal on API-driven systems backed by MySQL or PostgreSQL.

Ship features that models can actually use

Feature engineering basics are not a research exercise. They are the bridge between your application database and any model you call—hosted, vendor, or self-trained. Get point-in-time correctness, shared train-serve logic, and monitoring in place before you tune hyperparameters. That discipline shows up in booking platforms, eCommerce carts, and intake forms alike. If you are adding scoring, recommendations, or automation to an existing product, contact us to review your data pipeline and feature specs, or explore how production booking systems on kokil.com.np handle operational data end to end.