Incrementality Infrastructure: What It Is and How It Works

In 2025, I started noticing a change in the expectations of brands looking for new marketing measurement solutions.

Instead of deep-diving into how our UI can support their measurement use-cases, their first requirement was a daily feed of campaign & ad set level iROAS (incremental return on ad spend) delivered into their own data warehouse. Their marketing team already had an established workflow for spend optimization. In that workflow, they wanted to replace attributed ROAS with incremental ROAS, with the results available by an agreed time.

That changes the role of the incrementality measurement provider. The brand is making its existing optimization process more informed by incrementality, while retaining control over how that process works. The provider becomes responsible for a service that other systems depend on. Incrementality becomes infrastructure.

The emergence of a new paradigm, incrementality infrastructure, explains several changes we are seeing together: greater attention to methodology during procurement, daily results delivered through machine-readable interfaces, explicit operational requirements, and demand for measurement and optimization tools that a brand's own AI assistants can use.

This article introduces incrementality infrastructure: what it is, how it works, and how it changes the role of measurement in marketing.

What is incrementality infrastructure?

Incrementality infrastructure is a shared service that supplies incrementality measurement and optimization capabilities to a brand's people, business systems, and AI agents through dependable scheduled deliveries and on-demand interfaces.

Incrementality concerns the outcomes caused by marketing: sales, new customers, or other business results that would not otherwise have occurred. The infrastructure supplies estimates of those outcomes and tools for making decisions with them. It also maintains the data connections, evidence, business definitions, and operational processes that make the outputs usable over time.

The word infrastructure describes its role. In IT, infrastructure includes the underlying components enterprises depend on to run their systems, as IBM's overview of IT infrastructure explains. In this context, measurement becomes an underlying capability that several applications and processes can use.

A finance team might use the results in its planning model. A performance marketing team might receive campaign metrics in an existing dashboard. An internal agent might call an optimization tool when a budget changes. Each stakeholder should draw on consistent definitions and approved analytical methodology.

A provider can still offer an excellent user interface. People need somewhere to inspect results, review calibration, and explore scenarios. What changes is that the service also has a useful life outside that interface.

Why the role of marketing measurement is changing

Two developments are driving this change among the large ecommerce and retail brands I work with.

LLMs are becoming the intelligence and agent layer

Brands are using Claude, ChatGPT, and other LLMs as the layer through which people ask questions, interpret information, and coordinate work. They want to connect their measurement data and optimization tools to those environments.

An AI assistant might answer a question about last week's incremental performance or request a budget allocation based on a set of constraints. To do this, it needs access to measurement results and analytical tools through defined interfaces, such as MCP or APIs. The incrementality infrastructure supplies the data and runs the analytical tools. The AI layer interprets the request, calls the appropriate tools, and helps the user work with the result.

This makes machine-readable access increasingly important. The measurement provider's UI remains relevant as one of several interfaces, alongside those used by the brand's AI assistants, agents, and other systems.

Brands want to improve the processes they already run

Large ecommerce and retail brands already have established measurement and optimization processes. Their data warehouses, reporting, budget allocation, and bidding workflows are in place. They want to inject incrementality into those running processes without redesigning the whole process as a first step.

In practice, that can mean delivering campaign and ad set level incremental ROAS into an existing data warehouse every day. The team can use that new input in the same reporting or optimization workflow, replacing attributed ROAS with incremental ROAS where appropriate.

As other processes begin to depend on that input, its delivery becomes an operational responsibility. The results need to arrive in the agreed form and at the agreed time so the next step in the brand's workflow can run.

From a measurement application to incrementality infratructure

The following comparison describes a shift in emphasis. 

Login frequency becomes an incomplete measure of value in this setup. A team can depend on the measurement every day while spending little time in the provider's interface. The more useful questions concern whether the deliveries succeed, whether teams use the outputs, and whether those decisions produce the expected business results.

Scheduled outputs and on-demand tools

Incrementality infrastructure offers two ways to access its capabilities. Both should be designed around the work the brand needs to do.

Scheduled outputs

A scheduled delivery produces an agreed output at an agreed cadence. For example, a daily table might contain incremental revenue, incremental conversions, iROAS, and incremental cost per acquisition by market, campaign, ad set, and customer type.

