Moloco Integration for Car Dealers

Machine learning bidding that runs on conversion feedback, and a straight account of the feedback we do not supply.

Moloco is a performance demand side platform, and the emphasis belongs on performance. Where much of programmatic is sold on reach and audience definitions, this platform is sold on the quality of its bidding models: the machinery that decides, impression by impression, what a given opportunity is worth against a stated outcome. It grew up buying mobile app installs, which is a category where the outcome is unambiguous and arrives quickly, and it has been extending into web and commerce campaigns from that base.

For a dealership the translation is that this is not a platform you buy for placements. You buy it for optimisation, and optimisation is a machine that eats outcomes. Tell it what a conversion is, send it enough of them, and it gets better. Send it few or none and it degrades to ordinary buying with an extra layer of abstraction. That is the whole story of whether this platform suits a car store, and it is why the honest objection below matters more here than on most pages in this directory.

The case is efficiency at scale for a group. A dealer group running several rooftops across a state generates enough site activity, enough form completions and enough phone volume to give a bidding model something to learn from, and a platform whose entire pitch is bid quality can genuinely find cheaper outcomes than a manually managed line item. If your problem is that display spend feels undifferentiated across ten stores, this family of platform is a reasonable place to look.

The honest objection is volume, and for a single rooftop it is close to disqualifying. Models of this kind are trained on event streams measured in thousands per day, which is the world of app installs and retail checkouts rather than the world of one lot producing a modest number of enquiries a week. A store that hands such a model a trickle of conversions will get a model that has learned very little, at a platform fee, and would have been better served by a simpler buy.

The second objection is fit. Automotive demand is local and slow, the purchase happens offline, and the outcome that matters is a signature that never touches a browser. Before spending here, read what to expect from car sales leads and decide what you would actually optimise toward.

Available on request, a status with a published test rather than a soft no. The test is that no adapter file exists in the LeadLocate ad gateway for the platform, and none does. Moloco is not among the twenty networks registered against the gateway contract. Nothing is half implemented, no credential block is waiting on a key, and no code path in the CRM has ever addressed their API.

Access class is PARTNER, which always describes the vendor's gate and never ours. Credentials require an application the vendor reviews before issuing them. Those facts are published on separate lines because they fail in different ways and on different clocks. Our adapter is scheduled work we control. Their review is not, and it would still stand on the day our side was finished.

There is a third condition on this platform that the other two do not cover, and it deserves saying here rather than only in the gaps section: even a built adapter and an approved application would leave the bidding models without the conversion feedback that makes them worth paying for, because we do not send one. That is a more honest description of the distance than a queue position on its own.

A design, not a description, since none of it runs. The four row shape is used on every page in this directory so a connected platform and an unconnected one read the same way.

That last item in the bottom row is the one to sit with. On most platforms in this directory an outcome feed is a nice addition. On this one it is the product, and it is on the list of things that never leave the CRM.

Moloco would not be a special case in the CRM, and that is deliberate. Every advertising network answers one contract, which is what turns a request into a schedulable job.

A single library inside LeadLocate defines what any platform must be able to do: hand us an authorization URL, exchange the returned code for a token, list the accounts you own, deploy a campaign, pause or resume it, return spend and results, and prove on demand that the connection still works. Seven operations, one adapter file per network. That shape is why adding a platform is scoped work with a checklist rather than an open ended project, and why enabling one does not disturb the ones already running.

Twenty networks are registered against that contract. One is implemented, and the other nineteen return a refusal that names themselves, so a stray call anywhere in the CRM fails loudly and readably rather than looking like an outage at the network. Moloco is not among the twenty at all, which is what available on request means here rather than a gentler way of saying soon. Every entry in this directory carries a status with a stated test beside it, including the entries that say no.

Two paths, and the difference matters more than the branding.

The managed path is the webXintel Ads Network. It is included with the platform, our team builds and manages the campaigns from what you select in Leads Manager, and reporting comes back inside the CRM next to the activity it produced. Nothing on this page gates it and nothing on this page delays it.

