Tuning Deep Feature Synthesis#

There are several parameters that can be tuned to change the output of DFS. We’ll explore these parameters using the following transactions EntitySet.

[1]:
import featuretools as ft

es = ft.demo.load_mock_customer(return_entityset=True)
es
[1]:
Entityset: transactions
  DataFrames:
    transactions [Rows: 500, Columns: 6]
    products [Rows: 5, Columns: 3]
    sessions [Rows: 35, Columns: 5]
    customers [Rows: 5, Columns: 5]
  Relationships:
    transactions.product_id -> products.product_id
    transactions.session_id -> sessions.session_id
    sessions.customer_id -> customers.customer_id

Using “Seed Features”#

Seed features are manually defined and problem specific features that a user provides to DFS. Deep Feature Synthesis will then automatically stack new features on top of these features when it can.

By using seed features, we can include domain specific knowledge in feature engineering automation. For the seed feature below, the domain knowlege may be that, for a specific retailer, a transaction above $125 would be considered an expensive purchase.

[2]:
expensive_purchase = ft.Feature(es["transactions"].ww["amount"]) > 125

feature_matrix, feature_defs = ft.dfs(
    entityset=es,
    target_dataframe_name="customers",
    agg_primitives=["percent_true"],
    seed_features=[expensive_purchase],
)
feature_matrix[["PERCENT_TRUE(transactions.amount > 125)"]]
[2]:
PERCENT_TRUE(transactions.amount > 125)
customer_id
5 0.227848
4 0.220183
1 0.119048
3 0.182796
2 0.129032

We can now see that the PERCENT_TRUE primitive was automatically applied to the boolean expensive_purchase feature from the transactions table. The feature produced as a result can be understood as the percentage of transactions for a customer that are considered expensive.

Add “interesting” values to columns#

Sometimes we want to create features that are conditioned on a second value before calculations are performed. We call this extra filter a “where clause”. Where clauses are used in Deep Feature Synthesis by including primitives in the where_primitives parameter to DFS.

By default, where clauses are built using the interesting_values of a column.

Interesting values can be automatically determined and added for each DataFrame in a pandas EntitySet by calling es.add_interesting_values().

Note that Dask and Spark EntitySets cannot have interesting values determined automatically for their DataFrames. For those EntitySets, or when interesting values are already known for columns, the dataframe_name and values parameters can be used to set interesting values for individual columns in a DataFrame in an EntitySet.

[3]:
values_dict = {"device": ["desktop", "mobile", "tablet"]}
es.add_interesting_values(dataframe_name="sessions", values=values_dict)

Interesting values are stored in the DataFrame’s Woodwork typing information.

[4]:
es["sessions"].ww.columns["device"].metadata
[4]:
{'dataframe_name': 'sessions',
 'entityset_id': 'transactions',
 'interesting_values': ['desktop', 'mobile', 'tablet']}

Now that interesting values are set for the device column in the sessions table, we can specify the aggregation primitives for which we want where clauses using the where_primitives parameter to DFS.

[5]:
feature_matrix, feature_defs = ft.dfs(
    entityset=es,
    target_dataframe_name="customers",
    agg_primitives=["count", "avg_time_between"],
    where_primitives=["count", "avg_time_between"],
    trans_primitives=[],
)
feature_matrix
[5]:
zip_code AVG_TIME_BETWEEN(sessions.session_start) COUNT(sessions) AVG_TIME_BETWEEN(transactions.transaction_time) COUNT(transactions) AVG_TIME_BETWEEN(sessions.session_start WHERE device = tablet) AVG_TIME_BETWEEN(sessions.session_start WHERE device = desktop) AVG_TIME_BETWEEN(sessions.session_start WHERE device = mobile) COUNT(sessions WHERE device = tablet) COUNT(sessions WHERE device = desktop) ... AVG_TIME_BETWEEN(transactions.sessions.session_start) AVG_TIME_BETWEEN(transactions.sessions.session_start WHERE sessions.device = desktop) AVG_TIME_BETWEEN(transactions.sessions.session_start WHERE sessions.device = mobile) AVG_TIME_BETWEEN(transactions.sessions.session_start WHERE sessions.device = tablet) AVG_TIME_BETWEEN(transactions.transaction_time WHERE sessions.device = desktop) AVG_TIME_BETWEEN(transactions.transaction_time WHERE sessions.device = mobile) AVG_TIME_BETWEEN(transactions.transaction_time WHERE sessions.device = tablet) COUNT(transactions WHERE sessions.device = desktop) COUNT(transactions WHERE sessions.device = mobile) COUNT(transactions WHERE sessions.device = tablet)
customer_id
5 60091 5577.000000 6 363.333333 79 NaN 9685.0 13942.500000 1 2 ... 357.500000 345.892857 796.714286 0.000000 376.071429 809.714286 65.000000 29 36 14
4 60091 2516.428571 8 168.518519 109 NaN 4127.5 3336.666667 1 3 ... 163.101852 223.108108 192.500000 0.000000 238.918919 206.250000 65.000000 38 53 18
1 60091 3305.714286 8 192.920000 126 8807.5 7150.0 11570.000000 3 2 ... 185.120000 275.000000 420.727273 419.404762 302.500000 438.454545 442.619048 27 56 43
3 13244 5096.000000 6 287.554348 93 NaN 4745.0 NaN 1 4 ... 276.956522 233.360656 0.000000 0.000000 251.475410 65.000000 65.000000 62 16 15
2 13244 4907.500000 7 328.532609 93 5330.0 6890.0 1690.000000 2 3 ... 320.054348 417.575758 56.333333 197.407407 435.303030 82.333333 226.296296 34 31 28

