Zemanta Integration for Car Dealers

The programmatic tier of a native account relationship, and a precise account of what is wired and what is not.

Zemanta is a demand side platform, now part of the same commercial family as the Teads and Outbrain offering. Instead of buying placements on one network's publisher roster, it bids into more than fifty supply sources at once, covering native units, standard display and video across a very large share of the open web.

The difference from a native network matters for a dealership. A native buy is a product: headline, thumbnail, click, one roster of sites. A demand side platform is a buying tool. You bring the audience definition, the inventory rules, the frequency caps and the creative sizes, and the system goes shopping across every source it is connected to. That is more reach and considerably more decisions.

For most stores this is the advanced tier rather than the starting point. It is the sensible answer when a group has already learned what works on a single native network and wants the same message carried across the open web at scale, without signing the enterprise contract that a traditional trading desk requires. It sits in the same conversation as programmatic display advertising for dealers rather than in the same conversation as a recommendation widget.

The case is scale without a trading desk. A dealer group that wants one message across native, display and video, with real frequency control and one reporting surface, would otherwise be quoted an enterprise platform contract and a percentage of media. Buying programmatically through an existing account relationship removes most of that overhead, and the API is unusually approachable compared with the incumbents.

The first honest objection is that a demand side platform gives a store enough rope to do real damage. Open exchange inventory contains everything nobody curated out, and the defaults are not friendly to a brand that a manufacturer audits. Inventory lists, category blocks, viewability floors and frequency caps are all the buyer's responsibility here, and they are not optional work. A store that would not read a placement report should not be buying programmatically at all.

The second objection is measurement. Programmatic display earns its keep through view through effects and reach, and a channel whose value is partly unattributable is a difficult thing to defend in a monthly meeting against a search line item with clean numbers. The honest framing is that this is a reach instrument, and it belongs in the awareness half of a dealership advertising plan. If your question this month is where the next twenty leads come from, the answer is not here.

The third is the gate. Access here is not open, which is covered next, and a single rooftop store may simply not clear it.

Registered, not yet built. The published test is an adapter file in the ad gateway with a written wire-up checklist, committed and scoped, and this one carries five steps with no working lifecycle methods behind them. Every call it receives returns a refusal that names the network rather than a silence a dealer might mistake for success.

Access class is PARTNER, and that is the vendor's gate rather than ours. Credentials are issued through the parent account relationship after an application the vendor reviews, so even with a finished adapter a store would still need that relationship approved before anything could run. Naming that step is the point of separating access from status. If we folded them together, this page would say only that the platform is not available, and a dealer would not know which of the two obstacles applies to them.

There is a second consequence of the shared account relationship. The credential path here runs through the same commercial arrangement as the native network in the same family, so building that network first shortens this one materially. Build order in this family is a dependency chain, not a preference.

A design, since nothing here runs today.

Lead capture is clickout. There is no form inside the unit, so an opt in requires a landing page and one of the forms already living in the CRM. On a channel bidding across many supply sources, the source level breakdown row is the one that decides whether the buy is manageable.

A demand side platform is not treated as a different species inside the CRM. It answers the same contract as every other network.

One library defines what any advertising platform must be able to do: hand us an authorization URL, exchange the credential for a usable token, list the accounts that credential reaches, 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 uniformity is why a platform with a far larger surface area than a native network still amounts to a five step checklist here: we implement the seven operations the CRM needs, not the whole vendor API.

Tokens are encrypted using AES-256-GCM before storage. Every action against any network is written to an append only audit log carrying the company, the network, the user and the detail, stamped in UTC because the table is shared across dealerships and a company local timestamp cannot be reconciled afterwards. Campaign objects record which credentials created them and re-resolve those same credentials later, so a group that disconnects one account does not strand the campaigns built beneath it. On a platform where the credential comes through a partner relationship that could change hands, that last property is worth more than it sounds.

Two ways to advertise through LeadLocate, and the store decides which.

The first is the webXintel Ads Network. Included, built and operated by our team from the selections you make in Leads Manager, billed as one line instead of a stack of platform statements. No application to file, no credential to hold, and no exchange level decisions to make.

The second is your own account. Connect the account your group already holds and campaigns route through it, on your billing, in your name, with your terms and your history intact. On a partner gated platform that route assumes you already have the relationship or are prepared to apply for it, and that application is the vendor's to grant.

