MCP Web vs Server-Side Campaigns: Choosing the Architecture

Marketing Cloud Personalization campaigns reach the visitor through one of two architectures. Web campaigns render via the JavaScript SDK in the browser, with the platform deciding what to show after the page loads. Server-side campaigns reach the platform via API call from the site's own backend, with the rendering happening before the response is sent. The two look interchangeable in the campaign builder. They are not. The architecture choice affects every important property of the campaign.

What each architecture actually does

A web campaign works like this: the page loads. The MCP SDK initializes. The SDK calls back to MCP servers asking "what campaign applies to this visitor on this page?" MCP returns a payload (template, content, recommendations). The SDK renders that payload into a designated DOM element on the page. The visitor sees the personalized content a few hundred milliseconds after the rest of the page has rendered.

A server-side campaign works like this: the site backend receives a request for a page. Before responding, it calls the MCP API: "give me the campaign payload for visitor X on page Y." MCP responds with the same kind of payload. The backend incorporates the personalized content into the page HTML it sends back to the visitor. The visitor sees the personalized content as part of the initial page render.

Both flows produce the same output. The differences are in everything around the output.

The latency question

Web campaigns add zero server-side latency. The page response is unaffected by MCP. The rendering happens after the page is interactive. The downside is a brief flash where the placeholder is visible before the personalized content swaps in.

Server-side campaigns add latency to the page response. The backend has to wait for MCP to respond before it can finish the HTML. Typical added latency is 50 to 150 milliseconds, depending on network proximity to MCP servers and the complexity of the campaign. The upside is no flash. The personalized content is in the page from first paint.

For high-traffic sites where total page latency is a P0 concern, web campaigns are the safer default. For pages where the personalized content is critical to the visitor's first impression (a hero band, a checkout-page upsell), server-side campaigns avoid the flash even though they add latency.

Failure modes diverge

When MCP is slow or unavailable, the two architectures fail differently.

A web campaign that fails leaves the placeholder visible. The page is otherwise fine. The visitor sees an empty space or, if the placeholder was implemented well, a sensible default. Failure is visually obvious but does not break the page.

A server-side campaign that fails has two sub-cases. If the integration is built with timeouts and fallbacks, the backend uses a default response when MCP times out, and the visitor never knows. If the integration is built naively, the backend hangs waiting for MCP and the page is slow or returns an error.

For server-side campaigns, the discipline is hard timeouts (typically 100 to 200 ms) and explicit fallback content. Without those, an MCP outage becomes a site outage. The web SDK handles this for you. The server-side path requires intentional engineering.

Governance and editorial control

Server-side rendering means the site backend sees the full payload before it goes to the visitor. The site can apply additional filtering, sanitization, or transformation. For regulated industries (financial services, healthcare, anything subject to compliance review), this gives a clear boundary where compliance logic can live.

Web campaigns deliver content directly from MCP to the browser. The site's backend never sees what was rendered. For most consumer e-commerce that is fine. For contexts where every piece of content shown to a visitor needs to pass through compliance, web campaigns introduce a gap.

A common pattern: web campaigns for product recommendations (commercial decision, low compliance risk), server-side campaigns for any content that includes regulated language (rates, disclaimers, eligibility claims).

Caching and CDN behavior

Server-side campaigns produce HTML that varies by visitor. CDN caching of the page becomes complicated. Either the page is uncached (every visitor gets a fresh server render) or the CDN needs vary-by-visitor caching keys, which most CDNs do not support cleanly out of the box.

Web campaigns leave the underlying page cacheable. The CDN serves the same HTML to every visitor. The personalization layer renders client-side from the cached page. CDN strategy stays simple.

For sites with heavy CDN dependency, web campaigns are the architecture that does not break caching. Server-side campaigns push the team into custom cache logic, which is workable but more involved.

What goes where

A reasonable default rule for each campaign type:

• Product recommendation strips on item detail and home pages: web campaigns. Latency-sensitive pages, low compliance risk, CDN-friendly. The flash is acceptable for ancillary content.
• Category page sort and filtering: web campaigns. Same reasoning, with additional weight that re-sorting an entire category on the server is expensive.
• Hero band on home page for visitors with established affinity: server-side. The hero is the first thing the visitor sees. Avoiding the flash matters here.
• Checkout-page upsells: server-side. Cart contents are already on the server. The personalization integrates naturally into the checkout HTML.
• Email content or open-time personalization: server-side, by definition. The browser is not running JavaScript at the moment the email renders.
• Mobile push notifications: server-side, for the same reason.
• Any campaign with regulated content: server-side. Site backend can apply compliance filtering.

The decision is not all-or-nothing

A typical production site runs both architectures. Web campaigns for the high-volume low-stakes recommendation strips. Server-side campaigns for the few pages where the personalized content needs to be in the initial render or filtered through compliance logic. The right answer per page depends on the constraints of that page, not on a project-wide architecture preference.

What does not work is treating the choice as ideological. Teams that go all-server-side for "control" pay the latency tax everywhere. Teams that go all-web-side for "simplicity" struggle with the few pages where flash is unacceptable.

Migrating between architectures

A campaign built as web can usually be moved to server-side later, and vice versa. The campaign content (template, recommendations, segment targeting) lives in MCP and is architecture-agnostic. The integration code at the site changes, but the marketing-defined logic does not.

This is worth knowing because the right answer often emerges after launch. A campaign designed as web that produces too much flash can be moved server-side without rebuilding it. A server-side campaign that adds too much latency can be moved web-side. Both are tractable. Neither is a one-way door.

The architecture choice deserves explicit attention during campaign design rather than being the default of whichever path the team finds easier to ship. Sapota's Salesforce team treats web vs server-side as a per-campaign decision and documents the reasoning so future campaigns of similar type get the same treatment.

---

Designing or auditing campaign architecture in Marketing Cloud Personalization? Sapota's Salesforce team handles web and server-side integration patterns on production engagements. Get in touch ->

See our full platform services for the stack we cover.