A Marketing Cloud Personalization sitemap that fires correctly during initial QA can silently regress. A new framework version changes how route events fire. A redesign moves the product ID to a different DOM attribute. An async loading change races the beacon. The sitemap runs without errors, the personalization team sees recommendations on the page, and meanwhile MCP is collecting partial or wrong data for weeks before someone notices.
The defense is treating the sitemap as code with a real test suite, not as a configuration step that ships once and is forgotten.
The categories of test that matter
A complete sitemap test suite covers four concerns. Most teams ship with one or two and add the others reactively after the first regression incident.
1. Beacon firing tests. Does the right beacon fire on the right page type with the right data? Manual or automated, every page type needs verification.
2. Identity tests. Does identification fire correctly on login, signup, and returning sessions? Does the merge happen?
3. Catalog ID validation. Are the IDs the sitemap reports actually present in the catalog? Mismatched IDs are the #1 source of "personalization is on but recommendations are random."
4. Regression tests. When the site code changes, does the sitemap still work? This requires the test suite to be runnable on demand, ideally in CI.
Beacon firing: the manual test pass
Before automation, every sitemap goes through a manual pass. The 15 to 20 minutes to do this catch most bugs:
- Open the browser console with MCP debug logging enabled.
- Walk through each page type the site has: home, category listing, item detail, search results, cart, checkout, account, content articles.
- For each page, record what beacons fire, what data they contain, and whether the data looks right.
- Then traverse using the navigation patterns real visitors use: SPA route changes, modals, quick-views, infinite scroll loads. Confirm beacons keep firing correctly.
The issues this catches:
- Pages that fire no beacon at all (broken integration on that page type).
- Pages that fire the wrong beacon (item detail being mistaken for category, or vice versa).
- Pages that fire the right beacon with null or placeholder data (async load races).
- SPA navigation that fails to fire route-change beacons.
Beacon firing: the automation case
Manual testing catches the common cases but does not scale. Sites of any size need automated tests.
The pattern that works: a Playwright or Cypress suite that visits each page type, intercepts the beacon network calls, and asserts the payload. The tests run in CI on every code change to the site.
test("item detail page fires item-detail beacon", async ({ page }) => {
await page.goto("/products/sample-sku-12345");
const beacon = await waitForBeacon(page);
expect(beacon.action).toBe("ItemDetail");
expect(beacon.itemId).toBe("SKU-12345");
});
The investment is real (a few days of test setup) and the payoff is large (the test suite runs forever, catching regressions before they reach production). Sapota standardizes this pattern at the start of every Personalization engagement so the test suite is in place before launch.
Identity testing
A separate test set covers identification flows:
- Anonymous browsing builds a visitor profile. Confirm via MCP debug overlay that the profile exists and has expected behavior recorded.
- Login fires identification with the canonical user ID. Confirm the user profile picks up the prior visitor behavior.
- Logout does not delete the user profile. Subsequent anonymous browsing creates a fresh visitor profile.
- Cross-device: another browser, login with the same user, expect the user profile to be visible with prior history.
These tests are harder to automate because they involve auth flows that may have CSRF tokens, MFA, or other state that fights automation. Manual identity testing as part of every release cycle is more practical for most teams.
Catalog ID validation
The bridge between sitemap and catalog is the item ID. The sitemap reports IDs from the DOM. The catalog stores items by ID. When the two diverge, MCP attributes behavior to ghost items that do not exist or to wrong items that do.
The validation: extract every ID the sitemap reports during a normal browsing session. Compare against the catalog. Any IDs in the sitemap but not in the catalog are bugs. Any IDs the visitor would expect to encounter but the sitemap never reports are also bugs.
A practical script:
- Run a synthetic browsing session that visits 50 to 100 product pages.
- Capture every item ID reported in beacons during the session.
- Query the MCP catalog API for each ID.
- Report any IDs that did not resolve, plus any catalog items the synthetic session expected to encounter but did not see.
Running this monthly catches gradual drift. Running it after major site changes catches sudden breakage.
Pre-launch checklist
Before the sitemap goes to production, this list should be all green:
- Manual walkthrough of every page type with debug logging on. All beacons fire, all data is correct.
- Automated tests cover at least the top 5 page types and pass in CI.
- Identity flow tested end to end: anonymous → identified → cross-device → identified again.
- Catalog ID validation script run at least once. No mismatches.
- SPA route changes verified to fire route-change beacons.
- Async data loading verified: throttle network in devtools to 3G, confirm beacons still fire with valid data.
- Modal and quick-view contexts verified to fire context-update beacons.
- Console has no errors related to MCP SDK.
- The MCP debug overlay matches expectations on every page type.
- Documented baseline metrics from a known-good day. Future regressions can be detected by comparing against this baseline.
Skipping any step usually does not cause an immediate visible problem. It causes a problem 6 months later that the team cannot trace back to its origin.
Continuous monitoring after launch
The test suite is for catching regressions before they ship. Continuous monitoring catches issues that slip through anyway:
- Beacon volume monitoring. Sudden drops in any beacon type indicate a partial outage. Set thresholds, alert on breach.
- Catalog match rate. The percentage of beacons whose item ID matches a catalog row. Should stay near 100 percent. A drop indicates the sitemap or catalog are drifting apart.
- Affinity profile depth. Average number of behavioral signals per user profile. If this drops, the data layer is feeding the platform less than it should.
- Recommendation strip render rate. The percentage of recommendation calls that return non-empty results. A drop indicates either filter over-application or data starvation.
Each of these has a normal range. Define the ranges during the first month of production traffic. Alert when subsequent values fall outside.
What changes when the site changes
Sites are not static. Every redesign, every framework upgrade, every new feature flag has the potential to break the sitemap. The discipline is to treat the sitemap as a downstream consumer of the site's data layer:
- New page types: expand the sitemap to cover them. Add tests.
- Framework upgrades: re-run the full test suite before declaring the upgrade complete.
- DOM restructuring: confirm the sitemap's selectors still match. Update if needed.
- Feature flags that change page behavior: test the sitemap under both states.
Sites that do this stay in good shape. Sites that do not, drift into a state where the sitemap was right 2 years ago and is now silently wrong in places no one has tested. Sapota's Salesforce team builds the sitemap regression suite as a deliverable on every Personalization engagement and includes ongoing test maintenance in production support contracts.
Building or maintaining sitemap test coverage for Marketing Cloud Personalization? Sapota's Salesforce team handles test design, automation, and continuous monitoring on production engagements. Get in touch ->
See our full platform services for the stack we cover.
