"Data-Driven Thinking" is written by members of the media community and contains fresh ideas on the digital revolution in media.
Today’s column is written by Bradley Timmers, senior product manager at Integral Ad Science.
Ninety percent of ad tech is just matching IDs to strings. Or that’s how it feels some days.
One of the joys of working in ad tech is getting to interact with so many other companies. But the price is you must somehow map your company’s IDs to everyone else’s IDs.
How do Company A and Company B know they’re talking about the same cookie, device or designated market area?
The problem is that every ad tech vendor has its own internal IDs for advertiser, campaign and so on. While every vendor could share a dictionary of its IDs with every other vendor, this is not realistic, as anyone who’s ever looked at a LUMAscape can tell you. There are many, many vendors in the industry, and each one inevitably needs to work with each of the others at some point.
What we need is an established standard where we all agree to use one particular set of IDs. Fortunately, we do have a kind of standard today as most in this space use the IDs from the advertiser’s ad server. This makes plenty of sense, given the central role of the ad server to a campaign’s delivery.
Ad servers for their part have been supportive in their role as “keeper of the standard IDs.” For every impression, they pass the values of their IDs down the delivery chain, from one ad tech vendor to the next, via the mechanism known as “macros.”
The problem lies in knowing the meaning of the IDs. The ad server may tell you the advertiser for this impression is 11981, but who is that? Only the ad server knows.
The question then becomes how do the meanings of the ad server IDs get communicated out to the rest of the ad tech ecosystem?
If You Didn’t Get My Mapping File, Check Your Spam Folder
The sad truth is that sharing the meanings of ad server IDs from one vendor to the next is mostly a manual process. The advertiser extracts the IDs from the ad server into a spreadsheet and emails that spreadsheet to the other ad tech vendors supporting its campaign. The vendors then map those IDs to their own IDs, using the spreadsheet as their Rosetta stone.
No one is a fan of emailing spreadsheets. Why can’t the other ad tech vendors just query an ad server’s application program interface (API)?
For instance, if a company’s pixel serves on an impression with the advertiser ID macro set to 11981, can’t the company just query the ad server’s API? It could send to the ad server the number 11981, which is meaningless to the company, and the ad server would send back the name of an agency.
The good news is that most, if not all, ad servers have APIs. The bad news is that access to them is usually limited to their paying customers, meaning only the advertisers. So the other vendors are out of luck.
Sharing The Wealth
This is more of a business problem than a technological one. I can imagine a master services agreement between an advertiser and ad server that extends access to the ad server’s API to all other vendors participating in the advertiser’s campaign.
I can also imagine each vendor having a single permanent login to an ad server’s API. Someone at the ad server or ad agency would then grant that account access to the relevant campaigns within the ad server, rather than creating a brand new account for the same vendor with every new campaign. If the vendor ever requested information for IDs that are part of a campaign they’re not working on, the API would return the appropriate error message to them.
APIs are clearly preferable to spreadsheets that are created, sent and processed manually. The meanings of ad server IDs are not a secret. Every day, these mapping files are passed from hand to hand, and company to company. Ultimately, for an advertiser’s campaign to be successful, it needs all of its supporting vendors speaking the same language when it comes to IDs. A more open API policy for ad servers would be a huge win for all involved.