LiveRamp Integration for Car Dealers

Identity resolution is the one capability this whole directory lacks, which makes this the page where the gap is the subject rather than a footnote.

LiveRamp is plumbing between records a business already owns and the advertising platforms it already buys. A company hands over a customer file, the names and addresses and email addresses it holds, and LiveRamp resolves each record to a persistent identifier. That identifier is then distributed into ad platforms so the company can address those same people, or deliberately avoid them, without handing the raw file to each platform in turn.

Around that core sit the products most large advertisers actually buy: audience distribution into the major platforms, a clean room where two businesses can measure an overlap without either seeing the other's records, and an authenticated identifier used to buy media in browsers where third party cookies are gone.

For a dealership the translation is short. This is how the owner base becomes something you can target. Every store sits on years of sold customers, service visits and unsold shoppers, and in almost every store that file is used for email and nothing else. LiveRamp is the standard answer to making it addressable in paid media, which is why it appears in a directory of advertising integrations at all despite selling no advertising.

The case is that a store's own list is the best audience it will ever have and the one it advertises to least. Service due owners, customers approaching the end of a finance term, unsold shoppers from eighteen months ago: these people already know your name and have already transacted or nearly transacted. Being able to reach them in paid media, and to suppress them from conquest budgets so you stop paying to advertise at people who already bought from you, is worth more than most incremental reach a store could buy. It is also how a CRM database stops being an email list and starts being a media asset.

The honest objection has four parts and they compound. It is contract gated and enterprise priced, which is what the access class on this page means in practice. Match rates on dealership records are variable, because addresses go stale, households share an email address and a phone number changes more often than a person does, so the audience that comes out the other side is smaller than the file that went in. A single rooftop's file is often too small to justify the arrangement at all, which pushes this toward groups rather than stores. And the legal responsibility for what you onboard stays with the dealership, including the consent basis for every record and the obligation to honour opt outs downstream.

None of that makes it a bad idea. It makes it a decision for somebody with a large file, a lawyer and a budget, rather than an obvious upgrade.

Not started. The published test for that status is that no adapter file exists in the LeadLocate ad gateway for this platform, and none does. No authorization URL, no wire-up checklist, no partially written token exchange.

Access class is CERTIFIED, the strictest value in the vocabulary and the vendor's gate rather than ours. It means a contract, a certification or a minimum spend commitment stands in front of programmatic access. That is the highest external barrier on any page in this directory, and it is worth being clear about the order of events it implies: even a finished adapter would sit idle until a commercial arrangement existed, and the arrangement is not one we can enter on your behalf.

There is a more important reason this entry is unstarted, and it has nothing to do with the vendor's gate. An adapter here would be pointless without something to feed it. LiveRamp consumes an audience file. We do not produce one. Writing a connection to a system whose entire purpose is to ingest a thing we do not emit would be theatre, and this directory exists specifically to avoid that kind of theatre. That is the honest answer, and it is not going to be dressed up as a queue position.

This table is written differently from every other one in the directory, because the interesting row is the last one.

On every other page in this directory the first two rows are a design sketch and the last row is a caveat. Here the last row cancels the first two. That is the whole page in one table.

It is worth explaining the contract even on a page arguing that this platform does not fit it, because the mismatch is instructive.

Inside LeadLocate a single library defines what an advertising platform must be able to do: hand us an authorization URL, exchange the 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 contract is why adding a network is scoped work with a checklist rather than an open ended project, and why turning one on does not disturb the network already running.

Now read those seven against an identity platform. There is no campaign to deploy, no spend to report, and nothing to pause. Five of the seven have no meaning here. What an identity platform needs is an export pipeline: a way to assemble a customer file, apply the hashing the destination expects, deliver it, receive a match result and refresh it on a schedule as records change. That is a different piece of engineering from an adapter, and it would have to be built before an adapter was worth writing. The order matters, and nobody should be told otherwise when they ask about audience based display buying.

What would carry over is the plumbing. Credentials encrypted with AES-256-GCM before storage, an append only audit log carrying the company, the network, the user and the detail stamped in UTC because these tables are shared across dealerships, and objects that record which credentials created them and re-resolve those same credentials later. On a page about customer records, an append only log of who did what and when is not a nice detail. It is the minimum a store should demand of anybody touching its file.

There are two ways to advertise through LeadLocate and you pick. The first is the webXintel Ads Network. It is included, our team builds and runs the campaigns from the selections you make in Leads Manager, and it arrives as one line rather than a stack of platform invoices. Nothing to configure and no contract to negotiate with anybody.

The second is your own account. Connect the advertising account your store already has and campaigns route through it instead, on your billing, in your name, with your spend history intact.

