How your data is prepared

Every segmentation run starts from a prepared dataset: a cleaned, feature-engineered table with one row per customer (often called a customer 360), plus a generated data dictionary that describes every column. Preparation is a transformation, not a cleanup: Neuralift turns raw behavioral and transactional history into an analysis-ready view of every customer, with the measures that make segmentation sharp engineered in. This page explains what happens between the raw tables you sync and that finished table, who does the work, and why the quality of that transformation directly determines the quality of your segments.

From source tables to a customer 360

The output has two parts, and both matter:

• The customer 360 table. One row per customer ID. Its columns are a mix of cleaned source attributes and engineered behavioral features (see Feature engineering examples).
• The data dictionary. A profile of every column in that table, classified as a KPI, continuous, categorical, or ID field, with distribution statistics and descriptions. You review it in the use case’s Data tab; see The data dictionary.

Who does what

Neuralift’s team runs data preparation as part of your engagement. Once your source tables are synced, Neuralift designs the preparation with you, runs it, and the finished data dictionary appears in the use case for you to review. Your role is to have the right data ready (see Data requirements) and to check that the resulting dictionary reflects your business. See Roles & permissions for the full breakdown.

Why good preparation drives good segments

If the segment landscape you’ll later explore is a map of your customer base, preparation is the survey that produces it: the map can only be as faithful as the survey beneath it. The segmentation model finds structure in whatever table it is given, so the table has to describe customers in terms worth segmenting on:

What preparation does	Why segments improve
Aggregates raw history into per-customer behavior (when you provide transaction or event logs)	The model compares customers, not transactions. One row per customer is what makes “groups of customers” possible.
Adds trend and cadence features	Two customers with identical totals can be a grower and a decliner. Without trend features, the model can’t tell them apart.
Normalizes messy values	Placeholder text posing as data (for example “N/A” in a numeric column) would otherwise distort what the model learns.
Drops unusable columns	Constant, empty, and deeply nested columns add noise without signal.

The result feeds directly into the run: the model learns a representation of every customer from these columns, discovers segments, and explains each segment in terms of the same columns you see in the dictionary. See How the segmenter works.

Next steps

• Check your table against the checklist in Data requirements.
• Browse Feature engineering examples for illustrative examples of the features segmentation benefits from.
• Learn to read and annotate the data dictionary once preparation is done.