Skip to navigation
User Guide: Kumo StudioConnect Data

Data Preparation Best Practices

View as Markdown

Model quality depends on the information, correctness, and relational structure of the source data. Use this guide before creating a graph or training a predictive query.

Choose informative source data

Start with the raw tables that contain the entities, events, and labels needed for the prediction task. Include business-relevant signals and preserve the relationships between them.

Use this checklist:

  • A source table contains the label needed to generate positive and negative training examples.
  • The data contains enough history to represent the behavior and seasonal patterns relevant to the task.
  • Tables can be connected through stable primary-key and foreign-key relationships.
  • Event rows have timestamps that represent when their information became known.
  • Columns that reveal the future target are excluded.
  • Sensitive data is removed, hashed, or otherwise handled according to your organization’s policies.
  • The resulting graph fits within the documented quotas and limits.

Refer to What columns should I select? and What tables should I link? for more selection guidance.

Prefer raw events over precomputed features

Whenever practical, provide raw entity and event tables instead of pre-aggregated features. For example, provide timestamped login events rather than only a logins_last_30_days column.

Kumo learns from sequences, relationships, and temporal context across the graph. Aggregating the source data too early can remove information the model could otherwise use. Traditional feature engineering is therefore usually unnecessary, although selecting meaningful tables and columns remains important.

If an existing feature store contains useful source signals, refer to How do I use a feature store with Kumo?.

Inspect data quality

Check table and column statistics to confirm that:

  • Column names and values match their intended meaning.
  • Data collection and definitions are consistent across the selected history.
  • Categorical values use consistent spelling, capitalization, and separators.
  • Numeric fields contain numeric values rather than textual placeholders.
  • Duplicate or redundant columns do not represent the same information in different units or formats.
  • Missing values are represented consistently.

For model-related problems, use evaluation and explainability results to look for leakage, unexpected distributions, or entities with poor performance.

Handle missing values

Leave missing fields blank rather than filling them with strings such as N/A, none, or null, or sentinel numbers such as -1. These placeholders can be interpreted as real values.

A column with many missing values can still be useful when the presence or absence of a value is informative. Review its column statistics and business meaning before excluding it. Refer to How does Kumo handle missing values?.

Handle outliers

Do not remove or cap unusual values automatically. First determine whether they are errors, legitimate rare events, or signals associated with new entities and sparse histories.

Graph models can use neighboring entities and relationships when an individual entity has limited history. Correct genuine data errors at the source, but retain valid rare observations unless your evaluation shows that they harm the task.

Preserve graph connectivity when sampling

Independently sampling rows from every table can leave entities without their related histories and break foreign-key coverage.

When a smaller development dataset is necessary, sample around the prediction entity and retain the related rows across all tables. See How can I reduce model training time? for iteration strategies.

Next steps