Once that table arrives in the warehouse, the brand can join it to its own campaign data, show it in reporting, or use it as an input to a bidding process. Its usefulness depends on the details: stable identifiers, consistent definitions, known coverage, and a clear indication of how current the results are.

For illustration, a brand might require validated results by 08:00 each morning so its existing optimization process can run at 08:30. The team should also know what happens when an upstream source is late. A table arriving on time with yesterday's data should be distinguishable from a fresh, complete delivery.

On-demand historical queries

Other questions arise when someone needs an answer: What was incremental performance last week? Which markets changed most? How did acquisition campaigns perform compared with retention campaigns?

An API can make these results available to another application. An AI assistant can request them through a suitable tool interface. A useful response should identify the reporting period, metric definition, data cutoff, and analytical version, so people and systems can interpret the results correctly.

On-demand optimization

Optimization is a different request because the answer depends on the supplied objective and constraints. Consider: Allocate next quarter's marketing budget while keeping total spend equal to the same quarter last year. Prioritize new customer acquisition and preserve the committed brand investment.

The service must resolve the budget, planning period, objective, and constraints before calculating the allocation. It should return the proposed plan together with its assumptions and expected outcomes. If the inputs are incomplete or the constraints cannot all be satisfied, that should be explicit.

Historical iROAS describes estimated returns on past spending. Decisions about the next euro require a view of how returns change with spend, including saturation. This is where marginal incremental ROAS, or miROAS, becomes relevant. Ranking campaigns by historical average iROAS alone is not a complete budget optimization method.

The methodology behind the interface

When results flow into recurring decisions, methodological questions become operational questions. A reliable delivery process can distribute a weak estimate very efficiently. The people building and using the service need to understand both the analysis and its limitations.

Marketing Mix Modeling estimates marketing effects within a broader business context. Experiments provide evidence about causal effects in the conditions tested. Attribution supplies detailed information about observed marketing interactions and conversions. These sources have different strengths and assumptions.

A credible approach explains how experiments and attribution inform model calibration, which evidence is used, and where evidence remains limited. It should also explain how differences in test populations, outcomes, time periods, and campaign coverage affect calibration decisions.

The process continues after onboarding. New experiments can change the evidence. Campaign structures and customer behavior change. Someone must own the work of maintaining that evidence and deciding when a model or calibration needs review.

Operational reliability and service commitments

Operational reliability is the term I would use for the ability to deliver the agreed service consistently. It sits alongside analytical validity: the outputs must be defensible, and they must reach the intended people and systems in the expected form and at the expected time.

The distinction follows familiar service-management thinking. Google's Site Reliability Engineering guidance separates the indicators used to measure service behavior, the objectives set for those indicators, and agreements that specify consequences when commitments are missed. For incrementality, the measures should reflect the work that depends on the service.

Application uptime alone leaves important questions unanswered. A service can be online while a delivery is incomplete or an input source has stopped refreshing. Monitoring needs to follow the path from source arrival through validation and analysis to successful downstream delivery.

Preserve versions and control production changes

Historical estimates can change when late data arrives, an experiment adds evidence, or a model is revised. The service should preserve what a team saw when it made a decision, alongside the current estimate. This allows the team to separate a change in marketing performance from a change in the measurement.

New model configurations and calibration choices should be tested before they affect the teams and systems using the service in production. A practical process compares old and proposed outputs, investigates material changes, records approval, and provides a way to restore the previous version when needed.

Reliability must also hold at the intended scale. A successful pilot for one market does not by itself establish that the same delivery deadline can be met across many markets, customer segments, and models. Production acceptance should test the scope the brand actually intends to run.

Infrastructure for people, workflows, and AI agents

The same underlying capability can serve a marketer reading a dashboard, an automated report, and an AI agent helping with next quarter's plan. Each needs access to the appropriate results and tools.

Model Context Protocol, or MCP, provides a standard way for AI applications to discover and use external capabilities. In an incrementality setting, those capabilities might retrieve performance data or run an optimization scenario. An API can support other programmatic integrations, while scheduled data delivery continues to serve established warehouse processes.

The agent's role is to interpret the request, collect the necessary context, invoke the appropriate analytical tool, and explain the returned result. The measurement and optimization service performs the analysis. This gives the brand a way to combine specialist capabilities with its own assistant and other business information.

