Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(v2): adding support for multiple experiments, audiences and campaigns per page #28

Open
wants to merge 53 commits into
base: main
Choose a base branch
from

Conversation

ramboz
Copy link
Contributor

@ramboz ramboz commented May 24, 2024

This is a complete rewrite of the engine to support multiple experiments, audiences and campaigns per page, as well as hiding configurations behind named sheets.

Features:

  • Add support for multiple experiments, audiences and campaigns per page (1 at the page level, 1 for each section, and n for fragments/blocks).
  • Add support for specifying a manifest as config for each leveraging hidden sheets so the configs are not exposed by default
  • Expose new JS API to track what experiments/audiences/campaigns were applied to the page:
    • window.hlx.experiments/window.hlx.audiences/window.hlx.campaigns which are JS arrays containing the page modification details. The format is:
      {
        type: /* one of "page", "section" or "fragment" */,
        el: /* the DOM element the changes applied to (body, section or fragment) */,
        servedExperience: /* the URL for the content that was inlined for that page modification */,
        config: { /* experiment/campaign/audience details */ },
      }
    • the old singular equivalents (i.e.window.hlx.experiment) are still around for backward compatibility but will only contain the page-level type modifications
  • Expose a new DOM Event with experiment/audience/campaign details for easy integration with reporting or third-party libs
    document.addEventListener('aem:experimentation', (ev) => console.log(ev.detail));
    /* The event details will contain:
       - type: one of 'experiment', 'audience' or 'campaign',
       - element: the DOM element that was modified,
       - the experiment and variant name, the audience name, or the campaign name
    */
  • Add E2E tests and code coverage reporting

BREAKING CHANGE:

@ramboz ramboz marked this pull request as ready for review May 29, 2024 16:42
Copy link

codecov bot commented May 29, 2024

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

ramboz and others added 11 commits May 29, 2024 16:57
<!--- Provide a general summary of your changes in the Title above -->

## Description

This feature allows authors to specify custom labels for **both page and section experiment variants** via metadata and section metadata. While the internal variant IDs remain in a predefined format (e.g., challenger-1, challenger-2), the labels in the overlay pill can be customized to provide more meaningful names.
## Description

Fix the getMetadata function in extracting metadata tags from the
document's head. The function now is able to handle meta tags with names
or properties. (e.g. < meta property="campaign:-registration"
content="https://main--wknd--hlxsites.hlx.page/drafts/xfeng/page-variants/page-variant1"
>)
ramboz and others added 14 commits July 19, 2024 10:44
When the format `Audience: mobile `or `Campaign: c1` appears in the page
metadata, the space after the colon will be read as a hyphen which could cause a potential issue when we extract the value by applying the substring based on the string length.
<!--- Provide a general summary of your changes in the Title above -->

## Description
Fix making request failure caused by the difference between provided url
in doc and the domain serving on webpage.
<!--- Describe your changes in detail -->
![Screenshot 2024-07-24 at 8 43
32 AM](https://github.com/user-attachments/assets/d1e22a1a-81e6-49e6-9b8b-c7d141ff11e8)

<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)

## Checklist:

<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->

