Why the ad stack and the business still don’t talk to each other with Ju-kay Kwek of Switchboard Software

Why the ad stack and the business still don’t talk to each other with Ju-kay Kwek of Switchboard Software

BY ROB BEELER, BEELER.TECH + JU-KAY KWEK, CEO OF SWITCHBOARD SOFTWARE

Google Ad Manager can tell you what happened inside GAM, but publisher revenue doesn’t live inside one system anymore. It sits across the ad server, SSPs, OMS, analytics, pacing data, curated marketplace activity,- and the decisions that run the business depend on seeing all of it clearly, in time to act.

That’s the problem I wanted to dig into with Ju-kay Kwek, CEO of Switchboard Software. Ju-kay spends a lot of time with publishers looking at the gap between the ad stack and operating the business: the place where signals exist, but no one’s seeing them together early enough to act. That gap is where revenue leaks and teams lose hours trying to determine whether they’re dealing with a real delivery issue, a data latency problem, or a reporting artifact.

What I appreciate about this conversation is that it treats these reporting shortfalls as an operational problem. Ju-kay gets into why reconciliation is still so manual, why threshold-based alerts miss the slow-moving issues that matter, and what changes when teams can normalize data across systems instead of forcing operators to connect every dot themselves.

We also talk about what publishers can uncover once the data’s finally connected, including examples from Switchboard’s work with The Weather Company, where unified monetization data surfaced open-market advertiser activity, revenue discrepancies between GAM and SSP data, and significant manual reconciliation work that had been absorbing team capacity.

The bigger point is simple: if your team can’t quickly tell whether a revenue issue is real or just a reporting artifact, the reporting setup isn’t giving you the full picture.

Rob: Publishers rely heavily on Google Ad Manager for reporting, but when revenue doesn’t line up, it’s not always clear why. Where does native reporting start to fall short?

Ju-kay: GAM is excellent at telling you what happened within GAM. It tells you impressions served, fill rates, CPMs, and revenue credited to demand sources in its own system. Where it falls short is the moment you need to reconcile across the rest of your stack – your SSPs, your OMS, your pacing data. GAM has no visibility into what OpenX or Magnite or Amazon TAM are reporting on the same inventory. 

When those numbers diverge, GAM can’t explain why. It also can’t tell you whether a revenue drop is a real delivery problem, a data latency issue, a pacing decision made upstream, or a reporting artifact. That interpretation layer is entirely on the operator.

Rob: A lot of teams spend time reconciling discrepancies across different systems. Why is that still such a manual, time-consuming process today?

Ju-kay: Each system reports on the same inventory using different logic – different time zones, different attribution windows, different definitions of a valid impression. 

There’s no industry standard for how an SSP reports a deal versus how GAM records it. So every reconciliation requires a human who understands the quirks of each platform to make judgment calls about what’s a real gap and what’s a definitional mismatch. 

Most teams are doing this in spreadsheets, pulling exports from four or five systems and manually comparing them. The problem compounds when you’re running multiple ad formats, multiple SSPs, and direct campaigns simultaneously. The data volume outpaces what any spreadsheet workflow can handle reliably.

Rob: You describe a “gap” between the ad stack and the reporting layer. What’s actually happening in that gap that leads to revenue being missed?

Ju-kay: The gap is where signals exist but no one is watching them in a connected way. A delivery issue might start as a small anomaly in one SSP’s fill rate at 2am – not significant enough to trigger a manual review, but meaningful if it persists across the day. By the time a team member pulls their morning report, the revenue has already leaked. 

The gap also includes cross-stack patterns that only become visible when you combine data sources. A curated deal quietly shifting spend away from a direct IO, for example, might look fine in both reports individually but represent a strategic threat when viewed together. Individual platforms report on themselves – they have no incentive or ability to surface what’s happening across the full picture.

Rob: When revenue issues do surface, most teams are reacting after the fact. Why is it so hard to catch these problems earlier?

