The Report Suite That Cannot Be Split

The developer's two concerns are partly right and partly wrong, and the architect's proposal has a structural flaw.

On server calls: Multi-suite tagging in the Web SDK does not multiply server calls the way legacy AppMeasurement did. With Web SDK, a single sendEvent can target multiple report suites via the config override or the datastream's report suite mapping, so the 'multiply server calls' concern is largely a legacy mental model. However, sending to four suites does increase processing and storage cost, and the datastream must be configured to map correctly.

On variable limits: This is the real constraint. The funnel suite would need 12 new eVars and 8 new events on top of whatever it inherits. If the funnel suite is a fresh suite, it has its own allocation - that is the point of splitting. But if the funnel requires correlating with brand-level context, the funnel suite still needs those dimensions, and 12 eVars may not be enough if the funnel spans brands with different step definitions.

The structural flaw: A shared XDM schema across four brands with a single funnel suite means the funnel suite receives all traffic from all brands, including non-funnel pages. That is fine for a global funnel view but makes the suite noisy and expensive. More importantly, the 340-eVar global suite with 75% nulls is a governance problem that the proposal does not address - it just adds more suites on top.

Recommendation: Do not create a separate funnel suite by default. First, audit the global suite's 340 eVars and retire or consolidate the null-heavy ones - that frees allocation and reduces confusion. Then implement the funnel as 12 eVars and 8 events on the brand suites plus the global suite, using a shared classification or a calculated metric layer for cross-brand funnel views. Only split into a dedicated funnel suite if the funnel genuinely needs dimensions that conflict with brand suites or if processing rules must diverge. Multi-suite tagging to a fourth suite is acceptable if the datastream is configured correctly, but adding a fifth suite for the funnel should be justified by a concrete conflict, not by convention.

Validation must happen at three layers: configuration, hit-level, and report-level.

Configuration layer:

• Export the current variable allocation for each report suite (Admin > Report Suites > Edit Settings > Conversion > Success Events / Traffic > Traffic Variables / Conversion > Conversion Variables) and build a diff against the proposed 12 eVars and 8 events. Check for name collisions, duplicate event IDs, and any eVar already used as a traffic variable or list var.
• Confirm allocation type (recent vs. original) and expiry for each new eVar against the funnel's analysis needs - a funnel step that must persist across sessions needs a different expiry than a last-touch attribution.

Hit-level layer:

• Use the Adobe Experience Platform Debugger or a proxy (Charles/Fiddler) to inspect the sendEvent payload and confirm the XDM fields map to the intended eVars/events via the datastream mapping, not just that they exist in the payload.
• Fire test hits for each funnel step and each brand, and confirm the correct suite(s) receive them with the correct values. Include a null case and an edge case (e.g., a step reached out of order).

Report-level layer:

• After test traffic, run a low-traffic report on each new eVar and event and confirm non-zero values appear where expected and zero where not. Check the 'Unspecified' bucket - a high Unspecified count indicates mapping failures.
• Compare a known test session's expected values against the reports to confirm processing rules did not alter them.