If you work in CTV ad operations, you have almost certainly lived the following scenario. Your ad server is from one vendor. Your supply-side platform is from another. Your demand-side platform is a third, your data management platform is a fourth, and your analytics layer is held together by a custom integration that one engineer built two years ago and nobody else fully understands. Welcome to the Frankenstack.
The Frankenstack is not the result of poor planning. It is the natural outcome of a market that matured in fragments. Each component of the ad tech stack was developed by different companies solving different problems at different times. Publishers adopted best-of-breed solutions for each layer, and for a while, this approach seemed reasonable. But as CTV advertising has scaled in complexity and volume, the cracks in the Frankenstack have become fissures, and the cost of operating a fragmented stack is no longer just an inconvenience. It is a competitive disadvantage.
Anatomy of a Frankenstack
A typical fragmented CTV ad tech stack includes four or five core components, each from a different vendor. The ad server handles decisioning and delivery. The SSP manages programmatic supply and yield optimization. The DSP connects to demand sources. The DMP collects, segments, and activates audience data. And somewhere in the mix, there is usually a reporting or analytics tool trying to stitch together data from all of the above.
Each of these vendors has its own contract, its own login, its own data schema, its own API conventions, and its own roadmap. Each integration between systems requires custom development and ongoing maintenance. And each boundary between systems is a point where data is lost, delayed, or transformed in ways that introduce inaccuracy.
The result is an architecture that looks functional on a diagram but operates with significant friction in practice. Ad ops teams spend disproportionate time reconciling data between systems. Engineering teams spend cycles maintaining integrations instead of building product. And the business loses revenue in the gaps between platforms.
The Hidden Costs of Fragmentation
The most obvious cost of a Frankenstack is the engineering overhead required to keep everything connected. But the less visible costs are often more damaging.
Integration maintenance is a tax on velocity. Every time one vendor in the stack ships an update, there is a risk that it breaks an integration with another vendor. Publisher engineering teams become integration babysitters, spending their time ensuring that systems talk to each other rather than building features that drive revenue. This is not a theoretical concern. It is a weekly reality for most CTV publishers operating fragmented stacks.
Data loss between systems is invisible and cumulative. When audience data moves from a DMP to an SSP, some fidelity is lost. When bid data moves from an exchange to a reporting tool, some granularity disappears. Each hop between systems introduces small losses that compound over time. Publishers rarely see this happening because each system shows its own version of the truth, and no single system has the complete picture.
Conflicting optimization creates a tug of war. When the SSP optimizes for yield and the ad server optimizes for delivery, their goals can conflict. The SSP might want to hold an impression for a higher-paying programmatic bid, while the ad server needs to fulfill a direct-sold guarantee. In a fragmented stack, resolving these conflicts requires manual intervention or rigid rules that leave money on the table. In an integrated platform, these decisions are coordinated automatically.
The Latency Tax
In CTV advertising, latency is not just a user experience problem. It is a revenue problem. Every millisecond added to the ad decisioning process reduces the number of demand partners who can respond with a bid, which reduces competition, which reduces CPMs.
A Frankenstack is inherently slow. When an ad request originates from a player, it hits the ad server, which makes a call to the SSP, which sends bid requests to exchanges, which forward them to DSPs. Each hop adds network latency. Each system adds processing time. In a fragmented stack, the total round-trip time from ad request to ad response can exceed the timeout thresholds of many demand partners, meaning those partners never even get the chance to bid.
Every hop between systems adds latency, and every millisecond of latency costs you demand partners who time out before they can bid. In CTV, where CPMs are measured in tens of dollars, even a small reduction in bid density has a material impact on revenue.
The latency tax is particularly punishing in server-side ad insertion environments, where the entire ad break must be stitched together in real time. Publishers with fragmented stacks often resort to reducing the number of demand partners they call or increasing timeout thresholds, both of which are suboptimal compromises that an integrated platform eliminates.
Data Fragmentation: The Silent Revenue Killer
Perhaps the most damaging consequence of a Frankenstack is data fragmentation. When audience data lives in a DMP, transaction data lives in an ad server, and bid data lives in an SSP, building a complete picture of any single viewer or impression requires stitching data across systems. This is technically difficult, operationally expensive, and often impossible to do in real time.
The practical impact is significant. Audience segments built in the DMP cannot be seamlessly activated in the SSP. Campaign performance data from the ad server cannot be easily correlated with programmatic yield data from the SSP. And the publisher's sales team cannot see a unified view of inventory availability, audience composition, and pricing that would allow them to sell more effectively.
Data fragmentation also limits the effectiveness of machine learning and AI-driven optimization. Algorithms are only as good as the data they can access, and when that data is spread across four or five systems with different schemas and update frequencies, the algorithms are working with an incomplete and stale picture. A unified data layer, by contrast, gives optimization algorithms access to the full signal, which translates directly into better decisioning and higher revenue.
The Full-Stack Advantage
A full-stack platform addresses each of these problems by design. When the ad server, SSP, DSP, DMP, and analytics layer are built as a single integrated system, the boundaries between components become internal interfaces rather than external integrations. Data flows freely between layers without loss or latency. Optimization is coordinated across the entire stack. And the publisher operates from a single source of truth.
The advantages are concrete and measurable:
- Unified data. Every piece of data, from audience attributes to bid responses to delivery metrics, lives in a single system. There is no reconciliation required, no data loss between systems, and no delay in data availability. This enables real-time optimization that is simply not possible with fragmented stacks.
- Single integration point. Publishers integrate once with the platform, and the platform handles all downstream connections to demand partners, data providers, and measurement vendors. This dramatically reduces engineering overhead and speeds up time to market for new features and partnerships.
- Coordinated optimization. When the ad server and SSP share the same decisioning engine, direct and programmatic demand can be evaluated simultaneously. The platform can make holistic decisions about which ad to serve based on the full picture, maximizing revenue across all demand channels without the conflicts that arise in fragmented stacks.
- Lower latency. Internal function calls are orders of magnitude faster than external API calls. A full-stack platform can complete the entire decisioning process, from ad request to bid evaluation to creative selection, in a fraction of the time required by a chain of separate systems.
When Does Integrated Beat Best-of-Breed?
The best-of-breed argument has merit in some contexts. If you are a massive publisher with a dedicated engineering team of fifty and the resources to build and maintain custom integrations indefinitely, a carefully curated best-of-breed stack can work. The flexibility to swap individual components and the ability to negotiate enterprise-level terms with each vendor can offset the integration overhead.
But for the vast majority of CTV publishers, this is not realistic. Most publishers have small ad ops and engineering teams. They cannot afford to dedicate significant resources to integration maintenance. They need a platform that works out of the box and improves over time without requiring constant intervention. For these publishers, and they represent the overwhelming majority of the market, an integrated full-stack platform is the pragmatic and economically superior choice.
The calculus is straightforward: the revenue gained from coordinated optimization and reduced latency almost always exceeds the theoretical benefit of having the absolute best individual component at each layer. A well-built integrated platform that is ninety-five percent as good as each best-of-breed component will outperform a Frankenstack where each component is individually excellent but collectively hamstrung by integration friction.
How Shigo Approaches Full-Stack
Shigo was built from the ground up as an integrated platform, not assembled through acquisitions or bolted together over time. The SSP, DSP, DMP, and AI optimization layer share a common data model, a common decisioning engine, and a common interface. This means that audience data is available at the point of ad decisioning without an external lookup. It means that supply and demand optimization happen in the same process, eliminating the latency and data loss of cross-system calls. And it means that publishers get a single, coherent view of their business.
Critically, Shigo's full-stack architecture does not mean a closed system. The platform is designed to interoperate with the broader ecosystem, connecting to external demand partners, measurement vendors, and data providers through standard protocols. The integration reduction comes from consolidating the core stack, not from cutting off the outside world.
Making the Migration
For publishers currently operating a Frankenstack, the prospect of migrating to an integrated platform can feel daunting. Years of custom integrations, institutional knowledge embedded in workflows, and contractual commitments to existing vendors all create inertia. But the migration does not have to happen all at once.
The most successful transitions follow a phased approach. Start by consolidating the components with the highest integration overhead, typically the SSP and ad server. Once those are unified, layer in the DMP and audience capabilities. Finally, activate the DSP and AI optimization features. At each phase, the publisher gains immediate benefits from reduced complexity and improved data flow, which builds confidence and organizational support for the next phase.
The key question for any publisher evaluating their stack is not whether their current setup works. Of course it works; they have spent years making it work. The question is what it costs them in engineering time, in lost revenue from latency and data fragmentation, and in opportunity cost from features they cannot build because their team is busy maintaining integrations. When publishers honestly assess those costs, the case for an integrated platform makes itself.