Skip to main content

AI Fields

What it does​

AI Fields adds a column to your table by asking a language model a question about every record. You write the question once, point it at the columns it should read, and the answer becomes a new field.

The results are ordinary columns on your table. Once a field is active, they behave like any other: filter audiences on them, use them in signals, explore them in Users Explorer, feed them to the AI models.

Examples of what you can add:

  • Read a review or a support message and add its sentiment, or the topic it is about.
  • Turn a free-text note into a category from a list you define.
  • Read a product description and add a tier or a tag your data doesn't hold.
  • Summarise several columns into one sentence an agent can read at a glance.

AI Fields sits beside External Data Enrichment. The two are siblings and share the same vocabulary: enrichment looks a value up with a data provider, AI Fields works it out with a model. If you have read one page, the other will feel familiar.


When to use it, and when not to​

This is the most important thing on this page. AI Fields costs money for every different answer it produces, and the other ways of creating a field do not.

You wantUse
A value your data already implies — a total, a ratio, a flag, a date differenceField Builder calculated or aggregated field. Free.
A value that is a straight lookup — a code that maps to a nameField Builder lookup. Free.
A value that exists in someone else's database — the city behind an IPExternal Data Enrichment. Paid per value.
A value that needs reading and judgement — is this review angry, what is this message aboutAI Fields. Paid per distinct answer.

If you can express the rule, express the rule. A conditional field is free, instant, and gives the same answer every time. Reach for AI Fields when the question genuinely needs someone to read the text and decide, and nothing shorter will do.


How it works, in plain terms​

  1. You create an AI field: the table, the question, the columns the question reads, and the columns the answer fills.
  2. BPP collects the distinct combinations of the columns your question reads. If 5,000 records hold 900 different review texts, the model is asked 900 times, not 5,000.
  3. Each combination is sent to the model once, and the answer is stored privately.
  4. The answers are attached back to every record carrying that combination, and appear as new columns on your table.
  5. It runs again as part of your platform's scheduled pipeline — after the AI models and before audiences are rebuilt, so segments are always built on values you can see.

Two consequences worth knowing:

  • New records are picked up automatically. Every scheduled run answers combinations that have appeared since the last one.
  • Answers you already have are only re-asked if you say so. That is the run logic you choose in the wizard.

What it costs​

Cost tracks distinct answers, not records

This is where estimates go wrong by an order of magnitude. The model is asked once per distinct combination of the columns your question reads, and every record with that combination shares the answer.

A field over 10,000 users that reads only country and device type might produce 27 different answers. You pay for 27, not 10,000.

The same field reading a review text instead, where almost every record differs, is closer to one answer per record — and costs accordingly.

So the columns your question reads decide the bill. Adding a column that is unique per record, like an ID or a timestamp, turns a cheap field into an expensive one without changing the question.

The wizard shows you both numbers before you commit. Count records reports how many records are in scope and how many distinct answers they resolve to, and it is free to run as often as you like.

Two more things that keep the spend predictable:

  • Answers already produced are not bought again, unless your run logic says to refresh them.
  • The test run in the wizard is a real, billed call on 5 to 50 records. That is what makes it a real test.

Where the new columns appear​

Once a field is active and its first run has completed, the columns show up wherever fields are used:

WhereWhat you can do
AudiencesFilter on them, e.g. "Sentiment is negative".
SignalsUse them in conditions like any other field.
Users ExplorerSee the value on each profile.
AI ModelsThe models pick up the columns as additional features.
Field BuilderBuild calculated fields on top of them.

Each output carries a Show in Users Explorer toggle: turn it off to keep the column but hide it from the pickers.

Columns appear before the answers do

Activating a field adds the columns straight away, and they read empty until the first run finishes. That is expected. Anything reading them — audiences, signals, models — sees empty values until then.


Field lifecycle​

StatusWhat it means
DraftConfigured but never activated. No columns exist and nothing has been asked.
RunningA run is in progress.
CompleteRunning normally: the columns exist and are kept up to date by every scheduled run.
SuspendedPaused by you. Skipped by the scheduled pipeline; the answers already produced are kept, so resuming does not pay for them again.
ErrorThe last run failed. The reason is shown on the field, and the next scheduled run retries.

What leaves the platform​

To answer your question, the model has to be sent the values your question reads. Nothing else is sent: not the whole record, and not columns your question does not name.

Every column in your schema carries a switch saying whether its values are allowed to leave the platform. Only Bytek staff can change it. Columns declared as Email or Personal Phone identifiers start blocked; every other column starts open. If a column is blocked, it appears in the picker with a lock and cannot be used in a question, and a field that tries to use one is rejected when you save.

If you need a blocked column opened, ask your Bytek contact. If you would rather a sensitive column were never usable here, ask for it to be closed.


Learn more​