One Tenant, Many Websites: The RAS Advantage for Connected Operations

A growing website portfolio should not require a growing pile of disconnected systems

A business can have several websites and still operate as one team. Different storefronts may serve different audiences. Campaign destinations may support different offers. A shared checkout may complete transactions that began somewhere else. The customer sees a journey, but the business often has to manage the pieces separately.

That separation creates an operational opportunity. When website boundaries do not match the way the business works, teams spend time reconciling settings, checking installations, rebuilding context, and deciding which account owns which part of the journey.

EDSA RAS supports a more connected approach: manage authorized site workspaces through the platform, or connect multiple approved websites to a shared RAS site workspace within one tenant. The second model is especially useful when those websites genuinely belong to one coordinated operation.

The innovation is the combination of network-level configuration, explicit domain boundaries, a modular revenue toolkit, and optional continuity across approved checkout journeys. It is more than putting several website links behind one login. This article explains the supported advantages and the decisions that make the setup useful. The visuals are conceptual illustrations, not customer screenshots or measured results.

1. Understand the difference between an account, a site workspace, and a website

In RAS, the organization is the tenant context. A RAS site workspace has its own site key, settings, access scope, and product entitlements. A website hostname is an approved destination where that workspace can operate.

Those are different boundaries. Multiple separately configured site workspaces can exist within an organization, and authorized users can switch between the sites they can access. Their records and permissions remain scoped to the selected workspace. One login does not automatically merge every site's analytics or campaigns.

Alternatively, several approved hostnames can belong to one RAS site workspace. They use the same site key and the existing campaign configuration for that workspace, subject to each module's targeting and eligibility rules. This is the shared-network model: several customer-facing websites, one coordinated RAS configuration.

The right choice depends on ownership and responsibility. Shared operations can benefit from a shared workspace. Separate clients, teams that require data isolation, or independently governed businesses may need separate workspaces instead. A hostname inside a shared workspace is not automatically its own permission boundary.

2. Reduce repeated setup across a coordinated network

Adding another approved hostname to an existing workspace does not require creating another RAS site key or rebuilding that workspace's campaign definitions. The authorized manager adds the domain, then installs the existing site's loader on the participating website.

This gives a central team one configuration scope to maintain for the connected network. A new campaign destination can use an established installation pattern. A replacement website can be prepared without treating the revenue tooling as an unrelated project.

Domain registration is not automatic deployment. The loader must still be installed on each website, and consent, page targeting, commerce events, and module compatibility must be tested there. Sharing configuration also increases the importance of review: a change intended for one experience may affect other eligible pages in the network.

3. Expand the network with a controlled onboarding process

The domain-management workflow supports pasted lists of up to five hundred entries per batch. It normalizes hostnames, skips entries already assigned to the selected workspace, and preserves the status of existing inactive domains.

Invalid entries or ownership conflicts reject the batch rather than quietly creating an incomplete network. New registrations and their audit records are saved together. That matters when a manager is onboarding a portfolio and needs to know whether the operation actually succeeded.

Each hostname is explicit. The main hostname, its www version, and a checkout hostname need their own registrations when used. Registering a domain is not proof of DNS ownership and does not verify that the installation is working. The advantage is a deliberate inventory and repeatable setup process, not an unrestricted wildcard.

4. Coordinate a broader revenue toolkit from the same operational context

The shared-network model becomes more valuable when measurement, investigation, and action are available within the same suite. Each RAS module contributes a different part of the work:

• SiteMetrics: Examine acquisition, engagement, goals, funnels, and supported commerce outcomes to identify where the network's customer journey needs attention.
• JourneyLens: Investigate recorded behavior and interaction evidence to understand friction behind a metric. A shared workspace does not mean separate-origin recordings become one merged replay.
• Voice of Customer: Collect feedback that helps explain hesitation, confusion, and unmet expectations rather than relying only on behavioral inference.
• AdaptiveContent: Present configured messages or content changes on eligible pages, helping a central team address recurring questions across its connected experiences.
• Optimize: Test focused changes against defined outcomes instead of treating every design or messaging change as a proven improvement.
• ProductLift: Support product discovery through configured recommendations and their measurement, with catalog and product identifiers aligned to the commerce integration.
• Abandonment Recovery: Address eligible moments of hesitation or exit with configured recovery experiences and supported campaign measurement.
• Loyalty Engine: Support configured loyalty and reward workflows through the required signed integration. Sharing a browser site key does not establish a shared customer wallet.