5 rows × 21 columns

Now, we have several new potentially useful features. Here are two of them that are built off of the where clause “where the device used was a tablet”:

[6]:
feature_matrix[
    [
        "COUNT(sessions WHERE device = tablet)",
        "AVG_TIME_BETWEEN(sessions.session_start WHERE device = tablet)",
    ]
]
[6]:
COUNT(sessions WHERE device = tablet) AVG_TIME_BETWEEN(sessions.session_start WHERE device = tablet)
customer_id
5 1 NaN
4 1 NaN
1 3 8807.5
3 1 NaN
2 2 5330.0

The first geature, COUNT(sessions WHERE device = tablet), can be understood as indicating how many sessions a customer completed on a tablet.

The second feature, AVG_TIME_BETWEEN(sessions.session_start WHERE device = tablet), calculates the time between those sessions.

We can see that customer who only had 0 or 1 sessions on a tablet had NaN values for average time between such sessions.

Encoding categorical features#

Machine learning algorithms typically expect all numeric data or data that has defined numeric representations, like boolean values corresponding to 0 and 1. When Deep Feature Synthesis generates categorical features, we can encode them using Featureools.

[7]:
feature_matrix, feature_defs = ft.dfs(
    entityset=es,
    target_dataframe_name="customers",
    agg_primitives=["mode"],
    trans_primitives=["time_since"],
    max_depth=1,
)

feature_matrix
[7]:
zip_code MODE(sessions.device) TIME_SINCE(birthday) TIME_SINCE(join_date)
customer_id
5 60091 mobile 1.215383e+09 3.958597e+08
4 60091 mobile 5.196041e+08 3.729108e+08
1 60091 mobile 9.007145e+08 3.721668e+08
3 13244 desktop 6.058313e+08 3.619540e+08
2 13244 desktop 1.150497e+09 3.406715e+08

This feature matrix contains 2 columns that are categorical in nature, zip_code and MODE(sessions.device). We can use the feature matrix and feature definitions to encode these categorical values into boolean values. Featuretools offers functionality to apply one hot encoding to the output of DFS.

[8]:
feature_matrix_enc, features_enc = ft.encode_features(feature_matrix, feature_defs)
feature_matrix_enc
[8]:
TIME_SINCE(birthday) TIME_SINCE(join_date) zip_code = 60091 zip_code = 13244 zip_code is unknown MODE(sessions.device) = mobile MODE(sessions.device) = desktop MODE(sessions.device) is unknown
customer_id
5 1.215383e+09 3.958597e+08 True False False True False False
4 5.196041e+08 3.729108e+08 True False False True False False
1 9.007145e+08 3.721668e+08 True False False True False False
3 6.058313e+08 3.619540e+08 False True False False True False
2 1.150497e+09 3.406715e+08 False True False False True False

The returned feature matrix is now encoded in a way that is interpretable to machine learning algorithms. Notice how the columns that did not need encoding are still included. Additionally, we get a new set of feature definitions that contain the encoded values.

[9]:
features_enc
[9]:
[<Feature: zip_code = 60091>,
 <Feature: zip_code = 13244>,
 <Feature: zip_code is unknown>,
 <Feature: MODE(sessions.device) = mobile>,
 <Feature: MODE(sessions.device) = desktop>,
 <Feature: MODE(sessions.device) is unknown>,
 <Feature: TIME_SINCE(birthday)>,
 <Feature: TIME_SINCE(join_date)>]

These features can be used to calculate the same encoded values on new data. For more information on feature engineering in production, read the Deployment guide.