Why AI for Car Dealers Does Not Increase Car Selection Conversion
A car dealer's catalog is dozens of models and thousands of trim levels, and almost all car selection by parameters comes down to filters: price, body type, transmission, drivetrain.
The customer arrives with a different question — "spacious family car for everyday use," "compact for short city trips" — but the interface asks about specifications, not the usage scenario.
Selection turns into trying out options: the customer scrolls through dozens of cards, the manager spends the conversation on clarifying questions, and some inquiries leave without a test-drive booking.
Catalog personalization of cars in AI for car dealer projects usually builds on clicks and views, that is, on what a person has already seen, not on what they were looking for.
The model honestly learns the most popular trims and starts offering them to everyone — the output looks diverse but does not match intent.
Feedback also breaks off at booking: whether the customer reached the dealership or not, why they refused, what they viewed instead — all this does not enter the learning loop.
The bottleneck in selection is not output quality but a signal gap. Intent is smeared across a website request, call, chat, visit history, and manager notes in the dealer's management system.
Until this data is brought into a single customer profile, any model ranks noise and optimizes the wrong thing: impressions instead of selection conversion into booking.
Below we break down how this is closed: which sources form the intent profile, how it turns into catalog ranking, and why booking, not view depth, becomes the target metric.
What Changes After Implementing Selection Personalization
Selection personalization is not highlighting a banner on the homepage but a different catalog logic: the selection is assembled for a specific session based on behavior and query wording.
The customer does not need to know the exact trim name — ranking works on the "query — interest" pair. The layer on top of Elasticsearch returns the selection instantly and recalculates it at every step.
Conversion from Selection to Test-Drive Booking
Here they count not visits but the share of matches with interest: how many sessions reach a card from the selection and a test-drive booking.
When the first two or three options match the query, the number of steps to a decision shrinks from five to seven down to two or three, and the customer does not leave to compare on third-party platforms.
The share of abandoned selection sessions falls by about a third on average: the selection explains itself — why this model and what changes in the trim. Explanation works better than sorting by price.
Selection Speed and Manager Workload
The second effect is the time to a meaningful list of candidates. Previously, a customer came with the request "show me something in this class," and the meeting went into identifying the need. Now the input includes two or three models with clear criteria, and the manager discusses terms.
The load on the sales department is redistributed: the share of cold inquiries decreases, and substantive conversations become more numerous.
We check recommendation accuracy on a holdout sample: if the selection diverges from actual views and sales, the model is retrained rather than manually corrected.
Personalization Formats: Comparing Approaches and Limitations
Manual Rules and Catalog Filters
The output is set by the manager: class, in-stock availability, delivery time, budget within agreed limits. Such output is explainable and predictable, but as the catalog grows, rules begin to conflict, and seasonal demand shifts are entered manually.
Model Based on Deal History vs. Hybrid Scheme
A model based on deal history finds non-obvious connections between trim levels but is blind to new stock items and sharp demand shifts — until a position has deals, it will not appear in the output.
The hybrid scheme adds catalog rules and real-time feedback to history: a refusal, repeat view, or test-drive request changes the output within the session.
| Option | When It Fits | Limitations |
|---|---|---|
| Manual rules and catalog filters | Small stock, stable demand, need for explainability of every recommendation | Rules conflict as the catalog grows; new items and seasonality are adjusted manually |
| Model based only on deal history | Deals accumulated over a long period, demand changes slowly | Cold start on new positions, no reaction to refusal in the moment |
| Hybrid scheme with feedback | Large catalog, high inquiry frequency, reaction within the session matters | Requires event tagging and data quality control, harder debugging |
The choice is determined by catalog size and the speed of demand change. We test each option on the dealer's accumulated data and show where a rule is more accurate than a model and where feedback is needed.
How We Implement a Recommender System: Work Stages
Implementing a recommender system at a car dealer rests not on algorithm choice but on the quality of data about stock, customers, and deals. First comes an audit of the car dealer's data and metric definition, then output and testing on live traffic. Below are the stages we go through together with the client.
Data Audit and Metric Definition
- Data audit. We reconcile the catalog (make, body type, trim, drivetrain, mileage), deal history, CRM inquiries, test-drive bookings, and refusal reasons. We look for duplicates and discrepancies in trim codes. The output is a data suitability map and a list of what needs to be filled in.
- Data schema. We assemble a single customer and car profile and fix the linking keys between stock, CRM, and the display channel. We close gaps with explicit rules, not guesses.
- Output setup. We define the signals that move a card upward: budget, body type, length of ownership of the previous car, service visit history. We set the dealer's commercial priorities as separate weights — they can be changed without retraining.
- Selection quality metrics. We fix before launch: the share of sessions with three or more cards opened, the share of test-drive bookings from the selection, and the share of refusals due to irrelevant price. We calculate the baseline on historical data; otherwise there will be nothing to compare against.
Testing on Live Traffic and Handover
- Shadow launch of recommendations. The system builds output in parallel with the current one; the visitor sees the previous option. We compare on the same sessions and remove discrepancies before they affect customers.
- Rollout on live traffic. We enable selection in fractions: first for a share of visitors, monitor metrics, and roll back to the previous output if there is a deviation.
- System handover to the client. We provide access and roles, a procedure for reviewing disputed outputs, and train sales department employees. After that, the dealer can change weights and add signals independently.
What We Hand Over to the Car Dealer: Models, Data Schemas, Procedures
System handover is not a binary fact "we have it working." The dealer receives the model, the catalog data schema, procedures, and access rules — the things by which selection can be developed independently.
Without this, the system degrades in a couple of months: new trims and prices do not enter the features, and the manager sees recommendations for discontinued versions.
Data Schema and Retraining Rules
- Trained selection model: description of features, their weights, and which data about queries and deals affect it.
- Catalog data schema: required fields for model, trim, options, and availability; validation rules during upload.
- Integration schema with the management system: which events — inquiry, test drive, refusal, purchase — are returned as feedback.
- Retraining procedure: triggers, frequency, procedure for rolling out a new version and rolling back to the previous one.
- Instructions for managers: how to read the output, which signals to consider doubtful, and how to pass on feedback.
- Quality control procedure: control queries, metrics for hitting target trims, and the retraining threshold.
- Data access rules: roles, separation of personal and depersonalized fields, log of accesses to customer history.
The package is structured so that the client can verify it without us: run control queries, compare the output with the current catalog, and reproduce retraining according to the procedure. An item that cannot be confirmed at acceptance is considered not handed over.
Case: How the Share of Test-Drive Bookings Grew
The dealer holding AvtoSfera — eight locations, a catalog of new and used cars — before implementation gave everyone the same sorting: by price, year, and mileage. The customer returned to the site but again hit the same list and rarely reached a test-drive booking.
We assembled personalization on session events: card views, comparisons, applied filters, saved selections.
From them we calculate a preference profile — body type, transmission, drivetrain, mileage range, budget band — and rerank the catalog, the "similar" block, and selections in the email.
The target action is embedded in the model as a signal: a test-drive booking or manager call changes the feature weights for similar sessions.
What Changed in Customer Behavior
- Share of selections ending in a test-drive booking — from 2.4% to 7.1% of sessions with active selection. The growth came not from banners but from output order: the needed trim landed in the first cards.
- Catalog view depth — from 7 to 15 cards per session. Acceleration came from the fact that filtering out irrelevant body types and transmissions happened before scrolling.
- Share of returns to an unfinished selection within a week — from 11% to 27%. The saved profile is pulled into a new session, so the customer continues from where they stopped instead of starting over.
We measured the implementation result on a control group, not by a before-and-after comparison: half of the traffic saw baseline ranking, so seasonal demand spikes were not attributed to personalization.
For sessions without history, a cold start works on aggregated dealership preferences, and disabling the profile returns the usual sorting — rollback does not require reassembling the catalog.
How a Recommender Model Differs from Catalog Filters
A filter answers a query the customer has already formulated: body type, drivetrain, class, engine type, trim.
It does not know what the user did not select, so positions that fit in essence but were not guessed in the filter panel remain outside the output — and go to a competitor.
The recommender model completes intent from behavior: a set of viewed cards, time in the photo gallery, comparison of trims, returning to the same model from another device.
The output is not a binary selection of "fits/does not fit" but an order in which the catalog shows the customer's most likely next step.
The second layer is the similarity of buyer profiles. If customers with similar behavior and deal parameters stopped at certain configurations, this signal is transferred to a newcomer who does not yet have their own history.
This closes the cold start, and online behavior is linked to deal facts from the dealer's management systems (1C, CRM), not only to clicks.
Embedding this into the current site does not mean demolishing filters: the catalog and search remain the source of truth on stock; the model connects as a separate output layer — a block on the card, order in the listing, a selection for repeat touch.
We make the transition without stopping sales through shadow mode: recommendations are calculated in parallel, shown to a share of traffic, and their quality is compared with the current output on identical segments.
The acceptance criterion is the share of sessions where a recommended car is opened, view depth, and conversion to test drive specifically for these sessions. If there is no shift, the block is turned off with one toggle, and the site works as before.
Common Technical Questions About Recommender Systems
Before the project starts, clients ask roughly the same questions: how much deal history is needed, what to do with rare trims, how to update output without stopping sales. Below are short answers on how this is solved at the model and integration level.
How much deal history is needed for recommendations to work?
The model does not require a multi-year archive: we supplement collaborative filtering with features from cards — segment, body type, drivetrain, fuel type, price range.
When there is little interaction data, the weight shifts toward catalog content and on-site behavior: views, comparisons, inquiries.
What about rare trims — will they drop out of the output?
No. For positions with few interactions, similarity by characteristics works: the recommendation is built through versions close in parameters but more popular. As soon as a rare trim accumulates its own signals, its weight is recalculated automatically.
How is the cold start of a new customer solved?
We serve the first session according to segment rules and local model popularity. Then behavioral signals connect, and after several meaningful actions — comparisons and inquiries — the output is rebuilt for the specific person.
Can it be implemented without stopping sales?
Yes. The recommender service connects to the catalog and management system on the side and does not interfere with current processes.
First comes shadow mode: we calculate output, compare it with the working one, and only then switch a share of traffic — with the ability to return the previous logic at any moment.
How do we know the model is degrading?
We monitor the response share, card view depth, and divergence of calculated metrics from actual ones. A sustained decline over the observation window triggers scheduled retraining, while the previous version remains available for rollback.
Let's Discuss the Task: Data, Integrations, Acceptance Criteria
Assessment and work plan for personalization rely not on general considerations but on a specific dealer's data.
To come back with a calculation of stages and timelines rather than clarifying questions, it is enough to bring to the first discussion what already exists in the catalog, reports, and management system.
What to bring to the first discussion:
- Catalog export: models, trims, options, availability, and delivery times — the base on which selection is built.
- Inquiry statistics for several months: which models are asked about, what was offered in response, and how the dialogue ended.
- On-site behavior: card views, comparisons, configurator usage, exit points.
- List of systems where recommendations should go: website, dealer management system, customer chat channel, availability data.
- System acceptance criteria: what share of impressions is considered relevant, on what data this is measured, and who on the dealer side accepts the result.
- Constraints: timelines, personal data processing requirements, access to systems, and who provides them.
- Responsible people: who provides data, who approves disputed cases, who works with the system after launch.
If some item is unavailable, this is not a reason to postpone the conversation. Tell us about it right away, and we will suggest where to start the project: which data is replaceable and which should be collected first so that the assessment and work plan are realistic.