Privacy controls support the surrounding governance of collection and subject requests. Module access, usage limits, integrations, and campaign eligibility still apply. A shared tenant is not a promise that every product is enabled everywhere or that one subscription automatically covers every separate site workspace.

The management advantage is the ability to organize a repeatable process: observe a problem, investigate it, choose an intervention, and measure the result. The team can apply the same discipline across its network without pretending every website has identical needs.

5. Keep supported storefront-to-checkout measurement connected

A common challenge appears when browsing and checkout happen on different approved hostnames. Without a deliberate handoff, the destination can receive a new browser identity or lose the context that explains how the purchase journey began.

RAS provides optional cross-domain tracking for participating pages using the same site key. A global Portal Admin enables the feature, both installations opt in, and the source and destination must be authorized HTTPS pages. Consent is evaluated on each side.

For supported navigation, a short-lived, single-use handoff carries allowlisted analytics identifiers and attribution references. It can preserve the SiteMetrics visitor and suite session context, together with supported recovery touches, recommendation click receipts, content exposures, and experiment assignments needed for purchase association.

The opportunity is a more coherent explanation of the journey from storefront activity to a reported order. The handoff does not replay campaigns at checkout, invent missing source events, transfer a login, move a cart, or verify that payment succeeded. Custom checkout navigation and redirects need integration review rather than an assumption that every transition links automatically.

6. Make shared checkout infrastructure fit the business boundary

Sometimes a business needs a specific directory on a shared host rather than control over that host's entire website. RAS supports administrator-managed shared-domain path reservations for this situation.

An active global Portal Admin can reserve a literal directory for a receiving RAS site, with the receiving tenant explicitly enabled for the capability. The receiving site's key applies to that reserved path. A separately registered default owner can retain the rest of the hostname.

This allows the measurement boundary to follow a particular checkout area without requiring ownership of every unrelated page on the same host. Reservations can be prepared before ordinary whole-host registration, and later registration does not silently overwrite them.

Overlapping reservations are rejected. Pausing a reservation blocks its assigned path instead of silently handing it to another account; deliberate removal can return it to a registered default owner. The correct loader must be installed for each area, and switching account context across application paths requires the appropriate navigation and installation design. This is controlled routing, not isolation between mutually untrusted applications sharing one browser origin.

7. Pause one website without dismantling the network

A coordinated operation still needs local controls. An authorized manager can deactivate an individual registered hostname while other active domains continue under their normal rules. The full RAS site can also be deactivated or reactivated.

Deactivation preserves campaign definitions, history, memberships, and domain assignments. An inactive hostname remains claimed rather than becoming available for accidental reassignment. Reactivating the site does not silently reactivate a hostname that was separately disabled.

These controls are useful during a redesign, a campaign retirement, or an installation investigation. Their effect applies to subsequent configuration and collection checks; content already loaded in a browser may remain until refresh. Separate path reservations have their own controls, and site deactivation is not a substitute for cancelling billing, server integrations, or scheduled communications.

8. Give managers access without making every user a platform administrator

RAS distinguishes global, organization, and site roles. Authorized users work within their selected site context. An organization-level Site Admin can manage integrations for the organization's sites, while a site-only assignment is limited to its assigned site.

Ordinary domain and availability management therefore does not require handing every operator platform-wide authority. More sensitive capabilities, including shared-path routing and cross-domain tracking enablement, remain reserved for a currently active global Portal Admin.

This separation lets a business distribute day-to-day responsibility while retaining oversight of changes that alter routing or analytics continuity. It also makes the initial architecture decision important: users with access to a shared workspace should be appropriate for the combined operation, not merely for one hostname within it.

