AI on an automotive marketplace starts with the dealer inventory feed

Nearly every automotive marketplace AI announcement this year has been about the front end. Carsales added voice search, backed by its own survey saying over a third of Australians use AI to help with vehicle searches. Stellantis says its SPOTICAR assistant has already handled three million natural-language searches.

None of that is wrong, and the search box is the part shoppers see. But neither announcement says much about where the cars come from. Natural-language search ranks whatever is in the index. If the listing data is stale or inconsistent, a better model just ranks the wrong cars with more confidence. There’s a preprint from Allouah and colleagues on AI shopping agents that found small tweaks to a seller’s product description can shift market share in a meaningful way, because what’s in the listing is what the agent reads.

Natural-language search is only as good as the inventory under it

On one automotive engagement I spent a lot of my time on the layer underneath: getting dealer and manufacturer inventory into a marketplace in time for a launch. The thing I kept telling the team was that we needed to flip the attitude around. Our customers were internal, the dealer websites and the marketplace. You don’t try to build a golden architecture, beautiful services handling all of the inventory. The only important thing right then was feeding the inventory through to the marketplace.

I like to call that outside in. Everything about the inventory service becomes serving those two customers, and that informs all of the work, including the work of moving things off the old systems upstream.

It also means accepting the formats you’re given. Developers, me included, have a bit of an allergic reaction to FTPing files around. But REA Group used, and still uses, XML over FTP. It’s not even a real FTP server anymore, it’s a fake one that picks the file up and processes it. They decided that reworking every real estate agent’s software to talk to the portal was too much work and too prone to errors when there was already a standard and a format. Dealer systems are the same. They’re in use by every dealership on them, and they aren’t going to change for you. The format becomes the contract.

One job per dealer

The ingest pattern I pushed for is boring on purpose. Rather than one scheduled job that iterates through the dealers, you have one small job whose only work is getting the list of active dealerships, and it fires off a job per dealer. Each of those calls the source for that one dealership, does some processing on what comes back, and puts the vehicles on a queue one at a time. Vehicle, vehicle, vehicle. Then you’ve got a queue full of vehicles, and everything downstream works off that.

The reason is failure. If you do it all in one job, it works down the list, gets to the fifth dealership, the manufacturer has deleted that dealership, it throws an error and the whole thing falls over. You don’t get the couple of hundred dealerships after it. If you fire off a job per dealer, one of them fails, you get a notification that it’s failed, and it doesn’t touch the rest.

The top-level job runs on a schedule, every hour, every week, whatever, and you can trigger it by hand when a dealer is being onboarded for the first time. It’s a very straightforward thing to build. Even where a source doesn’t hand you inventory as such, it’s likely to be the same pattern: poll the endpoint and shove what comes back onto a queue for processing.

Once it’s on the queue, normalisation is where the marketplace earns its keep. A search result on a marketplace has competing dealerships sitting next to each other. If you’re showing what a shopper would pay to lease, then every lease has to be equivalent to every other lease, and every dealer finance offer to every other one. One manufacturer gives you a thousand off and another gives you two thousand, and that’s a meaningful thing for somebody looking at a list, but only if the numbers are calculated the same way.

Ship the partial feed and iterate

Later on the same engagement there was a question about whether to hold the feed back until every edge case was understood. My view was that it’s better having a partial solution and iterating on it than waiting until we work out every possible edge case. The easy dealers on their own were a bucket of many, many cars. I’d be inclined to get something working, even if it’s imperfect, and then iterate on it.

Doing it incrementally is fine. It’s not complete, but if you can push a bunch of inventory down from the manufacturer and process it, you’ve got something real to look at. When I was working out the shape of it, my aim was a rough version of processing vehicles into the inventory and the catalog as a proof of concept, so the people who knew the data could look at it and say, no, this is wrong. That conversation is far more useful with real processed vehicles in front of everybody than with a diagram.

Portals have to say no to dealers sometimes

Dealers will always push for things on a marketplace. Aside from manufacturer requirements, where you have less push, the dealers should sometimes be told no, you can’t have that, because it has a negative impact on the experience. We have to be the custodians here, explaining to them that they’re shooting themselves in the foot.

This isn’t new. It was always one of my things at REA: you’ve made that great for agents, but as a consumer I’m wading through listings rather than looking at a set of things I need to review. And once I’ve said I’m not interested, why would I ever see that one again? The people paying for the listings and the people searching them want different things, and the portal is the one that has to balance the two.

AI makes that matter more. If small changes to how a seller describes something can shift what an AI agent recommends, which is what that research found, then every dealer has a reason to push on how their listings read. Somebody has to push back on behalf of the shopper, and on a marketplace that job falls to the marketplace.

What I learned building 360 spins on a deadline

The other half of listing quality is the media, and that’s where my automotive work started. Some of the first automotive work I did was 360-degree spins around cars. The app dealers used for it was going away at the end of the year, there were a lot of dealers relying on it, and there were only a few months to replace it.

I’d come from leading engineering on REA’s innovation team, which was VR, AR and 3D scanning, so I said let’s prove it. I’ll do a prototype, we’ll timebox a month, and if I can’t prove it in a month then it’s not going to happen anyway. Two weeks in I’d shown we could do the walkarounds. From there I built the mobile app solo from scratch in Unity, for iOS and Android, while their team did the backend plumbing for the ingestion. We got it live in the app stores and switched the dealers across before the deadline.

Looking back, it’s the same approach I took on the feed work. Get something working early so people can see it, and keep the scope to what actually has to be live by the deadline. And the spins only mattered because they ended up on listings, so in a way the capture app was a feed too, it just started with a dealer walking around a car with a phone.

If you’re putting AI search on a car marketplace, I’d spend the first weeks on the feed. A job per dealer, a queue full of vehicles, normalised so listings can actually be compared, and shipped partial so you can improve it with real data. The search on top is only going to be as good as what’s in there.

If you want a second set of eyes on an ingest pipeline before you build AI on top of it, that’s what an architecture audit is for.