What is (and isn't) in the commercial bundle?

[SiAdcock]

The commercial bundle is loaded on all pages of the Guardian. The original intention was to allow Commercial Dev to share commercial logic between DCR and frontend in a way that was truly independent of each platform and its associated deployment process.

The commercial bundle's features include:

• creating ad slots in articles using the Spacefinder tool
• preparing various third party ad providers
• filling ad slots using Google Ad Manager (consented) and OptOut (unconsented)
• defining configuration for multivariate tests related to advertising
• recording commercial metrics
• logging ad-related errors to Sentry
• preparing non-advertising third parties such as Dotmetrics (Ipsos Mori) and Comscore
• collapsing unfilled ad slots that are hardcoded on the platform
• detecting whether a user is eligible for an ad free experience and if so, collapsing ad slots that are hardcoded on the platform

The commercial bundle does not:

• add Labs containers (e.g. dumathoin) to fronts
• add fixed slots to articles e.g. the right ad slot

From this discussion, I'd like to ensure the above lists are accurate and reasonably complete so that they can be documented for future reference.

We would then know the impact of the commercial bundle failing to load, whether intentionally (e.g. by offering a commercial-less experience to users) or unintentionally (due to network conditions, ad blockers blocking us, etc).

Documentation should also help ensure that the commercial bundle only grows intentionally i.e. anything added to the commercial bundle fits its defined remit. Any attempt to expand its remit can be questioned.

The context of this discussion is that the Open Journalism team recently introduced a change that prevented the commercial bundle from loading for ad free users (guardian/frontend#25909) This had a few undesirable side effects, notably making it impossible for a user to opt in to receiving advertising once they had opted out. If we had had a better understanding of the impact of this change, we would have had a reasonable chance of preventing such side effects.

My questions for this discussion:

• are the above lists accurate and complete?
• do the above lists represent what the commercial bundle ought to be doing? Is there anything in the commercial bundle that should be the responsibility of the platform, or the other way around?

[arelra]

are the above lists accurate and complete?

It would be great to have a comprehensive list to understand responsibilities and boundaries.

The features above are quite high level and therefore don't include sub-features e.g. header-bidding, page skins, iframe messaging, passbacks, commercial-templates etc. Sub-features are probably not important from a responsibilities / boundaries point of view but it might be useful for the teams understanding.

We attempted something like this a while ago:

https://docs.google.com/spreadsheets/d/1P2okuRU1Hx4Ka1OwaDu-v6xtHfxmBvgO0811jqa6oOA/edit#gid=0

do the above lists represent what the commercial bundle ought to be doing?

Something I feel that the commercial bundle should not be doing is setting reader revenue subscription cookies. As a legacy of having lived in Fronted, we rely on shared modules such as 'user-features' which afaics reader revenue rely on to set subscription related cookies. I'm following this up with them to work out their exact dependency.

If we had had a better understanding of the impact of this change, we would have had a reasonable chance of preventing such side effects

In terms of providing more safety when we assess changes to complex pieces of functionality I think holding that in our heads and interpretation is prone to error so I'm not sure documentation alone can solve it completely.

To better catch regressions I'd advocate for tests to cover more complex features (preferably unit / integration) so contributors have reliable automated feedback.

Ideally the tests themselves then act as a form of documentation.