How we implemented zero-code DSP onboarding at MiQ

Chandrahaas Uniyal, Senior Product Manager, MiQ

The number of DSPs in the digital marketing ecosystem keeps growing, with each one offering something unique across inventory, cost models, channels, or user experience. Programmatic traders, also known as buyers, can optimise their campaign executions to benefit from the unique features offered by each of these platforms. Having expertise in multiple platforms also helps an organisation become a one-stop shop for clients. However, choosing between many DSPs can create a few challenges:

At MiQ, we explored these challenges and realized that traders wanted to be able to:

1. Visualize all the data from all the DSPs in one place
2. Use multiple platforms without spending more time monitoring campaigns

We decided to tackle the visualization first, looking for solutions that would allow our buyers to view all their campaign data from all platforms in one place, as well as allow them to compare the performance of each platform.

At its core, this sounds like a simple request; bring data in from different platforms and then process for aggregation. Our early solutions were already doing this. But these were written to manage only a couple of DSPs and were very specific to each. As MiQ expanded to work with more channels, formats and regions, we had a stream of requests to onboard new DSPs and new accounts of existing DSPs (also known as seats). We realised that this approach was unsustainable — we couldn’t build a different solution for each new platform requested, so we decided to rethink our method.

Changing our approach

We needed a system where a new DSP or seat could be onboarded quickly, without requiring unique code, and meet both the time-saving and visualization requests from our traders. We set a goal of building a system where a new DSP could be integrated without writing any new code, and without any technical know-how. This was ambitious because:

1. There was no consistent nomenclature or schema between DSPs, nor did they all offer the same information.
2. A lot of other tools were using naming conventions, but that usually didn’t scale well. Errors were harder to find and they all needed an admin team to manage DSP data.
3. Not all DSPs offered robust APIs or data exports for the volume of data we were looking at.

Besides, most tools in the market were targeted towards smaller local agencies. So things like multi-currency and multi-time zone support were hard to achieve. We took lessons from all this analysis and started building our new system.

Developing a solution

We began by creating a normalised schema that would work for any DSP in the market. We created an extensive hierarchy of objects to cover the most complex use cases and then started simplifying it. For the objects that didn’t have a direct map to a particular DSP, we created a mechanism to handle blanks or fill them with mock objects. Then we created two modules:

• One to extract data from any DSP. This was done by building connectors for each DSP available.
• Another is to transform the DSP data to MiQ’s normalised schema.

The key components explained

Connectors: These are small scripts that are “read-only integrations” with DSPs. They support APIs or file exports or email extractors.

Meta data store: This is data that describes DSPs. Things like logos, URLs, credentials, labels etc.

Transformation layer: This is processing code that can identify columns in DSP data and map it to our normalised schema. Unlike some other tools, this doesn’t need to be done every time there is a new DSP account to be added. It supports multiple currencies and timezones out of the box. And doesn’t need an admin to maintain.

Normalised data store: Our big flat data. Here all the DSP data is available in a singular, uniform format for our other applications to read from. It works at the smallest grain and is aggregated as and when required. There are strict data health and recency checks that are carried out every few hours to keep our data accurate.

All these processes or pipelines work continuously to bring the most recent data to our systems. We support SLAs that cover all our regions to have data in their latest recencies.

Success

The operational gains that this solution has brought to MiQ cannot be understated. Our previous approach of building specific solutions for each DSP caused huge delays for traders and clients. And we knew that DSPs have different strengths, proprietary inventory and data sets — with some even biased towards their own inventory or supply paths — meaning having access to multiple DSPs typically drives better campaign performance.

MiQ differentiates itself from other programmatic media partners through being partner agnostic and tech enabled — our zero-code DSP onboarding process underlines this. With our new approach, we have 100% coverage to the DSPs we use. We’re able to build campaigns best adapted to reach the advertiser’s goals in an unbiased and agile way, driving optimal performance. By supporting regional teams on deals that are very specific to them, as well as onboarding larger DSPs globally and smaller ones in emerging markets, we’ve encouraged growth as well as sustenance.

But we’re not finished. We’re taking the lessons we’ve learned from this process and building a common language to activate, so buyers can take advantage of unique DSP activation capabilities, without writing any new code.