Ju-kay: The core problem is that most monitoring is threshold-based – you only get an alert when a metric crosses a predefined line. But real revenue issues often don’t present as clean threshold violations. A slow degradation in CPMs, a gradual increase in unfilled impressions, a subtle shift in demand mix – these patterns are meaningful but they don’t trip a static alert. 

They require someone to notice a trend across multiple data points over time, which is exactly what manual monitoring can’t reliably do at scale. By the time the pattern is obvious enough to trigger a rule, the revenue impact has already accumulated.

Rob: Cross-stack signals are often fragmented: ad server, SSPs, analytics. What makes it difficult to connect those signals in a way that tells a clear story?

Ju-kay: Timing and schema. Each system operates on its own reporting cadence – some update hourly, some daily, some with a 24-48 hour lag. 

When you’re trying to correlate a fill rate drop in your ad server with SSP delivery data and analytics session volume, you’re often working with data that’s out of sync by hours or days. On top of that, each system has its own schema and naming conventions. The same advertiser might be referenced three different ways across three systems. 

Before you can ask “what’s causing this?” you have to answer “am I even looking at the same thing?” 

That normalization work is invisible, time-consuming, and usually has to be redone every time a platform updates its API or changes its reporting structure.

Rob: You’ve worked with publishers like The Weather Company on this. What did they uncover about their own reporting or workflows that surprised them?

Ju-kay: The Weather Company story is a useful illustration here. 

When their team unified monetization data across GAM, SSPs, and curated marketplace demand, one of the first things that surfaced was approximately $500K in open-market advertiser activity that had been distributed across demand sources in ways their existing reporting couldn’t see holistically. The data existed – it just wasn’t connected. 

Once it was, their team could identify which advertisers were transacting at scale in the open market and approach them about direct relationships. That’s a revenue opportunity that was invisible before, not because anyone failed to do their job, but because each system was accurately reporting on its own slice. The full picture only appears when you normalize across all of them.

The same unified foundation also revealed $1M in monthly revenue discrepancies between GAM and SSP data, and eliminated an estimated 50+ hours per month of manual reconciliation work that had been absorbing team capacity. You can read the full success story here.

Rob: There’s a shift happening from troubleshooting problems to trying to prevent them. What does that shift actually look like in practice for an ad ops team?

Ju-kay: In practice it means the team’s morning starts differently. Instead of pulling reports and scanning for what went wrong, they’re reviewing a prioritized set of signals that have already been filtered for operational relevance – anomalies the system has determined are statistically meaningful and not explained by known factors like campaign pacing or seasonal traffic patterns. 

The triage step shrinks dramatically. The operator’s judgment is still essential, but it’s applied to a much smaller set of real signals rather than a flood of noise. Over time, that shift changes the team’s posture from firefighting to pattern recognition – they start building institutional knowledge about what signals precede real problems, which makes the whole operation more defensible. 

The next step in that shift – one we’re already seeing demand for – is the senior operator skipping the dashboard entirely and asking the question directly in plain English, getting a trustworthy answer because the data underneath is already normalized and governed across the full stack.

Rob: If a publisher wanted to sense-check whether their reporting setup is giving them the full picture, what’s the first question they should ask themselves?

Ju-kay: Ask this: when revenue doesn’t match expectations, how long does it take your team to determine whether the problem is real or a reporting artifact – and how confident are you in that answer? If the answer is “hours, and we’re not always sure,” that’s the gap. 

A well-instrumented reporting setup, that looks across your business, not at silos of it, should be able to answer that question in minutes with high confidence. Most publishers, if they’re honest, can’t. But the ones who can? They’re not guessing. They’re operating on a connected picture – and that’s a competitive advantage hiding in plain sight.

👉Want to stay in the loop with what’s happening in the Beeler.Tech community? Subscribe to our newsletter. If you’re interested in attending or sponsoring a future event, you can explore our upcoming events here.

This is content created in paid partnership with Switchboard Software. We only feature partners who we believe bring real value to the publisher community.