Consider the request to keep next quarter's spend equal to last year. An agent might retrieve the approved historical budget from one system, identify existing commitments from another, and submit both to the optimization service. It should then present the returned allocation with the objective, constraints, forecast, and limitations used to calculate it.

This is why a useful agent interface requires more than access to a report. Tools need clearly defined inputs, consistent metric meanings, discoverable capabilities, and understandable failure responses. The returned information should carry enough context to be checked and reproduced.

Permissions should follow the decision involved. Reading performance, creating a scenario, changing calibration, and executing budget changes are different actions. A brand may allow an assistant to compare scenarios while reserving execution for an approved workflow. Audit records should connect the request, analytical version, recommendation, and any resulting action.

Preparing for agents therefore improves the underlying service for other teams and systems too. Clear definitions and traceable outputs help a reporting system or analyst just as much as an AI assistant.

How the shift changes industry expectations

Procurement is one place where this change becomes visible. In the conversations I see, brands spend more time examining methodology and operational reliability alongside the user interface. They ask how granular results are derived, how experiments enter calibration, how outputs reach their systems, and who investigates unexpected changes.

Those questions reflect the role measurement is taking on in everyday work. A campaign result needs to make sense all the way from its source data and calibration to its use in a warehouse or optimization process. A budget recommendation needs to carry the assumptions and constraints behind it. These are properties of the service that matter whenever people or systems rely on it.

For technology providers and internal development teams, this raises expectations for transparency. The capabilities available through each interface need to be clear, including any configuration requirements or limits. A tool demonstrated in a user interface may still need a separate implementation before an API or AI agent can use it.

Responsibilities also become more explicit. A brand may own source-data correctness, business definitions, and execution decisions. A provider may own processing, model operation, and scheduled delivery. Experiment design and calibration review may be shared. These responsibilities exist whether measurement is developed internally, supplied by a specialist, or assembled from both.

How Sellforte fits into this architecture

Sellforte is the measurement infrastructure that helps agents and marketing teams see which part of the media spend is actually driving incremental growth.

Sellforte's data connections support the flow of business and marketing data into measurement. Sellforte Experiments supports experimentation and the evidence used in calibration. Sellforte Optimizer supports budget scenarios and allocation decisions.

Sellforte MCP extends access into compatible AI environments, including measurement analysis and optimizer scenarios. 

Across these capabilities, the architectural principle is the same: the brand can bring incrementality into the systems and workflows it already uses, with clear definitions of what each interface delivers.

Talk to Sellforte about connecting incrementality measurement and optimization to your existing workflows and AI tools.

Frequently asked questions

Is incrementality infrastructure a new measurement methodology?

It describes how measurement and optimization capabilities are supplied and operated. The underlying methods may include experiments, MMM, and calibrated attribution. The infrastructure also includes the interfaces, definitions, controls, and service processes needed to use those methods in recurring decisions.

Does it replace the measurement dashboard?

A dashboard can remain useful for exploration, validation, and managing the service. Incrementality infrastructure also makes the results and tools available to other systems, such as the brand's own reporting systems or AI assistants. The brand can choose the interface that fits each task.

Is an API or MCP enough to make a platform infrastructure?

An API or MCP provides a connection. A service that other processes depend on also needs documented behavior, defensible outputs, operational reliability, and clear ownership. That includes consistent handling of incomplete data, errors, and changes in production.

Can a brand keep its own attribution and bidding systems?

That is a central use case for this architecture. Existing data can feed the service and incremental outputs can feed existing decisions. Compatibility still depends on the required dimensions, identifiers, definitions, and integration capabilities, which should be checked during implementation.

Can AI agents optimize marketing budgets through this infrastructure?

An agent can request a scenario from an optimization tool when the service exposes that capability. The result depends on the supplied objective, constraints, and analytical model. Permission to request a scenario is separate from permission to execute changes in an advertising platform.

About the author

Lauri Potka is the Chief Operating Officer at Sellforte, with over 15 years of experience in Marketing Mix Modeling, marketing measurement and media spend optimization. Before joining Sellforte, he worked as a management consultant at the Boston Consulting Group, advising some of the world’s largest advertisers on marketing optimization. Follow Lauri on LinkedIn.