- [x] I have signed the [Adobe Open Source
CLA](https://opensource.adobe.com/cla.html).
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.
<!--- Provide a general summary of your changes in the Title above -->

## Description
Leverage"Variant" entry in manifest to support variant name
customization for fragment experimentation.

<!--- Describe your changes in detail -->
![Untitled
(1)](https://github.com/user-attachments/assets/74c8f053-c2c9-4c3d-9009-558b0e98e4ad)
## Related Issue


## Related Issue

<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an
issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps
to reproduce -->
<!--- Please link to the issue here: -->

## Motivation and Context

<!--- Why is this change required? What problem does it solve? -->

## How Has This Been Tested?

<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->

## Screenshots (if appropriate):

## Types of changes

<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)

## Checklist:

<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->

- [x] I have signed the [Adobe Open Source
CLA](https://opensource.adobe.com/cla.html).
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.

---------

Co-authored-by: Julien Ramboz <ramboz@adobe.com>
<!--- Provide a general summary of your changes in the Title above -->

## Description

<!--- Describe your changes in detail -->

The **branch** with preview files:

https://github.com/adobe/aem-experimentation/tree/gh-pages


**Todo:**

Configure the adobe.github.io to point to the gh-pages branch.




## Types of changes

<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)

## Checklist:

<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->

- [x] I have signed the [Adobe Open Source
CLA](https://opensource.adobe.com/cla.html).
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.

---------

Co-authored-by: Julien Ramboz <ramboz@adobe.com>
<!--- Provide a general summary of your changes in the Title above -->

## Description

The fragment decoration needs more logic on handling decorations. 
We leveraged Eventlistener, at the same time introduce decoration
handler on index.js to handle the logic of redecorating.

<!--- Describe your changes in detail -->
`reDecorateBlocks` function and `buildBlock` fucntion are defined inside
of project's script.js, where we need to pass from.
```
export function reDecorateBlocks(el) {
  if (!el.classList.contains('block')) return;
  decorateBlock(el);
  loadBlock(el);
}
```

## Related Issue

<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an
issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps
to reproduce -->
<!--- Please link to the issue here: -->

## Motivation and Context

<!--- Why is this change required? What problem does it solve? -->

## How Has This Been Tested?

<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->

## Screenshots (if appropriate):

## Types of changes

<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)

## Checklist:

<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->

- [ ] I have signed the [Adobe Open Source
CLA](https://opensource.adobe.com/cla.html).
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
… page metadata (#41)

<!--- Provide a general summary of your changes in the Title above -->

## Description

<!--- Describe your changes in detail -->
In the demo, we agree that defining `Experiment Name` property for
customizing variant name is not intuitive enough and can confuse with
`Experiment` property.
Therefore, I update the doc to `Experiment Variant Name` or `Experiment
Variant Names` , that authors can define the variant name and also
leverage the experimentsMetaTagPrefix.
<img width="400" alt="Screenshot 2024-08-06 at 9 23 40 AM"
src="https://github.com/user-attachments/assets/7ebb66f5-2977-45f2-a470-916928b4f2cc">



<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)

## Checklist:

<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->

- [x] I have signed the [Adobe Open Source
CLA](https://opensource.adobe.com/cla.html).
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.
<!--- Provide a general summary of your changes in the Title above -->

## Description
The aim is to run full-page experimentation and personalization use
cases that fully redirect to the target URL instead of just replacing
the content for a marketer.

The new properties are introduced:
```
Experiment Resolution | redirect
Audience Resolution   | redirect
Campaign Resolution   | redirect
```
<img width="624" alt="Screenshot 2024-08-13 at 7 44 24 AM"
src="https://github.com/user-attachments/assets/60794d53-78f7-411e-9276-f6da3f165c7f">

   
When simulate the variant, rather than 'replace' the page, url is
redirected by calling `window.location.replace(url)` API

<img width="600" alt="Screenshot 2024-08-13 at 7 45 59 AM"
src="https://github.com/user-attachments/assets/eefb3c7d-72ac-4a93-9c7b-45a9aa982c88">



## How Has This Been Tested?

**Test link:**
- [wknd
page](https://experimentation-v2-integration--wknd--hlxsites.hlx.page/drafts/xfeng/experiments/page)
- [wknd
doc](https://adobe.sharepoint.com/:w:/r/sites/HelixProjects/_layouts/15/Doc.aspx?sourcedoc=%7B316CD824-E05C-452D-92DD-506039911607%7D&file=page.docx&action=default&mobileredirect=true)


## Types of changes

<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)

## Checklist:

<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->

- [x] I have signed the [Adobe Open Source
CLA](https://opensource.adobe.com/cla.html).
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
**To test:**
 1. RUM is fired before redirect
2. Page is successfully redirected in all three cases (experiments,
campaigns, audiences)
 
**Finding:**
1. Tried different ways to override the `window.location.replace () ` to
let it do nothing when testing RUM is fired before redirect.
However, some browsers have strict security restriction that don't allow
certain function to be overridden, which leads to test fails.
2. Modify the script before its execution. The line with
`window.location.replace () ` is commented out before the script is
executed and security policies are applied.

## Types of changes

<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)

## Checklist:

<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->

- [x] I have signed the [Adobe Open Source
CLA](https://opensource.adobe.com/cla.html).
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [x] I have added tests to cover my changes.
- [x] All new and existing tests passed.

---------

Co-authored-by: Julien Ramboz <ramboz@adobe.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants