Skip to navigation
Code ExamplesWorkflows & SolutionsGrowth Marketing

Feature Adoption Prediction

View as Markdown

Solution Background and Business Value

Modern software platforms continuously release new capabilities to enhance customer value. Predicting early feature adoption lets businesses focus marketing and sales on high-intent users, personalize outreach, and accelerate time-to-value.

However, tracking adoption across features and identifying likely adopters is complex. It requires processing large volumes of telemetry data, interpreting diverse customer behaviors, and keeping pace with frequent feature releases. Kumo is purpose-built for this challenge: its graph-based learning and rich feature engineering uncover patterns in telemetry data that traditional rule-based or static models miss.

This example shows how to train a multi-label classification model that predicts whether a user will adopt a set of pre-defined features within the next N days.

Data Requirements and Schema

To build an effective feature adoption prediction model, you need structured data capturing relevant user and feature information. The minimum required data is described below, but adding more telemetry tables and attributes improves model accuracy.

This example uses two core tables (a users table and a product success table) plus any number of telemetry tables. Each row in the users table represents an entity the model predicts over. Each row in the product success table represents the first time a user adopted a feature. Telemetry tables supply the model with behavioral signals for each user.

Core Tables:

  1. Users: one row per user

    • user_id: unique user identifier
    • Optional: region, age, demographics, or other user attributes

  2. Product Success: one row per first-adoption event

    • Only the first adoption of each feature per user is tracked
    • success_id: unique success identifier
    • date_of_success: date the user first adopted the feature
    • user_id: the user who adopted the feature
    • feature: name of the feature
    • use_case: how the feature was used
    • Optional: additional feature attributes

  3. User Telemetry Tables: add as many as available

    • More telemetry tables increase model accuracy
    • Examples: user dimensions, sessions, transactions
    • Required: user_id to link back to the users table

Entity Relationship Diagram (ERD):

PRODUCT_SUCCESS PK INT success_id TIMESTAMP date_of_success FK INT user_id STRING feature STRING use_case USERS PK INT user_id SESSIONS PK INT session_id FK INT user_id TIMESTAMP create_date TRANSACTIONS PK INT transaction_id FK INT user_id FLOAT price USER_DIMS TIMESTAMP DATE FK INT user_id INT company_size has telemetry table telemetry table telemetry table

Multi-label Classification vs. Binary Classification

There are two main ways to train a feature adoption prediction model.

Binary classification trains a separate model for each feature. Each model outputs whether a user will adopt that specific feature.

Multi-label classification predicts adoption of several features in a single model. This lets the model detect signals across features simultaneously, which can improve accuracy. It also eliminates the need to train and maintain a separate model per feature, reducing the effort required to bring the solution into production.

Predictive Query

The following predictive query creates the training table for a multi-label classification model. It predicts whether a user will adopt any of the top K features within the next N days. Replace N with your prediction horizon (for example, 30 for 30 days) and K with the maximum number of features to predict per user.

PREDICT LIST_DISTINCT(product_success.feature, 0, N, DAYS)
CLASSIFY TOP K
FOR EACH users.user_id