Why email personalization breaks at scale
Personalization rests on the customer profile, and the profile is assembled from at least four sources: deals, order history, website behavior, support requests.
As long as these data live separately and do not converge on a single key, the model sees one person as several different ones — and the email goes out with a product purchased a month ago, or a category they have already abandoned.
Then segments break. Built manually, they age by send time: the customer has already placed an order, changed interest, unsubscribed from some channels, but the list still keeps them as an active buyer.
The larger the base, the faster the labeling and actual behavior diverge — and the less sense there is in rules like "purchased in the last 90 days."
At scale, manual campaign assembly stops scaling.
An analyst cannot label hundreds of thousands of profiles for every send, so the newsletter slides into identical emails across large segments — "everyone about the sale." The cost is predictable: low open rates, falling clicks, and growing unsubscribes, which hit domain reputation and reduce deliverability of subsequent sends.
The cause is not the copy or the email frequency. The loop between the data warehouse and sending breaks: there is no profile recalculation at send time, no incremental feature updates, and no way to roll back the model if recommendations get worse. We break down how this is closed.
What recommendation-based selection brings to newsletters
Recommendation-based selection changes not the entire email but three points within the send: subject line and first screen, order of product blocks, and send timing.
The model calculates relevance of the "recipient — product" pair from purchase and view history, and the email assembles the closest items for a specific person. Open rates rise on comparable segments, and email clicks become a verifiable metric rather than a promise.
Unsubscribes fall for another reason: people leave not because of email frequency but because of irrelevance — they are sent the entire catalog. Frequency caps and rules for segments with declining response suppress such an email before it turns into a spam complaint. Domain reputation stays intact.
Campaign preparation time shrinks: previously a marketer manually labeled blocks and assembled email versions; now they set goals and rules, and the system performs the insertion.
The send is prepared on the same business day, while templates and legal signatures remain under human control.
Repeat purchases return to the flow: a "time to restock" trigger, selection of related products based on customer history, complementary items instead of random ones.
We measure the effect on a holdout sample and a small share of traffic so as not to confuse growth with seasonality. We run assembly and sending in Braze and similar platforms with an interface for inserting dynamic blocks.
Email personalization: approaches and limitations
Static rules and segments provide predictability but scale poorly: the list of conditions grows faster than the team can maintain it.
Selection based on purchase history is more accurate for an active audience, but for new contacts and rare categories it relies on too short a history. Below are four options that are actually chosen between, with honest limitations of each.
What is actually compared
| Approach | When it fits | Limitations |
|---|---|---|
| Rules and segments | Stable catalog, short decision cycle, need full control over display | Manual maintenance, does not account for changing taste, emails within a segment are identical |
| Purchase history selection | Many repeat purchases, contact has accumulated a long history | Nothing to recommend to a new customer; rare categories drop out of the output |
| Product and email features | Broad catalog, little customer data, many new items | Poorly captures personal taste, requires clean product cards and filled attributes |
| Hybrid selection | Need a balance of accuracy and coverage across the entire base | Harder to operate: requires logging, quality control, and a clear rollback path |
Contact frequency is a separate layer on top of any option: it limits the number of emails per recipient per period and prioritizes between campaigns. Without it, accurate selection simply accelerates unsubscribes.
A hybrid selection is assembled like this: rules and segments set the boundaries and prohibitions, product features cover the cold start, purchase history refines the choice, and frequency capping prevents growth in accuracy from turning into growth in unsubscribes — we break down how this is configured on the client side.
How we implement selection: stages of engineering work
We start with data, not the model. Email selection rests on events: opens, clicks, purchases, unsubscribes. If the history is short or events arrive inconsistently, the first version will be guessing.
That is why the route is split into stages, and each ends with a verifiable result that can be accepted or challenged.
- Data audit. We examine which events are collected, how much history is stored, what share of recipients has a behavioral profile, and where the gaps are. The outcome is a list of gaps and a decision: what we close with collection and what we work around with rules.
- Event map. We bring actions to a unified schema: what counts as a signal, over what window, with what weight, how we match address and profile. Discrepancies in event names are removed at this step.
- Selection setup. The model learns on the agreed history; for new recipients we set a cold start — a block based on segment popularity while behavior is insufficient. We separately cap frequency so that growth in opens is not paid for with unsubscribes.
- Group test. Part of the flow continues to receive the previous emails, and we compare opens, clicks, order share, and unsubscribes. The effect must hold across several campaigns, not just one successful one.
- Rollback procedure. Before enabling, we fix metric thresholds and the procedure when they are breached: return to the previous scheme in one run, without code changes.
- Launch and handover. We enable gradually — first on a share of the flow, then on all of it. We hand over documentation, access, and training for your team.
Then comes support: metric review once every two weeks and updating the event map when new channels appear or recipient behavior changes.
Project artifacts: selection rules and procedures
Working personalization is not only recommendation output but also a set of documents by which it can be changed without us.
The handover package includes a data schema, selection rules, and operating procedures: your team's engineer can refine the model from them, and a marketer can launch a campaign and understand where to look when something deviates.
- Data schema. Which events are collected, with what field composition, and how the recipient profile, open and click history, and offer catalog relate to each other. Without this schema, neither retraining the model nor connecting a new source is possible.
- Selection rules. How the set of offers for one recipient is formed: which features participate, which constraints are in place — exclusion of already purchased items, lists of prohibited categories, requirements for output diversity.
- Frequency policy. How many emails per week are allowed to one address, by what signals frequency is reduced, and what happens if a recipient stops responding — so that growth in personalization does not turn into growth in unsubscribes.
- Marketer instructions. Step-by-step procedure for launching a campaign, campaign labeling, where to view the issued recommendations, and what to do if response drops relative to the previous period.
- Rollback procedure. Which previous rule set to return to, how to disable personalization for part of the audience, and by what indicators the rollback decision is made.
- Monitoring map. Tracked metrics with deviation thresholds: open rate, clicks, share of unsubscribes and spam complaints, audience coverage by recommendations.
- Version log. History of rule changes with date, author, and measurement of the result before and after — so that every intervention can be tied to an effect and rolled back selectively.
Each document is written for your data structure and updated along with the system — this is part of the handover, not additional work.
Case study: how response to a regular newsletter grew
What it was before implementation
Home goods retail chain sent a regular newsletter on schedule: a marketer exported segments, manually selected products, and edited selections for each send.
A send took six to eight hours of work, and up to 70% of positions in the email were replaced by hand — segmentation rules did not account for purchase history, recency of visit, or warehouse stock.
Response held at about 2.3% clicks, unsubscribe rate was 0.8% per send: the same people received the same blocks.
What was changed
We built a recommendation loop. Events of views, add-to-cart, and orders are written to a log, the model calculates the weight of each product for a specific recipient, and the email is assembled from ready-made blocks with insertion of ranked positions.
We separately configured frequency caps and product card "cooldown" rules so that an item would not repeat in two consecutive sends.
What it became after
Email response grew to 5.4% clicks, and the unsubscribe rate decreased to 0.4%. Assembling a send takes about 35 minutes, and the share of manual edits in offer selection fell from 70% to 15% — the marketer reviews the output and removes individual positions.
The loop provides a log for each send, so response dynamics are visible by segment, not only across the entire base.
How a ranking model differs from segmentation rules
Segmentation rules are a deterministic function of the profile: if status is active and purchase is older than two months, we show category X.
A ranking model learns from interaction history and estimates the probability of response for the "recipient — content" pair, sorting email blocks by that estimate. The difference is fundamental: rules set the boundaries, the model sets the order within the boundaries.
Rules are explained in one line and are cheaper to maintain, so they are kept for send frequency, stop lists, and mandatory blocks. The model wins where joint features that cannot be written by hand matter: recency of last click, time of day, device, category of previous view. The more events per recipient, the more noticeable the gap in response.
Cold start is the first limitation: while there is no history, the model relies on subscription features and the behavior of similar profiles, meaning it effectively returns to segmentation.
That is why we keep rules as a safety layer for the first campaigns of a new recipient and move them to the model after enough events accumulate.
Explainability is the second: the reason for a model's ranking is reconstructed through feature contribution and counterfactual examples, which is slower than a ready-made condition line. If support is required to explain every email to a person, some decisions remain with rules.
Overfitting and the feedback loop: the model recommends what was shown more often and stops testing new things, while a seasonal spike becomes fixed as the norm.
It is treated with a share of traffic for testing new items, time-based rather than random splits, and drift monitoring on a holdout period. The working scheme is a hybrid: rules constrain the space, the model ranks within it.
Common technical questions about implementing selection
Technical doubts at this stage are almost always the same: whether there is enough data, what to show a new customer, how not to pull personal data into the model, and whether the output can be tested without enabling it for the entire base. Below are the answers in the form in which we give them when defending a solution.
What should be done if there is almost no history for a customer?
We cover cold start with hybrid output: while events are below the threshold, segment rules and product associations from aggregate statistics work, and as they accumulate, the weight shifts to the personal model.
Trigger scenarios — abandoned cart, repeat visit, reaction to a previous email — provide a signal before history accumulates.
What volume of event history is needed to start?
The lower bound is several thousand interactions per active segment; after that, returns grow more slowly than data volume.
We store events in the columnar database ClickHouse: month-long slices are computed quickly, and old data is rolled up into daily profiles, so the registry does not grow uncontrollably.
How to secure personal data?
Depersonalized identifiers and events go into the model, not addresses and names; the mapping is stored separately, access is role-based, and exports are logged.
Retention periods and consents are fixed in the policy: when consent is withdrawn, the profile is deleted along with its features.
How to test quality before full launch?
We keep a holdout sample and compare personalized output with the baseline by opens, clicks, and unsubscribes. Rollout proceeds by traffic share — from single-digit percentages with gradual expansion, and rollback is done with one weight switch.
Let's discuss the task: what data is needed to start
An estimate of the scope for email personalization depends on what signal already exists in the data and how quickly the output must return to sending.
To avoid calculating "by eye," it is enough to gather a minimal set of inputs — usually this is one call and access to the items listed below.
- Email interaction history over several months: send, open, click, unsubscribe. It shows whether there is enough data for ranking or whether some segments will have to be merged.
- Offer catalog: what we recommend, with features for matching and rules about what and when cannot be shown.
- Data access: connection to the warehouse with read-only rights or a test environment with a depersonalized copy. We do not work on production mailing addresses.
- Integration points: where to return the output — into the current email platform via its software interface, into a queue, or as a file on a schedule, and how often it is recalculated.
- Metric goals: baseline open and click rates, meaningful uplift, and the horizon over which we fix the result.
- Data constraints: which features cannot be used, history retention periods, depersonalization requirements.
- Contact and current volume: the person responsible on your side, number of emails per week and segments, and the release approval procedure.
With this set, we calculate the scope: how many sources to connect, where improvements are needed on your side, what the iteration plan looks like, and the control group for testing the effect. Describe the task — we will come back with an estimate and a work plan.
