Integrations are an essential part of any ad tech vendor’s offering. Marketers and agencies need their many vendors and platforms to work together in order to give them holistic insight and control over campaigns. Those who don’t integrate with each other quickly become irrelevant to their customers.
The first step in any integration between two vendors is getting a contract. In addition to all the legalese about commercial terms and licensing, the contract should have some language on how the integration should be engineered. If a particular engineering approach is an absolute requirement for you (e.g. a certain encryption standard), it’s best to bring it up during contract negotiations, and work it into the contract.
Here’s a broad overview of what’s needed in order to ensure successful integrations, many of which may be mentioned in the contract:
-
Whose API?
At their heart, most integrations are about sharing data. Usually, it’s a question of whether Vendor A will pull data from Vendor B’s API, or vice versa. Understandably, each vendor will want their own API to be the conduit for the integration, since it will involve less engineering work for them.
Which vendor wins out often comes down to who has more market power. But even so, the “losing” vendor may not be able to support all the requirements of the “winning” vendor’s API, so both sides can expect to do some coding.
-
Security
If Vendor A is sending data to Vendor B, Vendor A will want some assurance that Vendor B is keeping that data safe, especially if it involves PII. Standard contractual provisions may require Vendor B to encrypt this data; to not commingle it with other parties’ data; and/or to delete it after a certain period.
-
Compliance monitoring
To ensure that the security provisions are being adhered to, there may be a provision to allow the one vendor to perform audits of the other vendor’s practices.
-
ID-mapping
Both vendors will have their own set of internal database IDs for the same advertisers and campaigns. The two vendors therefore have to agree on a way to ensure that they understand each other’s IDs (read more about this here). One approach would be to create a new, third set of IDs for both vendors to refer to when passing data to each other.
Another, simpler approach is to simply match data on names instead of IDs, since the name of an advertiser ought to be universal. (Vendor A and Vendor B can certainly agree that the name of Dentsu is Dentsu!)
Of course, the way the names are stored may vary between the two vendors (e.g. “McDonald’s” versus “McDonalds”), so some kind of fuzzy matching will be needed. Errors in matching may still occur, which leads us to the next item on this list.
-
Discrepancy management
A lightbulb factory may stamp out ten million perfect lightbulbs a day – but it will also stamp out a few defective ones every day, too. Even automated systems, however sophisticated, will make mistakes when running at massive scale. The important thing is to make sure the error rate is at an acceptable level. Vendors should agree on an acceptable threshold for the discrepancy rate, and on a process for monitoring that discrepancy rate and dealing with it if it ever gets too high.
-
Testing
Once the integration has been built, it should be tested with pilot campaigns before declaring it to be fully live. Fortunately, advertisers are often very eager to try out new technologies, even with the knowledge that there may still be some bugs.
-
Marketing
Now that all the pipes have been built and tested, it’s time to let the world know! You’ll want to coordinate messaging and timing with your partner.
While every vendor-to-vendor integration is unique, most of them are guided by the considerations given above. These key components should help integrations go smoothly, ultimately providing better tools, and better results, for customers.
