Introducing Micro Experiences

Micro Experiences (MX) is a new PageBuilder capability, designed to improve the flexibility and efficiency of our customer developer teams, empowering our clients to manage and scale their digital properties.

MX enables organizations to create multiple instances of PageBuilder. Each instance can be configured with its codebase and bundle of features, enabling teams to create specialized digital experiences that align with specific business needs or audience segments.

MX Fireside Chat with Joey and Fatih

Generated using [Experimental] Arc XP AI Audio Narratives.

Micro Experiences Benefits for Your Team

Micro Experiences (MX) provides your team with a powerful tool for enhancing digital operations through the separation of concerns. By allowing the creation and management of multiple PageBuilder instances, MX enables different teams to focus on their specific areas of expertise without interference.

This separation enhances collaboration, accelerates development cycles, and optimizes performance, empowering your team to deliver superior digital experiences efficiently.

Primary Benefits

Parallel Deployments Enable independent developer teams to deploy changes simultaneously, enhancing collaboration and productivity.

Increased Developer Efficiency Accelerate development cycles and reduce time to market with streamlined workflows and faster feature rollouts.

Reduced Deployment Risk Minimize the impact of deployment errors by isolating business-critical components from daily updates, ensuring a smaller blast radius.

How does MX work?

Here is a simple, high-level Micro Experience architecture that highlights how three distinct personas interact with Micro Experiences:

Key Takeaways:

Multiple PageBuilder instances, with completely isolated databases of pages, templates, and resolvers.
- Your editorial/curation team can easily navigate to each experience in Arc Home and curate pages/templates same way they do today.
- They can see a curated list of blocks (potentially smaller list) while they configure each experience (i.e: only see blocks for election experience when curating a page in election MX).
Multiple codebases, separate bundles can be deployed to each MX Deployer.
- Deployments are now independent from each other. Teams can work and deploy in parallel, to reduce risk of deployments from each other.
Your readers do not see any difference in their experience. They continue to smoothly browse your site across multiple MX.

To learn more about Micro Experience architecture and how it works see How does Micro Experiences work.

Use Cases

Micro Experiences opens doors to many possibilities. It provides a flexible framework for creating and managing digital experiences at scale. Here are a few example use cases of enterprise-scale DXP needs that we designed Micro Experiences for:

1. Launching New Unique Digital Properties

Scenario: A brand is introducing new digital properties that significantly differ from its current offerings.

Approach: With MX, each platform can have its own dedicated PageBuilder instance, enabling tailored design and functionality for each unique property. This setup allows for customized content strategies and branding, ensuring that the new experiences are distinct without impacting existing sites. It allows for an increased speed-to-market for new experiences due to reduced development coordination. Customers can even hire a partner or 3rd party development team to stand up an independent site without changing their own developers’ workflows.

2. Separating Business-Critical Operations (by lowering risk of deployments)

Scenario: A media organization needs to ensure that its subscription, paywall and identity systems are isolated from non-critical daily updates.

Approach: MX can be used to create, or split dedicated experiences for business-critical operations, such as payment processing, reducing the risk of disruptions from unrelated updates or deployments. Other teams working on outside of this experience can also gain confidence and speed when they make deployments.

3. Supporting Multiple Development Teams

Scenario: A large enterprise organization has multiple development teams working on different projects and features simultaneously.

Approach: With MX, each development team can have its own dedicated PageBuilder instance, allowing them to work independently without interference from other teams. This setup facilitates parallel development and deployment, reducing bottlenecks and enabling faster feature delivery. By isolating projects, teams can focus on their specific goals and requirements while maintaining overall system stability and cohesion.

4. Consolidate Secondary Organizations to the primary org

Scenario: A customer currently utilizing Secondary Organizations for supporting a multiple-experience model (i.e: running custom and Themes bundles on separate PageBuilder instances at the same time), wants to consolidate and simplify their organization setup with Micro Experiences under their primary organization.

Approach: Customer developers can simply deploy Secondary Organization bundles into their primary organization under a new Micro Experience and reconfigure the routing to consolidate and simplify their PageBuilder setup.

5. Experimenting with Core Features and Rendering Strategies

