Segmentation / 4 min read /
Build customer segments that explain their membership
Combine Jev decisions with observed product events without confusing behavior, probability, and causation.
A customer retries checkout three times, contacts support, and leaves. A useful segment might be “recent checkout friction with an unresolved payment request.” A much less defensible segment would be “customers who left because they do not trust us.”
The first name describes observable conditions. The second invents a motive.
Jev can contribute structured judgments about the support request. Your event system supplies what happened. A segmentation engine combines those two sources into membership rules that an operator can inspect.
Give every clause an owner
Consider this proposed segment:
at least 3 checkout failures within 24 hours
AND an unresolved support request exists
AND that request is classified as payment-related
The event counter owns the first clause. The ticket database owns the second. A model classification supplies evidence for the third.
A membership inspector should display all three. If the support text is unavailable, membership is unknown—not false, and not automatically true because the events look similar to a previous customer.
This design is deliberately modest about what the model knows. It also makes debugging much easier: an operator can distinguish missing events from an incorrect classification.
Respect the clock
Every segment needs a time window and an available-through timestamp. “Failed checkout in the past day” is different from “has ever failed checkout.” A later successful payment may change the operational response even though the earlier failure remains part of history.
Evaluate predictions using only information available at the time they would have been made. A canceled subscription recorded tomorrow cannot help a model predict cancellation today.
For longitudinal evaluation, separate earlier and later periods. Where appropriate, keep the same account out of both training and evaluation. Otherwise a segment can look accurate because the system recognizes repeated customer-specific language.
Keep uncertainty in the membership model
An exact event predicate is not a model probability. A high probability of payment intent is not a high probability of future churn. Store them as separate fields.
Do not multiply several decision probabilities to obtain a segment probability unless the required dependence assumptions have been established. Two questions about the same ticket can be strongly correlated.
A practical initial implementation uses three membership states: included, excluded, and needs review. Known fields are evaluated deterministically. Model-dependent clauses use an evaluated policy. Missing evidence or unsupported input produces review.
Segments can overlap. A customer can belong to both payment friction and onboarding delay. Counts across overlapping segments must not be added as if they were a partition of all customers.
Discover groups without pretending to discover truth
The unresolved queue is a useful place to look for recurring themes. Embeddings and clustering can propose groups of similar records. Show representative records and ask an operator to name, merge, or reject each group.
A proposed cluster is not automatically a category. Its membership may change with the embedding model, clustering parameters, or incoming traffic. Record those versions and test stability before making operational decisions from it.
Promoting a cluster into a taxonomy is a product decision. Give it a definition, label examples and counterexamples, evaluate a classifier, and migrate any dependent segment rules explicitly.
Turn a segment into an experiment
An actionable segment might route affected customers to support, show an appropriate help article, or prioritize a product investigation. Record the intervention separately from segment membership.
If you want to claim the segment improves retention, compare outcomes through an appropriate experiment. A rising conversion rate among contacted users does not establish that the contact caused it; selection and timing can explain the difference.
The public demo should let a visitor inspect a timeline, see why a record joined a segment, and change one predicate to watch membership update. If the events are synthetic, label them synthetic. If decisions are recorded, identify the run.
That is a more useful experience than assigning a mysterious customer score. It shows a team which evidence led to a group and what they can responsibly do with it.
This is an original application design for combining typed decisions with event data. The current local gate is not trained for behavioral segmentation. Architecture and provenance requirements are specified in the batch contract proposal.