Add a rule for Joybuy

[GravityCore]

Works for joybuy.nl, joybuy.co.uk, etc.

[MidasN]

Nice, thanks! I have two requests, if possible:

1. Could you rename the rule to joybuy.co.uk.json? I think this cookie banner is unique to this website (I tried to dig into the code to see if it's part of a CMP, but I couldn't find anything), and I will try to clean up the rules so it more clearly indicates whether something is a URL or a CMP.
2. Could you use language filters for selection targets? Right now you're selecting buttons and toggles by traversing the DOM and using nth child selectors. This is rather fragile in case the order of interface elements changes. If this banner is unique for this website, that's most likely fine, but in situations where it's a general CMP then the chances of clicking on the wrong things is a lot higher. I would prefer if this rule uses the language filter options to select the elements (e.g., Customize, Functional cookies, etc). The downside of this is that if this page is multi-lingual, it'll need to support all those languages in the language filter. Happy to help further with this if necessary!

[GravityCore]

This website is for 6 countries (ccTLDs) and 5 languages, as seen on Joybuy Customize location page. Is there a specific reason why I should add co.uk into the .json filename? This is a port of a Chinese website to EU and the rule is meant for not only co.uk ccTLD.

For this website, I don't feel like language filters here would be a much better solution, and sadly they are often using semantically meaningless and non-unique IDs and classes for the elements, which makes selecting the correct ones a headache.

What I can do is select the button for opening the options using data-exp button attribute, as it has data-exp="..Customer_cookie..", which seems to be the same across languages and indicates changing the cookie settings. But for the buttons on options pane, I could use the gibberish but unique and stable class names such as jdi-2x3e2m, which also are consistent across languages.

As for the toggle switches, this website is using the 4 main common sections in a common order: Essential (nontoggable) Function, Analytics, Advertising. I don't see any reasons for why they should change this order or the elements, as the HTML elements they are using for the website seem to be from some kind of a MUI website template, which I guess they can't tinker with too much, nor will the provider of the template do so (too many dependants -> not worth it). So the order and number of elements there seems to be stable (i.e., no risk of breaking).

What do you think would be the reasonable and non-breakable solution based on this info?

[MidasN]

Hmm. My goal with the "domain as rule name" is to make it possible to track down the website at a later point if we want to update/check/maintain the rule somehow. I suppose it doesn't really matter if it's joybuy.co.uk, or joybuy.nl, or any of the other ccTLDs (except that .co.uk feels more "universal" than the other country domains, but that's pretty subjective). Happy to hear your thoughts about other solutions as well, if you have any. I've considered in the past having metadata properties as part of the rule JSON, but that feels messy, so rule name is currently the only approach.

For the rule design, my main concern with relational position or gibberish selectors is that the rule won't break if they swap things around, which would result (from the user side) in accepting data processing for purposes the user didn't want to. Imagine someone said they gave consent for content personalisation, but not ad personalisation. If somehow the order of things changed (for example if they split things up, or reorganised it), the rule wouldn't break. The language-based approach would at least prevent that from happening, since it'll consent specifically related to the purpose, so if those are renamed it'll stop working.

To be honest, it’s a tricky balance between ensuring the rule remains robust to changes, maintaining confidence that CoM will actually submit user preference answers, and avoiding a rule-making process that becomes overly burdensome. There's different factors that can help weigh each factor. For example, this includes estimating the likelihood of changes based on factors such as the use of third-party services (e.g., MUI) or whether the banner comes from a site-specific or widely used CMP; considering the impact of not respecting user preferences—especially since most users likely leave all options toggled off, making fine-grained rules less critical (though we don’t collect user data, so we can’t verify this); and assessing how localization affects the effort required for language-based rule-making.

Happy to hear any thoughts or suggestions you have on this. In this case, since the website only uses 3 EU languages (NL, EN, FR) and the purpose descriptions are pretty straight forward (analytics, advertising, etc) I'm leaning slightly towards language based. But better more rules than perfect rules, so can also just go with what you have now :)

[GravityCore]

Yeah, I understand the concern for false selections. For this website, the language filter is an OK solution and I will implement it soon (got busy here as well). But if the number of languages go over 7-ish, then I will try other approaches (as was the case for SAS in #542).

The rule json could have an optional, only informative metadata property, which would hold an array of URLs/ccTLDs for which the rule has been tested to work correctly. I am currently mentioning them in the commit message. With this property, the filename wouldn't have to contain the domain, nor would the rule creator then have to think which one is the most "appropriate".