Experimentation on Edge Delivery Services

Experimentation on Edge Delivery Services (EDS) lets you test layouts, messaging, and components without sacrificing the performance profile that EDS is known for. The experimentation plugin brings this directly into your authoring flow, so you can spin up A/B tests from the same tools you already use to create content.

This post gives a concise overview of how experimentation works on EDS and a short, practical guide to running your first test with the experimentation plugin.

How Experimentation Works on EDS

The experimentation framework for EDS is designed to stay light and edge‑friendly:

• You use an existing page as the control.

• You create one or more challenger variants (for example, different hero, CTA, or layout).

• You configure experiment metadata on the control page to define:

  • Experiment ID
  • Variant URLs
  • Traffic split and other options

• The experimentation engine then:

  • Randomly assigns visitors to variants
  • Tracks views and success metrics using Operational Telemetry
  • Computes performance and statistical significance with minimal runtime overhead

You can use this with both document-based authoring and Universal Editor based experiences on EDS, as described in the contextual experimentation documentation for AEM.

Quick Start: Running an Experiment with the Experimentation Plugin

This guide assumes you already have:

• An Edge Delivery Services project wired to GitHub
• A content source (SharePoint, Google Drive, or AEM with Universal Editor)
• The experimentation engine and plugin enabled for your project (see references below)

1. Open your page in preview

1. Open the page you want to experiment on in preview (for example, the .page or preview URL for your EDS site).
2. Ensure you can see and launch the AEM Sidekick for that project.

2. Launch the experimentation plugin

1. Click the Sidekick icon in your browser.
2. In the Sidekick, select the Experimentation plugin/entry.
3. This opens the experimentation rail or panel, connected to your current page.

3. Define control and challenger

1. Choose the current page as your control experience.

2. Create a challenger:

   • For document-based authoring: duplicate the control document into an /experiments/... folder and apply your content/layout changes there.
   • For Universal Editor: create a variant page or fragment with your desired changes.

3. Note the URLs for the control and challenger pages; you’ll reference them in metadata.

4. Configure experiment metadata

Using the plugin and the underlying experimentation framework:

1. Assign a unique Experiment ID (for example, EXP-001-homepage-cta).

2. Map:

   • Control URL → variant control
   • Challenger URL → variant challenger-1

3. Set the traffic split (for example, 50/50) and any run dates if supported by your setup.

4. Save/publish the metadata changes so they are available at the edge.

The plugin will update the required metadata fields on the control page in line with the experimentation framework for EDS.

5. Preview and sanity‑check

1. Use the plugin’s preview/simulation capabilities (for example, ?experiment=EXP-001-homepage-cta/challenger-1 in the URL) to:

   • Force a specific variant
   • Confirm that the correct content loads for each variant

2. Verify that the experiment pill/rail shows the experiment as active and that variants resolve correctly.

6. Go live and monitor results

1. Publish the control and challenger pages plus their metadata.

2. Let the experiment run until:

   • A minimum traffic threshold is reached
   • The experimentation reporting indicates sufficient statistical confidence

3. Use the plugin’s reporting view (and any connected dashboards) to compare:

   • Visitors per variant
   • Goal completions (for example, clicks, sign‑ups, or downstream conversions)

4. Once a clear winner emerges, update your site:

   • Promote the best-performing variant to the new control
   • Stop or archive the experiment in the plugin

Why the Plugin Approach Fits EDS

The experimentation plugin is aligned with EDS architecture:

• It uses existing authoring tools (documents or Universal Editor) instead of a separate UI.
• It stores configuration as page metadata, so your experiments are versioned and deployed alongside content.
• It keeps decision logic close to the edge, avoiding heavy client‑side frameworks or blocking scripts.

This combination keeps experiments fast, low‑overhead, and resilient to code changes—exactly what you want on an EDS site.