Lucidity’s Tech Is Putting Supply-Path Optimization In The Hands Of Media Buyers

Buyers increasingly want transparency into their programmatic buying. But undertaking the project of requesting log-level data from exchanges themselves requires resources many brands don’t have. Lucidity wants to be the tech solution to demystify and audit the programmatic supply chain.

Lucidity stitches together information from the buyer’s ad server (where it inserts its own pixel), the DSP, the ad exchange and the publisher. Then a media buyer can look at a dashboard that shows them all the ways the impression they thought they bought differed from what was actually delivered.

This approach gives media buyers access to insights derived from log-level data – but without the hassle of RFIing exchanges and the cost of doing it yourself.

“We’re bringing this to market at scale to reduce costs for each party,” said Lucidity CEO Sam Kim. “We’re excited to bring log-level data analytics not just of the largest brands, but also to the downstream brands.”

Kim talked to AdExchanger about Lucidity’s tech, the demise of competitor Ad/Fin, and how Lucidity uses blockchain.

AdExchanger: What does Lucidity do?

SAM KIM: We are trying to create a unified view of an impression across the programmatic supply chain – the provenance of an impression – to ensure that the impression was delivered in a manner the advertiser requested or required. For example, that the impression ran consistently through the ad server all the way to the DSP and the exchange. And that the ad ran on the bid the advertiser won, including correct placement and ad format.

How are you technically able to track where ads run?

We’re ingesting log-level data from the exchange and the DSP, as well as our ad serving pixel. And we are able to track and create a unified ID for each impression and match it across the supply chain.

There are breakages in the supply chain, where the DSP doesn’t match the exchange data, or maybe the exchange data doesn’t match what’s in the pixel. We consider those non-matches. We identify supply paths that create poor matches. One publisher might have a great match in one supply path, and a less efficient one with the other. 

What causes poor matches?

It could be anything from fraud to auction manipulation to breakages in the supply chain. Mobile app being flagged as display would be an improper match. It could be bot traffic, where they are using the same auction ID multiple times. Bid caching would get flagged.

Does ads.txt and sellers.json make your tech redundant? Or add to your offering?

We match against ads.txt and sellers.json. We think they’re great, but there are still lots of vulnerabilities in there. They can help with domain spoofing, but there are still types of inventory misrepresentation that can persist even with these two standards.

What else can’t these standards catch?

They also can’t handle click injection, like multiple clicks off a single auction ID. And we can also surface those insights in a dashboard.

How do you stitch together all this information in a privacy-safe way?

We do not have cookies or device IDs or any identifiers. We are just ensuring the impression flows through.

What’s your pricing model?

 We have an SaaS-base pricing model based on volumes. There are two ways we justify our value. First is just the operational improvement of doing reconciliation in real time. Second is delivering insights to media buyers. We see a significant boost in campaign performance in advertiser KPIs.

What do buyers do when they see something amiss?

If it’s suspect inventory, they can blacklist it, or choose a supply path to the publisher that’s more optimal. Media buyers have also reached out to publishers because they wanted the inventory, asked them to look into it and it was an integration issue [behind the discrepancy].

It’s powerful to see what happens when you cut out a few discrepant placements: We’ve consistently seen improved upper-funnel campaign performance resulting from cutting out sites with low match rates for impressions and clicks in large-scale programmatic campaigns. When advertisers flag discrepancies and quickly move campaigns away from flagged sites, they enjoy better performance before it’s too late and the campaign is over.

Ad/Fin just went out of business. What does that mean for your peer group?

The antagonistic approach wasn’t enabling agencies to do their job better. It’s not the fees that are important to improve the media buying functions. It’s making sure the advertiser is getting what they are paying for.

We’re different. We’re focused on media measurement and accuracy rather than fees.

But isn’t fee information often a key goal of the brand?

We haven’t had brands request that we look at fee transparency.

Are you doing a Trade Desk-like model where you’re just working with agencies?

We’re partners to the agencies, [to] enable them to improve their clients’ brands, and improve the media buying function at the agency level.

We have done test campaigns with nearly every agency holding company, and are in the process of shifting to longer-term contracts and partnerships. In some instances, brands have centers of excellence focusing on supply-chain transparency and will reach out to us first and then introduce us to their agency.

The word blockchain hasn’t come up yet. But the homepage of your website describes Lucidity as “blockchain-audited media.” Why not bring it up?

We don’t think we need to talk about it so early on. Blockchain allows us to transparently confirm if the impression is valid or not. We do that by a transparent contract that sits on top of our blockchain. We write data onto the blockchain so it is immutable and can’t be manipulated.

The value proposition we bring to the table for the media buyer is independent of the blockchain. They don’t want to work with us because of blockchain, they want to work with us because they get value.

This interview has been edited and condensed.

 

Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>