Neither path involves your customer file, and that is not an oversight. A dealer group that already holds a contract with this vendor runs it in the vendor's own environment, feeding it from the systems that hold the records, which for most groups means the dealer management system rather than a marketing tool. Nothing about LeadLocate helps with that today and nothing about it interferes.

One limit holds across the gateway regardless of path: pushing, pausing and reading numbers from a network is done by our team today, not from your dashboard. That is a deliberate constraint while the connection layer is young, and it is on the list to open up.

Three pieces of work, and only the last one is an adapter.

First, an export pipeline that does not exist: assembling a customer file from the CRM with a defensible consent basis attached to every record, applying the hashing a destination expects, and refreshing it as records change. That is the missing capability across the whole product, not a LiveRamp specific task, and it would benefit every platform in this catalogue that accepts an audience.

Second, the commercial arrangement. A contract, a certification or a minimum commitment, entered into by whoever owns the data, which is the dealer group. Not something a software vendor completes on a customer's behalf.

Third, the adapter itself, which is the smallest of the three and would be near meaningless without the first two.

On measurement, set expectations away from lead counts entirely. The output of an identity project is a match rate and an audience size, and the honest business result is a suppression list that stops wasted spend and a targeted audience that performs better than cold reach. Those effects show up across a quarter in blended cost per sale rather than in a lead report on Tuesday, and any vendor quoting you a faster proof on this particular capability is quoting you something else.

This is the page in the directory most likely to be read as implying an audience upload, so the denial goes first and goes plainly.

We do not export a hashed customer list, and we do not build a matched audience for any platform. Not for this vendor, not for the one network we have connected, not for anything. There is no export anywhere in our product that turns a dealership's records into a targetable file, and that is exactly the capability this platform exists to provide, which is why the gap matters more on this page than on any other one in the catalogue.

We do not resolve, enrich or append anything to your customer records. No identity graph, no household matching, no third party attributes added to a contact.

We do not install or manage pixels, we do not run a server side conversions endpoint of any kind, and we do not upload offline conversions. Offline conversion upload is the other half of what identity platforms are usually bought for, and it is absent too.

We do not emit a vehicle catalog to any advertising system.

No call has ever been made to this vendor from the CRM, and a dealer cannot push, activate, pause or read spend on any network without our team. If a vendor has shown you this logo on an integrations page, ask them which file leaves your building and where it goes.

Say so, but say the underlying thing rather than the vendor name, because on this page they are different requests. Almost everybody asking for this wants one of two outcomes: to advertise to their own owner base, or to stop paying to advertise at people who already bought. Both of those need an export pipeline first, and that is the request that would actually change what gets built.

Requests are recorded against the platform they name and the tally is the input to build order, so naming this vendor does register. It registers against a platform we have just spent a page explaining we could not usefully connect until something else exists, which is a strange thing for a vendor to publish and is precisely why it is published. A store deserves to know which of its asks is a scheduling question and which is an architecture question. This one is the second kind.

Compare that with the network where a connection genuinely exists and its gaps are still listed by name on the Meta page. Pricing for the platform is on the pricing page and does not change based on which networks you turn on.

Does LeadLocate integrate with LiveRamp today?

No. The published test for that status is that no adapter file exists in the ad gateway for this platform, and none does. There is no authorization URL, no checklist and no code path in the CRM that reaches this vendor.

Can I use my own LiveRamp account?

Not through the CRM, because there is nothing to attach it to and nothing to feed it. A group holding a contract with this vendor runs it in the vendor's own environment, fed from the systems that actually hold the records.

What happens if I request LiveRamp?

It is recorded against this vendor specifically and counted. The reply will separate the two halves honestly: an adapter is a scheduling question, and the export pipeline it would need is an architecture question that has to be answered first.

Can you upload my customer list as an audience anywhere?

No. We do not export a hashed customer list and we do not build a matched audience for any platform, including the one network carrying our connected status. There is no export in the product that produces such a file at all.

Why is the access class CERTIFIED?

Because a contract, a certification or a minimum spend commitment stands in front of programmatic access. That is the vendor's gate rather than ours, it is the strictest value in the vocabulary, and it is not an arrangement a software vendor enters on a customer's behalf.

Could you suppress my existing customers from ad targeting?

Not today. Suppression is built from the same exported audience file as targeting, so the absence that blocks one blocks the other. It is one of the two outcomes most stores are really asking for here and it is worth naming directly in a request.

Most stores asking about identity want to reach their own owner base or stop paying to advertise at people who already bought. Name that outcome and it goes on the tally where it can change something.