Nepomuk Seiler
highfivve / Head of Engineering
Muki Seiler, chairman of the Prebid Documentation Committee, offers practical advice for vetting ad tech vendors, emphasizing the importance of clear change indicators in UIs, comprehensive documentation, individual user accounts, code review, and adherence to industry standards. He highlights that thorough vetting can prevent significant issues and ensure smoother integration and functionality.
How to vet your adtech vendors
I refrained from using a click bait headline “7 things you should do to vet your adtech partners!”. Still you will find some hands on advice, which I think publishers and adtech vendors should know about, when they are in the process of testing new technologies. This article is for techies and non techies alike. At the end you’ll find a list of positive things I witnessed, because if you want to make things better, you have to show what they might look like.
You should not feel scared to make changes
We all use and manage tech that is responsible for the monthly paycheck of other people. There are more critical tools than others: Messing up your CMP, e.g. the vendor list, may cause huge revenue losses. Archiving your AdX line item or uploading an empty ads.txt file will achieve the same.
If the tech you are looking at is having an UI where you can change things, you should be comfortable making changes. These following points bring me the most comfort:
- There’s always a clear indicator if my change is going to be live immediately or requires an additional step
- I can make changes and release them in a new version of my configuration. If anything goes downhill, I can revert back to my old version that was working
- I can preview changes, ideally on my live website, before putting them in production
- The UI guides me through complex changes and explains things on the way
Documentation
There’s no way I would ever work with somebody that has no written documentation whatsoever. Documentation is the contract for engineers that they rely on to integrate any tech. And I’m not saying this as the Prebid Docs PMC chairmen, but as an engineer with 10+ years of experience, who has tinkered around with APIs enough.
Documentation alone is not enough, though. There are some quality checks I use to vet a vendor’s documentation:
- Is it public? In my opinion there should always be a public part of the documentation to get a feeling of how much effort it would be to integrate it.
- Is it online? PDF or .docx files tell me that you are a company that provides web technology, but is not able to put up what is basically a blog. Also files don’t update themselves and the documentation gets outdated. Sharing a link is also much simpler than a file
- Are there examples? If I have to choose, I would always pick a documentation with examples rather than plain API documentation.
Multiple user accounts
If you can make changes, you need accounts per user. This is crucial for
- Auditing: who did the change?
- Debugging: find the person to ask why a change was made
- Permissions: lower privileges, means less risk that somebody breaks something
- Offboarding: remove accounts from former employees
Unfortunately, this is not always the case. There are plenty of systems where we have a “teams account” that is shared with everyone. This means, the entire team is an admin. It doesn’t take malicious intent to break a system, when you can do anything.
Read the code
This one is for the engineers and I can highly recommend it. If possible, read the code of the integration. Luckily, the code that’s closest to the user, javascript, is always available in some form.
- Open Source – e.g. prebid adapters or modules
- Minified as a script tag – either put directly on the page or fetched at runtime (e.g. pubads_impl.js)
- Unminified script tags – if the js file is named like xyz.min.js, try removing the min and you will be surprised how many tech vendors publish their unminified javascript code (with comments) publicly.
What I usually look for are the following things:
- TCF API integration Is there any sort of consent handling? Does it use non-deprecated APIs? What does it check? Search for __tcfapi and you find the calls
- Prebid integration Are there any calls to pbjs? Especially the setConfig API is dangerous, as it may override existing settings. Calls to requestBids are also suspicious if the technology is not supposed to trigger auctions
- Google Publisher Tag (gpt.js) integration The same applies as for prebid. Any configuration (googletag.pubads()) calls should be understood and checked against your current setup.
- Event Listeners Browsers have a ton of events to hook into. Make sure you know which one the javascript code uses. It can range from privacy sensitive (listening to keyboard events) to performance critical (mouse move event).
- Outgoing network requests Some tech may need to call home. If you have the option to test a live variant of the script, you can check the network tab in your browser dev tools, where requests are being made and then find the place in the code. Sometimes this opens avenues, where the client side javascript is completely obsolete, because it’s only configuration, consent and an API request.
A tip on minified code. Copy it in your favourite IDE and use the rename/refactor function to name variables and functions if you have guessed the meaning. The code often becomes more readable quite quickly.
sTANDARD cOMPLIANCE
There are a lot of standards in adtech, but there are quite few for each use case. The folks at IAB and Prebid have managed to standardise quite a lot. Still there are tech vendors that follow this classic XKCD
If your partner operates on OpenRTB, that’s great! It means their endpoints can potentially work in every environment; Web, App, Audio, DooH. There’s plenty of documentation and tooling around this standard and it still has extension possibilities to accommodate for special use cases.
The TCF standard was a milestone, especially for publishers. And it showcases why standards are so vital for a competitive marketplace. As a publisher, I can switch to a CMP with relatively low effort – thanks to TCF. As an advertiser, I have to register in one place and not talk to every CMP out there.
The less your adtech partner is compliant with existing standards, the more cautious you should be. You need your own javascript on the page to do user syncing? Why don’t you have a Prebid user id module? What’s this custom taxonomy that basically looks like the seller defined audiences? Every non-compliance means more integration work, more maintenance, more room for errors, and less interoperability.
View the original article here