Data requirements

Before Neuralift prepares your data, you need a source table worth preparing. This page is the checklist: what to have ready, why each item matters, and what to do if something doesn’t fit. Meeting it up front is the single biggest thing you can do to speed up your engagement.

What you provide vs. what Neuralift produces

You can provide either entity-level tables (already one row per customer) or raw transaction and event history. Preparation produces the prepared dataset: one row per customer, ready for segmentation. The one-row-per-ID requirement applies to that prepared output, so if you bring raw history, Neuralift aggregates it up to customer level during preparation.

The checklist

Requirement	What it means
One row per customer	The prepared dataset has one row per entity you want to segment: provide a table at that grain, or raw history that Neuralift aggregates during preparation.
A unique ID column	One column that uniquely identifies every row.
KPI columns	The business outcomes you care about, with a clear direction of “good”.
No PII	Neuralift does not accept any data with PII.
A supported format	A warehouse table via your data connection, or Parquet, CSV, or Delta files.
Clean column types	Numbers stored as numbers, dates as dates, no deeply nested structures.
Real nulls	Missing values as actual nulls, not placeholder text.
Consistent dates	Date columns in a consistent, parseable format.

The sections below expand each item.

One row per customer

Segmentation groups customers, so the prepared dataset must describe customers, one row each. The requirement applies to the prepared output, not necessarily to what you provide: if your data lives in transaction or event logs, Neuralift aggregates it up to customer level during preparation, producing totals, averages, recency, and trends per customer rather than one row per receipt. Feature engineering examples shows the patterns, and Neuralift works with you on the aggregation design during onboarding.

You can segment entities other than customers (members, players, accounts, households) as long as the table has one row per entity.

A unique ID column

Every row needs one column that identifies it uniquely, with no duplicates and as few nulls as possible. A pseudonymous identifier such as <customer_id> is ideal; it lets you join segment results back to your own systems without exposing who anyone is. If identifying a customer in your data takes a combination of columns, raise it with your Neuralift contact before syncing so the right single key can be built.

KPI columns

Segments are profiled and compared against your KPIs: the outcomes you want to move, such as revenue, visits, or a churn flag. Have those columns present in the table, and know the direction of good for each one: revenue up is good, churn up is bad. KPIs can be continuous values or already banded; either way they are ranked and confirmed in the use case definition.

No PII

Neuralift does not accept any data with PII. You must remove names, email addresses, phone numbers, street addresses, and any other directly identifying fields at the source, before syncing, and key the table on a pseudonymous ID instead. See Data handling & security.

A supported format

The usual path is a warehouse table synced through your data connection. Parquet, CSV, and Delta files are also accepted when a warehouse connection isn’t the right fit; ask your Neuralift contact about file hand-off.

Clean column types

Each column should hold one plain type. The common problems to fix at the source:

• Numbers stored as text. A revenue column containing "1,204.50" as a string reads as categorical, not numeric.
• Deeply nested structures. Columns holding arrays, structs, or maps can’t be used directly. Flatten them into plain columns before syncing.
• Mixed content. A column that is sometimes a number and sometimes a note will be typed by its worst rows.

Real nulls

Missing values should be actual nulls, not stand-in text such as "N/A", "-", "NULL", or an empty string. Preparation normalizes the common cases, but placeholder tokens it doesn’t recognize can end up treated as real values. If your systems use a house convention for “missing”, tell your Neuralift contact so it’s handled explicitly.

Consistent dates

Date columns should use one consistent, parseable format. Dates matter more than they look: recency, cadence, and trend features are all computed from them, so an unparseable date silently costs you some of the most valuable features in the table.

If your table isn’t accepted

Troubleshooting is symptom-level: work through the checklist above, then ask.

Symptom	Likely cause
Preparation can’t start on your table	One of the checklist basics is missing, most often no unique ID column.
A numeric column shows up as categorical	The values are stored as text; fix the type at the source.
Date-based features look wrong or missing	Inconsistent or unparseable date formats.
Columns you expected are missing from the dictionary	Empty, constant, and deeply nested columns are dropped during preparation because they carry no usable signal.

If the checklist doesn’t resolve it, contact your Neuralift representative or support@neuralift.ai; reviewing your table together is a normal part of the engagement. See Getting help.

Next steps

• See what preparation adds on top of your table in Feature engineering examples.
• Sync the table through your data connection.
• Review the result in the data dictionary.