Scenario: A development team aims to test high-level features like using Themes, or low-level features such as Engine code splitting, Single Page Applications (SPA), or alternative rendering strategies (like fully-static render), on a smaller section without affecting the live site as whole.

Approach: MX allows the creation of a dedicated environment for these technical experiments. Developers can explore out of box Themes product while keeping their current experience in custom bundles, or try different architectural approaches, such as splitting the Engine code or implementing SPAs, in isolation. This setup provides a safe space to validate new techniques and frameworks before integrating them into the main site, ensuring that any risks or disruptions are minimized.

These are just a few use cases we anticipate Micro Experiences can be commonly used for. We’re looking your feedback and curious to hear your unique use case for Micro Experiences.

6. Redesign / Revamp / Upgrade

Scenario: A big redesign, rebranding, revamping of the current experience can be a huge task to build, test and go live all at once, brings increased risk and long timelines.

Approach: Customers can utilize MX, and design a iterative approach to implement designs, upgrades and have quicker test and feedback loop. The development work can be split easily by a template-by-template or site-by-site migration over to the new code instead of, single experience model requiring a big launch.

Availability

Micro Experiences (MX) is generally available to all customers sandbox environments by February 3, 2025, and will be available in production environments by March 3, 2025.

To start using MX, it must be provisioned to your PageBuilder setup. To learn more about the provisioning process and the requirements, see Getting Access to Micro Experiences guide. To initiate the provisioning process for Micro Experiences, please contact your Technical Account Manager (TAM).

Micro Experience Compatibility with other Arc XP Features

Micro Experience feature is compatible with most PageBuilder curation and rendering features and Arc XP Delivery (CDN) settings, except for a few scenarios:

FEATURE	MX COMPATIBILITY	NOTES
Single Page Application (SPA)	✅ Supported	SPA features can be used within each MX, but cannot be used across MXs. When powering a single site using multiple MXs, your reader’s navigation from one page to another that are rendered by separate MXs will initiate full page reload. Each experience can still have SPA navigation as long as user navigates within the same experience (i.e: Election MX could still have SPA features that provide more seamless user experience between Election pages, but the browser navigates fully when the user navigates to the sports section front, if it is rendered by another MX).
PageBuilder Data Sync API	⚠️ Only Default MX	Only works on the default MX.
Bandito	⚠️ Only Default MX	Only works on the default MX. This feature cannot be provisioned to secondary Micro Experiences.
Audience Targeting	⚠️ Only Default MX	Only works on the default MX. This feature cannot be provisioned to secondary Micro Experiences.
Clavis	✅ Supported	Clavis is implemented and configured fully on client-side, therefore you can use the same Clavis implementation in multiple MXes and they will work consistently throughout your experiences.
Resizer (Photo Center)	✅ Supported	Resizer can be configured the exact same way in each codebase in your Experiences.
Video Player (Video Center)	✅ Supported	Video Player can be configured the exact same way in each codebase in your Experiences.
Arc Subscriptions and Identity	✅ Supported	Arc Subscriptions and Arc Identity Blocks can be configured the exact same way in each codebase in your Experiences.

For Resizer, Video Player and Arc Subs/Identity implementations across multiple Micro Experiences, it’s important to know the concepts about sharing code and configuration. See Micro Experience Developer Guide to learn more.

Pricing

Micro Experiences is free, opt-in feature, available to customers with PageBuilder license. Number of Micro Experiences is limited to 5 per organization.

Office Hours

Join our Micro Experiences Office Hours on Tuesdays and Thursdays from 12:00 PM to 12:30 PM EST to chat with our product team about any questions or topics related to Micro Experiences. All customers and partners are encouraged to join.

Contact your TAM for meeting link or invite.

Dates

Every Tuesday and Thursday for 4 weeks:

February 18, 12pm-12:30pm EST
February 20, 12pm-12:30pm EST
February 25, 12pm-12:30pm EST
February 27, 12pm-12:30pm EST
March 4, 12pm-12:30pm EST
March 6, 12pm-12:30pm EST
March 11, 12pm-12:30pm EST
March 13, 12pm-12:30pm EST

See left sidebar for further reading about Micro Experiences topics.