Why AI customer segmentation runs into manual rules
Today a segment is most often assembled by hand: an analyst writes selection conditions in SQL or a report builder, exports the customer base from CRM, billing, and the support system, and merges everything into one table.
The rules are static — “purchased in the last 90 days,” “average order value above the threshold” — and disparate exports from systems reconcile only after key matching and manual review of discrepancies.
The cost of such a scheme does not show up immediately. A customer changes behavior within weeks, while selection rules live until the next revision, so the segment remains the same and leads communications past the audience.
Add overlaps: the same customer lands in three groups because each was assembled by its own query, and no one watches for consistency of boundaries between them.
Then everything runs into the analyst's throughput. Each new scenario is another query, another reconciliation, and another version of the table that cannot be reproduced a month later.
There is also no way to explain why a customer ended up in a group: behind the condition “average order value above the threshold” there is no behavioral model, only a threshold chosen by eye.
AI customer segmentation removes this differently. The model looks for joint patterns across dozens of features at once — frequency, recency, basket composition, channels, response to past campaigns — and identifies groups where manual base segmentation sees a homogeneous mass.
A language model turns each cluster into a readable description: what the group represents, how it differs from the neighboring one, and what to do with it in a campaign. Below, we break down how this is addressed step by step.
Behavioral segmentation: what disappears from manual work
A segment assembled manually lasts exactly until the next export: the analyst writes a query with fixed conditions, the manager sends the campaign, and a month later the group no longer reflects reality.
Behavioral customer features change the logic itself — the segment is recalculated based on actions, not on a filter set once.
A unified customer profile is assembled in the columnar store ClickHouse: event history, purchase frequency, recency of the last contact, category depth, acquisition channel, response to past communications.
Features are calculated in sliding windows of 7, 30, and 90 days and normalized — the profile does not depend on customer scale and is updated incrementally, without a full recalculation.
Next is clustering on behavior vectors. The key here is not the number of groups but their stability: before rollout, we check what share of customers remains in their group between recalculations and discard fuzzy boundaries. Otherwise the boundaries shift with every run, and such a segment cannot be relied on.
Automatic segment descriptions are produced by a language model: it reads cluster centers, their differences from the profile average, and forms a short text — who these customers are and what makes them stand out.
Segment updates without an analyst run on a schedule: recalculation, then rebuilding descriptions; manual editing is needed only when business rules change.
The effect is measurable: the update cycle shrinks from days to hours, the share of manual exports drops almost to zero, and questionable groups are filtered out before they enter work.
Comparison of approaches: rules, clustering, hybrid
Feature-based rules and customer clustering answer different questions: the former apply already known selection logic, the latter look for structure that the rules do not yet contain.
Therefore, comparison of segmentation methods makes sense along three axes — explainability of the result, resilience to new data, and maintenance effort.
Pure clustering rarely makes it to implementation: labels like “cluster 3” mean nothing to the business.
A hybrid approach to segmentation removes this limitation — a language model describes the composition of each cluster and proposes a clear name, while rules set the boundaries that the segment does not cross.
| Option | When it fits | Limitations |
|---|---|---|
| Feature-based rules | Groups are already known, explainability is needed: it is always clear why a customer entered the segment | As the number of conditions grows, thresholds conflict, rules become outdated, new groups are not found |
| Customer clustering | Group composition is unknown, there are many behavioral features, event history is available | The number of clusters is set manually, the result is sensitive to feature scale and outliers, labels are unreadable without a description |
| Hybrid approach | Both known slices and discovery of new ones are needed: rules filter out irrelevant items, clustering divides the remainder | More expensive to maintain: data drift must be monitored and boundaries revised |
| Training on labeled history | Accumulated labels from past campaigns and a stable feature set are available | Labels are subjective and become outdated, the model reproduces past decisions instead of new ones |
Implementation stages: from data audit to handover
The order of stages here is not a formality: each step produces an artifact that the next one relies on. Skip the source audit, and the feature schema will be built on guesses, and the segments will look nice on a chart but not work in campaigns.
-
Data audit for segmentation. We analyze transactions, support requests, product activity, and accounting system records. We check history depth, field completeness, and the key by which records are matched to a single customer. The output is a source map with explicit limitations.
-
Feature schema. We convert raw fields into behavioral ones: purchase frequency and recency, dynamics over equal windows, return share, depth of product usage. A feature that cannot be explained by business logic does not go into the split.
-
Calculation assembly. Features are assembled into a mart with regular recalculation: a new customer enters the segment in the next cycle, and history is not recalculated from scratch. The set version is fixed — the result is reproducible.
-
Clustering and descriptions. We calculate several splits and compare stability: a segment that falls apart when the window shifts is not suitable for work. For each profile, we attach a human-readable description and verify it against the numbers.
-
Segment quality check. We look at group sizes, differences in target actions, and stability on a holdout period. We make sure the split does not repeat one coarse variable — region or customer lifetime.
-
Handover of the solution to the client. We provide access, the recalculation policy, and instructions for reading segments, and train the team. We stay in touch while the solution becomes established in your processes.
What we hand over: artifacts and policies
We hand over the solution so that it can be maintained without us. The package answers four questions: where the data comes from, how each feature is calculated, who has access to it, and what to do when segmentation quality declines. Everything listed remains with the client as a working document, not a verbal agreement.
- Data dictionary. For each feature — source, calculation formula, aggregation window, units, missing value share and filling rule, field owner.
- Data flow diagrams. Where events and transactions come from, where the marts are calculated, when the model is connected, and where the finished labels go.
- Access rules. Who works with source data, who works only with anonymized exports, how one-time requests are made, and how they are logged.
- Retraining policy. Triggers (distribution shift, metric drop, change in business rules), run frequency, and the quality check procedure before a new version is put into operation.
- Segment cards. Name, marker features, standard actions for the team, applicability boundaries — so that the cluster is not interpreted in someone's own way.
- Instructions for adjacent teams. How to get fresh segmentation, how to dispute a customer's assignment, and whom to contact when a calculation fails.
- Model version log. Which version produced the current labels, how it differs from the previous one, and how to roll back to the previous one without losing labels.
- Solution documentation. Architecture diagram, integration points, acceptance checklist, and handover procedure to a new engineer.
Case study: how manual base labeling was reduced
The client — a service with a base of about 380,000 customers — labeled the audience manually: once a quarter, the analyst exported transactions into tables and recolored groups by intuition.
One labeling iteration took around 120 person-hours, and by the time the list was ready, the behavior of some customers had already changed. As a result, every ninth campaign went to those who had not purchased for a long time.
We moved features into a mart and replaced manual labeling with behavioral clustering: purchase frequency, average order value in relative terms, recency of the last order, response to promotions. We run scheduled segment rebuilding in Airflow, so groups are updated without analyst involvement.
Before and after metrics
| Parameter | Before | After |
|---|---|---|
| Manual hours for base labeling | 120 per iteration | about 6 for verification |
| Group update frequency | once a quarter | once a day |
| Selection errors in campaigns | every ninth | one in sixty |
| Transitions between segments without behavior changes | 22% | 4% |
| Segments suitable for campaigns | 6 | 19 |
We maintain segment stability not by model accuracy but by a transition rule: a customer changes group only if they move away from their segment center beyond a set threshold.
Therefore, a campaign launched on a group does not fall apart during the next rebuild — the share of transitions without behavior changes fell from 22% to 4%.
We separately added a description of the profile in human language: the language model reads the cluster features and formulates who entered it — the marketer sees “buy one item once a month and respond to a discount,” not a cluster number. Manual labeling shrank by about twenty times, and groups can now be updated even daily.
How does clustering differ from feature-based rules?
Feature-based rules are set by a person: “purchased in the last 30 days, amount above the threshold — active customer.” Such segmentation is predictable, easy to explain, and reproducible, so it is used when segment boundaries are known from the logic of working with customers.
The weak point is that thresholds are assigned manually, and across dozens of features a person stops seeing which combinations actually distinguish the audience.
Clustering starts from the data: the algorithm finds groups itself in a multidimensional space — by purchase frequency and recency, basket composition, and response to communications.
k-means and outlier-resistant variants produce a split that no one set: segments are assembled from actual behavior, not from the team's expectations.
The choice of segmentation method is determined by the data structure — dense compact groups, sparse groups, or nested groups require different approaches.
Next, we check group stability: clusters are recalculated on a holdout period and on a shifted sample.
If the segment composition jumps from run to run, it is a consequence of outliers, not real structure; a stable split gives a stable share of customers in each segment and a predictable result in the next recalculation.
Interpretation of clusters is a separate stage: group numbers without a description are useless. Profiles are formed by a language model from aggregated features and validated by an expert — otherwise it is easy to get a nice wording over a random set.
In practice, the approaches are combined: rules set hard constraints, and clustering looks for structure within them.
Common technical questions about data and privacy
Segmentation breaks not on the model but at the input: duplicates in the customer base, different date formats, empty fields in order history — and clusters assemble around missing values, not around behavior.
Therefore, before training, we fix the feature schema, cleaning rules, and minimum completeness for each field, and we perform anonymization on the client side: identifiers do not leave their perimeter, and the model works with pseudonyms.
Below are answers to doubts that most often come up during the evaluation stage. They concern data quality, result verification, and rights to the solution.
What to do if the data is incomplete or heterogeneous?
We calculate completeness for each field and discard features where the missing value share makes the conclusion random. We supplement the rest with derived features: purchase frequency, recency of the last order, change in average order value over time.
If there is objectively little data, we switch to rules and aggregates instead of training — the result remains reproducible.
How is customer data anonymized?
Direct identifiers are replaced with pseudonyms before being passed to the model, and the reverse mapping is stored only in the client's perimeter. For exports, we apply generalization: exact dates are turned into intervals, and amounts into ranges. A segment is described by behavior, not by personal attributes.
How do you check segment quality?
We calculate stability metrics: how cluster composition changes on a repeated run on a subsample, whether there are overlaps between groups, and whether they match business meaning.
We add a holdout period check — segments must explain the behavior of customers the model has not seen. If the labeling does not converge, the split is rebuilt.
Who owns the model and the data?
The data remains with the client, and we get access to it for the duration of the work. We transfer the training code, configurations, and segment descriptions to their repository along with documentation — retraining and launch do not require our involvement. Refusing support does not break the solution's operation.
What to send for evaluation and where we start
An evaluation of such a task is not done from a general description: how many stable clusters will result and how to describe them is visible only from the data.
Therefore, the review starts with input materials — they are enough to understand the scope of work and not make assumptions at random.
- Export of interaction history for a full year: orders, support requests, product activity. A slice is needed where both seasonality and one-time purchases are visible — otherwise clusters will assemble around outliers.
- Data schema with descriptions of tables and keys: where revenue, purchase frequency, recency of the last contact, and acquisition channel are stored.
- Current manual segments and how they are used: campaigns, conditions, sales department work — so that the new slice does not duplicate what already works.
- Three to five customer profiles from your team: what a loyal, dormant, and churned customer looks like. We use them to calibrate the number of groups and check that the result is readable by people, not only by the algorithm.
- Restrictions on personal data: what can be exported for the review, where processing is allowed, and who on the client side confirms the result.
Then the order is as follows: we discuss the task with an engineer — what decisions you make on segments and where the bottleneck currently is; we draw the perimeter diagram, where the data comes from and how the result returns to your systems; we send a work plan with an assessment by stages — data preparation, clustering, segment description, and validation on historical periods.
After the review, the assessment rarely changes: the volume and quality of data are already visible.