The self connect path is where a named network belongs. You connect the advertising account your store already owns, campaigns route through it, and the billing relationship, the spend history and the account itself remain yours. Most vendors will not offer that, because it costs them the markup on your media. For Moloco the option is not available, because there is no adapter to route anything through.

Across both paths one limit holds today: our team performs the push, the pause and the spend read rather than you from a dashboard inside the CRM. That is a constraint of a young connection layer rather than a permanent decision, and it is queued work like everything else on this page.

Vendor application first, since credentials are reviewed rather than issued on sign up. Adapter second, meaning the seven operations against their endpoints, a credential block in the gateway configuration, and a verification call that proves the connection instead of assuming it. Third, and unlike most platforms in this family, a genuine answer to what a conversion is for your store and how it would ever reach the model, because without that the first two steps buy you an expensive way to run flat bids.

On measurement, delivery reads within a day or two as it does everywhere in display. Model performance does not, and it should not, because a bidding model that changes its behaviour after a handful of events is overfitting rather than learning. Expect a meaningful read in weeks and expect the early period to look ordinary, which is normal and is the reason patience is a prerequisite rather than a virtue here.

None of this is a promise about volume or about what any of it closes at. Nobody can promise that, least of all on a platform whose results depend on data nobody has sent it yet.

The first gap below is the one that decides whether this platform is worth requesting at all, which is unusual. On most pages the gaps are limits. Here one of them is the engine.

We do not run a server side conversions API of any kind, and we do not upload offline conversions. There is no outcome event stream leaving the CRM to any advertising platform. A bidding model that is sold on learning from conversions would be receiving nothing from us, and any claim that a connection would improve your cost per outcome should be read against that sentence.

We do not install or manage pixels, which is the other route by which a platform ordinarily observes site side outcomes.

We do not export a hashed audience built from your customer list, so seeding or suppressing against your owner base is not available.

We do not emit a vehicle catalog or an inventory feed to any advertising platform, so creative rendering specific units is out of scope.

No campaign has ever been deployed to Moloco from LeadLocate, because nothing in our code can reach them.

Ask for it by name and attach the store, because requests are recorded against the platform they name and the tally decides build order. A dealership ready to spend on a channel is a better signal than any internal roadmap meeting, and it is the only signal this queue runs on.

On this platform the useful thing to include is your rooftop count and your monthly enquiry volume. A performance buying platform earns its fee on volume, and those two numbers decide whether the honest reply is a queue position or a straight recommendation to spend the same money somewhere the feedback loop is shorter. You will get whichever of those two is true. The rest of the directory is published with the same statuses attached so you can weigh the alternative yourself rather than take our word for it.

The managed path runs today and waits on none of this. Platform pricing is on the pricing page and does not vary with the networks you turn on.

Does LeadLocate integrate with Moloco today?

No. The published test for available on request is that no adapter file exists in the ad gateway, and none does. Moloco is not among the twenty networks registered against the gateway contract, so there is nothing partial to describe.

Can I use my own Moloco ad account?

Not through the CRM. Routing campaigns through an account you own requires an adapter and there is none here. An account you hold with the vendor runs entirely on its own and nothing in LeadLocate reads or changes it.

What happens if I request Moloco?

It is recorded against Moloco specifically and counted, and the count feeds build order. Because this platform depends on outcome data we do not send, the reply will also say plainly whether requesting it makes sense for your store size.

Would you send conversion events to train the bidding model?

No. We do not run a server side conversions API of any kind and we do not upload offline conversions, to this platform or any other. A model sold on learning from outcomes would receive nothing from us, and that is worth knowing before you evaluate the platform fee.

Is a performance demand side platform sensible for one rooftop?

Usually not. These models are built for event volumes measured in thousands per day, and a single lot producing a modest number of enquiries a week gives them very little to learn from. A group across several rooftops is a different and more reasonable conversation.

What does PARTNER mean here?

It is the vendor's gate rather than ours. Credentials require an application the vendor reviews before issuing them, and that would still be true on the day our adapter shipped. The directory tracks it separately so you can see which side of the connection is actually holding things up.

A performance buying platform earns its fee on volume. Tell us how many stores you run and roughly how many enquiries a month they produce, and you will get a queue position or an honest redirect.