Featuretools Cheat Sheet

1Install & the idea1.31

pip install featuretools import featuretools as ft★
Add featuretools[dask] / [spark] for distributed compute.
# DFS = aggregation primitives (across relationships) # + transform primitives (within a row/table), stacked★
The mental model: aggregations summarize child rows up to a parent (a customer's MEAN(transactions.amount)); transforms derive within a table (MONTH(timestamp)).
es = ft.demo.load_mock_customer(return_entityset=True)
A ready-made multi-table EntitySet for experimenting.

2EntitySet & dataframesregister tables

es = ft.EntitySet(id="shop")★
The container that holds your tables and their relationships.
es = es.add_dataframe( dataframe_name="transactions", dataframe=tx_df, index="transaction_id", time_index="timestamp")★
Each table needs a unique index. Set time_index for temporal data — it's what makes cutoff times / leakage-safety work.
add_dataframe(..., logical_types={"zip": "Categorical", "age": "Integer"})★
Types drive which primitives apply. Woodwork logical types (Categorical, Integer, Double, Datetime, EmailAddress...) are inferred but overridable.
add_dataframe(..., make_index=True) # create a synthetic index
Use when a table has no natural unique key.

3Relationshipsparent → child

es = es.add_relationship("customers", "customer_id", "transactions", "customer_id")★
Order is (parent_df, parent_key, child_df, child_key) — one parent row, many child rows. The parent key must be that table's index.
es.add_relationships([rel1, rel2, ...])
Chain multiple relationships to model a full schema (customers → sessions → transactions).
es · es.plot() · es["transactions"]★
Print/plot the schema to sanity-check; index into a table's DataFrame.
DFS follows relationshipskey
Aggregation features only exist along declared relationships — no relationship, no cross-table features. Model the schema completely.

4dfs — the core callDeep Feature Synthesis

fm, defs = ft.dfs(entityset=es, target_dataframe_name="customers")★
The core call. Returns the feature matrix (one row per target entity) and the feature definitions (reusable recipes). Target = the table you're predicting on.
ft.dfs(..., agg_primitives=["sum","mean","count","std","mode"], trans_primitives=["month","weekday","time_since_previous"])★
Choose which primitives to use — the biggest lever on what features you get (and how many).
ft.dfs(dataframes={"a": (df_a, "id")}, relationships=[...], target_dataframe_name="a") # skip explicit EntitySet
Pass raw dataframes + relationships directly for a quick one-shot.
ft.dfs(..., features_only=True) # get defs without computing
Inspect what would be generated before the (potentially expensive) computation.

5Primitivesthe building blocks

ft.list_primitives() # all available, with type & description★
Browse the catalog. Filter by type (aggregation/transform).
# aggregation: Sum, Mean, Count, Max, Min, Std, Mode, NumUnique, Trend, Skew★
Summarize child rows to the parent — the cross-table power of DFS.
# transform: Month, Weekday, Hour, TimeSincePrevious, CumSum, Diff, Absolute★
Derive new columns within a table (esp. datetime features).
ft.dfs(..., groupby_trans_primitives=["cum_sum"])
Windowed transforms grouped by a key (running totals per customer). Write custom primitives by subclassing.

6Depth & stackingcontrol the explosion

ft.dfs(..., max_depth=2)★
Depth = how many primitives stack. Depth 2 gives things like MEAN(sessions.COUNT(transactions)). Higher = exponentially more (and slower) features.
ft.dfs(..., max_features=100)
Cap the count. Combine with primitive selection to keep it manageable.
ft.dfs(..., primitive_options={...}, ignore_columns={...})
Fine-grained control: which columns/primitives to include or exclude per table.
ft.graph_feature(defs[10]) # visualize how a feature was built
Every synthesized feature is explainable — trace its primitive stack.

7Cutoff times (no leakage)temporal correctness

fm, defs = ft.dfs(entityset=es, target_dataframe_name="customers", cutoff_time=cutoff_df) # columns: instance id, time★
The killer feature: only data before each row's cutoff time is used — so features never peek into the future. Essential for time-series ML.
cutoff_df = pd.DataFrame({"customer_id": ids, "time": label_times})
One cutoff per prediction point — typically the moment you'd make the prediction in production.
ft.dfs(..., training_window="30 days")
Restrict aggregations to a window before the cutoff (e.g. last-30-days behavior).

8Reuse & select featuresproduction

fm_new = ft.calculate_feature_matrix(features=defs, entityset=es_new, cutoff_time=new_cutoffs)★
Apply the same feature definitions to new data — the train/serve consistency guarantee. Compute once at train, reuse at inference.
ft.save_features(defs, "features.json") defs = ft.load_features("features.json")★
Persist feature definitions to disk — version them like code.
fm_enc, defs_enc = ft.encode_features(fm, defs) # one-hot categoricals
Prepare for sklearn. Then prune with selection.remove_highly_correlated_features / remove_low_information_features.

!Common gotchasread before shipping

set time_index + cutoff_time for temporal data
Without them, DFS uses all rows — leaking future data into training features. This is the most important correctness rule.
max_depth explodes feature count
Depth 3+ can generate thousands of features & run for hours. Start at depth 2, restrict primitives, then expand.
every table needs a unique index
And relationship parent keys must be that table's index. Wrong keys silently produce empty aggregations.
logical types drive primitives
A numeric id typed as Integer gets summed/averaged nonsensically — type ids as Categorical so DFS treats them as keys.
reuse defs, don't re-run dfs
At inference, use calculate_feature_matrix with saved defs so features match training exactly.

Featuretools cheat sheet