Add shouldReportToOphan to ABTest type

[domlander]

What does this change?

Adds shouldReportToOphan to the ABTest type. The network request that is sent to Ophan that includes the users test participations will exclude a test if the test object has shouldReportToOphan defined and evaluates to false on the client.

Why?

So that server-side AB tests have a way of excluding users from the test on the client.

Client-side AB tests are able to exclude users using logic in the components. Server-side tests do not have this luxury as the page may have already been changed. For example, an AB test that removes the Highlights container on fronts cannot reinstate this container on the client. There would be a horrible flash of content and high CLS when the client-side code runs and the highlights container is inserted. If we wanted to run a test like this but ONLY include users that have a certain cookie, for instance, we would still show the user the experience based on their allotted variant, but choose to NOT report the user to Ophan if they don't have this cookie set.

I thought shouldReportToOphan was more accurate than canRun which was used in the previous AB testing framework, as the user will still see the experience dictated by their test variant; only the reporting is affected.

This server-side AB test attempts to only include users at certain screen sizes. This PR will allow for accurate analysis of test results.

[github-actions]

Deploy build 25623 of dotcom:rendering-all to CODE

All deployment options

• Deploy build 25623 of dotcom:rendering-all to CODE
• Deploy parts of build 25623 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[github-actions]

Deploy build 1050 of dotcom:ab-testing to CODE

All deployment options

• Deploy build 1050 of dotcom:ab-testing to CODE
• Deploy parts of build 1050 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[github-actions]

Hello 👋! When you're ready to run Chromatic, please apply the run_chromatic label to this PR.

You will need to reapply the label each time you want to run Chromatic.

Click here to see the Chromatic project.

[arelra]

@Jakeii I assume we don't attempt to serialise the tests anywhere?

[Jakeii]

Nope they aren't, so having functions here should be fine

[cemms1]

Could this be a boolean rather than a function? Similar to shouldForceMetricsCollection?

I'm possibly misunderstanding how this should work. Maybe an example could be useful here?

[domlander]

I've just given it a try. shouldReportToOphan is evaluated on the server if it is a boolean rather than a function, which I don't think we want to happen. It also doesn't work when testing locally (the ophan request is fired every time), and with a condition to stop it blowing up on the server, e.g.:
shouldReportToOphan: typeof window !== "undefined" ? window.innerWidth >= 1300 : false
If I've misunderstood please let me know.

[cemms1]

Makes sense that we want this to be able to be evaluated away from the server! Maybe an extra comment would be useful here to indicate why this is a function not a boolean since this isn't obvious at the moment and the naming convention follows the booleans

[domlander]

I've updated the comment to hopefully make it a bit clearer. I'm not entirely happy with the name so I'm open to ideas for improvement.

[Jakeii]

Could you add a specific usage example to the comment, the breakpoint is a good example.

I think it is also applicable to client-side tests? They can exclude users from the functionality being tested but not the reporting!

[domlander]

Yes, this could also be used for client-side tests. I'll make the server-side comment as an example rather than the use case. I'll also update the comment to specify an actual example.

[Jakeii]

Nice addition, I think this will come in handy for future tests too!

[gu-prout]

Seen on PROD (merged by @domlander 7 minutes and 20 seconds ago) Please check your changes!