Tim Abraham, Adbrain, director, data platforms, discusses the choices facing advertisers when faced with the prospect of choosing which ad tech providers to partner with. 

Selecting the right technology partner is one of the most challenging prospects facing media businesses today, time and time again I’ve had people ask me: “Who would you go with?” And my answer is always the same - it depends, take a seat.

Decisions, Decisions

Increasingly the decision facing all businesses close to either side of the notorious lumascape is the same as I faced in previous career stints (at outfits like Xaxis, GroupM and AOL). This is a choice over partnering with standalone products (plugging into existing solutions) versus developing equivalent functionality (in-house or from existing partners).

The decision is harder for services that aren’t simple. As I think most readers can attest to the lure of a product that delivers an awesome piece of functionality can rapidly be outweighed by integration costs. This includes training, education and context switching costs (logging out of one platform into another).

This is particularly true for optimisation/attribution where the products act as a 'master' component which provides execution instructions to a 'slave' component. For example, an optimisation solution may identify that users on site X, in audience Y, at a frequency of Z are highly performing.

This optimisation 'master' then sends a signal to some 'slave' ad server in the assumption that the ad server can interpret and action those optimisation instructions while in fact there is no structural reason why this is the case at all. All too often we see products that are high value in isolation but don’t interface into activation layers effectively, meaning heavy development work is required in order to use product thus diminishing its attractiveness.

On first look therefore it seems that standalone products create integration costs and the combined value with the pre-existing stack is constrained by its parts, rather than being the sum of them. The good news is that this risk is reduced for products and businesses that are natively built with API connectivity between components (not just API 'afterthoughts'). These are the businesses that will be successful in interfacing new components with those already in place - businesses such as BannerConnect and Grapeshot have proven this with their work integrating to the AppNexus ecosystem.

Going for the Full Stack

For the full stack alternative the customer partners with a single provider and relies on them to emulate the best of new siloed products. The overwhelming advantage of this solution is operator usability and decision making fluidity – being able to use a tool effectively can be more important than having the best tool available.

Furthermore, businesses committed to a single stack are also more able to focus and execute since there is less time spent evaluating and contracting with competing products. Of course, there are also some pitfalls and key areas to consider in adopting a full stack approach.

The most obvious question is how long it takes for a single full stack provider to 'catch up' with competing products and what motivation they have to do this (consider an agency/client model where the agency is contracted to delivering 'media firsts'). Less obvious but at least equally as important is the question of incentivisation.

Businesses need to ensure that their success is closely aligned with the success of their stack provider. For example a full stack vendor providing a technology solution to customer A and a media business to customer B can readily cause a conflict of interests in both campaign execution and roadmap prioritisation.

Another key question to ask is what extent the customer will enjoy data and identification portability - does the customer own all of their data, can they take it with them, can they identify users on their partner platform in their own first party data sets?

Take Aways

In summary there are a few key points to consider when deciding between the full stack and individual products:

Product Solution

1)  Beware of integration costs - not just technical but also training, education and  context switching

2)  Beware master/slave constraints

3)  Look for products that use API layers within their own stack

Full Stack

1)  Understand what influence you have on the partner’s roadmap, are they directly incentivised to provide feature parity

2)  Choose a provider with broadest coverage of features with reasonable functionality

3)  Beware conflicts in incentivisation for technology providers that are also media businesses

4)  Look for data portability and clear policies on how data will be used

In truth, many businesses will benefit from a core stack provided by one flexible and well-incentivised provider. This can then be enriched with a handful of product solutions if required but only if they are engineered to allow flexible integrations (typically by having API layers baked in from the ground up).

On a final note, the choice between full stack vs product 'problem' is borne of innovation, change and progress, and for many of us this is the reason we remain so enthused and interested in the industry today. The wealth of choice in the market shouldn’t feel like a burden, technology is the foundation for a differentiated service layer and ultimately this is what will set agencies apart in today’s landscape.