9. Preserve a clearer record of operational changes

Adding domains, changing availability, and managing advanced routing are administrative actions, not just cosmetic settings. The relevant workflows require authorization, request validation, and audit records. Status changes use confirmation and current-state checks to reduce the risk of one manager overwriting another manager's newer decision.

For a central operations team, that provides a stronger basis for answering practical questions: was a hostname disabled intentionally, was an onboarding batch accepted, and which control was changed?

Auditability does not remove the need for an internal change process. It gives that process better evidence. A shared network particularly benefits from assigning an owner, documenting intended changes, and validating representative pages before broad rollout.

10. Bring greater consistency to privacy and measurement decisions

A shared RAS configuration can help a central team coordinate collection practices across approved websites. Optional cross-domain continuity does not bypass the destination's consent gate. Existing server-side suppressions are checked during handoff, and a module suppression can stop the complete handoff.

The handoff transports restricted identifiers and attribution references, not customer contact details, payment data, or arbitrary page configuration. It is analytics continuity within an approved network, not universal person recognition across devices or unrelated businesses.

Teams still need to decide whether the websites should share a workspace, what data is appropriate to collect, and how subject requests and retention are handled. Centralization can make governance more consistent, but the configuration alone does not establish compliance.

11. Make commercial planning follow the actual configuration

Organizations carry billing profiles, while many product entitlements attach to a particular RAS site and solution. Adding approved domains to an existing workspace is different from provisioning another separately entitled workspace.

This distinction makes planning more concrete. The team can identify which websites belong to a shared operation, which require separation, which modules are needed, and what combined traffic and event volumes the connected network may generate.

The opportunity is less configuration duplication and clearer capacity planning, not an unsupported promise of unlimited domains, unlimited events, or guaranteed savings. A larger network can concentrate usage in one workspace. Plans, add-ons, collection limits, and hosting capacity should be reviewed against the intended rollout.

12. Turn the architecture into a repeatable management workflow

Consider a business operating several specialized storefronts with a common checkout operation. It wants consistent revenue tooling but does not want every expansion to become another disconnected implementation.

1. Choose the scope: Confirm which websites genuinely belong in one shared workspace and which need independent access or reporting boundaries.
2. Inventory the entry points: Register the required hostnames and arrange any administrator-managed checkout path reservations.
3. Standardize installation: Use the correct existing site key on each participating page, preserving consent controls and avoiding duplicate loaders.
4. Validate real journeys: Check representative browsing, campaign eligibility, navigation, checkout, and confirmed-order events.
5. Enable continuity deliberately: Request cross-domain enablement where appropriate and test the actual navigation methods used by the websites.
6. Review evidence: Use the suite's available measurement and investigation tools to identify a specific issue before choosing a change.
7. Roll out in stages: Monitor usage, access, and operational effects as more approved websites join the network.

Keep order references stable and unique across the network, and align product identifiers where commerce modules depend on them. Otherwise a shared workspace can make identifier collisions more consequential rather than magically reconciling different systems.

What makes the RAS approach distinctive

The value is not simply that one person can access several websites. It is that the operational boundary can be designed around the business: separate workspaces where separation matters, or approved websites sharing a RAS configuration where coordination matters.

Domain onboarding, per-host controls, optional checkout continuity, administrator-managed path routing, scoped access, audit evidence, and the revenue modules contribute to that same design. Together they create an opportunity to manage a connected web operation with fewer repeated setup tasks and clearer responsibility.

That does not mean every report becomes a portfolio leaderboard, campaigns automatically clone between separate workspaces, or all customer identities and loyalty balances merge. Cross-domain tracking does not add a new hostname-breakdown reporting screen or prove causal revenue lift. The commercial value depends on choosing the right boundaries and validating the implementation.

For businesses whose customer journeys already cross website boundaries, RAS offers a practical way to make the management model follow the operation. Start with one clearly defined network, connect its approved experiences, and build a repeatable improvement process around the evidence it produces.