One boundary stated plainly: deploying, activating, pausing and reading spend is done by our team today, not from a control on your dashboard. That is deliberate while the connection layer is young, and it is on the list to open up rather than in the product.

Five ordered steps, with an application in front of them. Establish the account relationship and obtain a reviewed credential. Fill the credential block and enable it. Implement account listing and campaign creation. Implement budget, bid and status changes. Implement reporting with supply source breakdowns and the verification call.

The first step is the one that is not ours. The vendor reviews the application on its own timeline and against its own criteria, and no amount of engineering on this side shortens it. Everything after it is work we control, which is why the status here is registered rather than unavailable.

Minimum spend follows the parent account terms rather than a published self serve floor, so it is a negotiation rather than a number, and any figure printed on a page would be wrong for somebody. Ask for it in writing when the relationship is set up.

On timing, clicks arrive within hours of a campaign going live and meaningful lead counts take two to five days. Reach and frequency effects take longer than either and will never resolve into a clean same day number. That is a description of how quickly the channel becomes readable, not a forecast of volume, and treating a programmatic reach buy as a lead counter is the standard way stores end up disappointed by it.

The specific gaps, because a demand side platform invites the most generous assumptions in this directory.

We do not emit a vehicle catalog or an inventory feed. Dynamic vehicle creative on a programmatic buy runs off a product feed, and no code in our stack generates one for any advertising platform. This is the gap most likely to be assumed away on a page like this, so it is stated first.

We do not run a server side conversions API. No server side events, no offline conversion upload, no pixel installation or management. A demand side platform optimising toward conversions needs a signal, and we do not send one.

We do not export a hashed audience file. No customer list matching, no suppression list upload, no lookalike seeding. Audience activation from your own data is a normal expectation of a platform in this category and it is not something we do.

We do not operate a trading desk. Inventory allow lists, category blocks, viewability thresholds and frequency policy are decisions somebody has to own, and a finished adapter would move campaigns, not judgement.

No campaign has ever been deployed here from the CRM, because the code does not exist and the credential has not been issued.

Ask for it by name, with your group, your rooftop count and the reach problem you are trying to solve. Requests are recorded against the platform they name and the tally sets build order, because a dealer ready to fund a channel is a better signal than an internal ranking of logos.

Two things make this request stronger than most. If you already hold the parent account relationship, say so, because it removes the vendor gate from the critical path entirely and turns this into pure engineering time. And if you are asking for the native network in the same family as well, say that too, since the credential work overlaps and two requests that share a dependency move faster together than either does alone.

The managed path runs today and waits on none of it. Platform pricing is on the pricing page and does not change with which networks you enable.

Does LeadLocate integrate with Zemanta today?

No. It is registered in the ad gateway with a five step wire-up checklist and no working lifecycle methods, and every call the adapter receives returns a refusal that names the network. Credentials would also require a vendor reviewed application before anything could run.

Can I use my own Zemanta account?

Not through the CRM yet, and there are two separate reasons. The self connect code is unbuilt, and access is partner gated, so a credential comes through an account relationship the vendor approves. If you already hold that relationship, only the first reason applies to you.

What happens if I request Zemanta?

It is recorded against this platform specifically and counted, and the count feeds build order. A person replies with a range or a reason. Mentioning an existing parent account relationship changes the answer, because it removes the part of the timeline we cannot influence.

What does partner access actually mean for my store?

It means the vendor decides who gets credentials, using an application it reviews. That gate is theirs, not ours, and it exists whether or not our adapter is finished. Small single rooftop stores are the ones most likely to find the managed path a better fit.

Is this better than buying one native network directly?

Different, not better. A native network is a product with one publisher roster. This is a buying tool bidding across many supply sources, which brings reach and also brings inventory quality decisions that somebody at your store has to own.

How would I judge a programmatic buy without a conversion signal?

By reach, frequency and the traffic it puts on a landing page, measured against CRM sourced leads over a window you fix before launch. What you cannot do is compare it line for line against search on same day attribution, because the two channels are answering different questions.

Requests are counted against the platform they name and the count sets build order. Tell us your group, your rooftops and whether the parent account relationship already exists.