support home

Back to website
Login  Sign up

Allow choosing a different purpose/category than the default for an existing built-in service/purpose

Sometimes the purpose associated with a built-in service is simply not accurate or not the best fit for your particular site. 

While the ability to add a service to your privacy/cookie policy from a directory of ready-made services is useful to a point, it really limits its usefulness when you can't customize the service at all.

Sure, you can just create a new custom service, but copying and pasting means we wouldn't benefit from any updates that Iubenda made to the service description on their end. (I assume this might have been one of the reasons this feature was requested.)

Examples of when it would be useful to be able to override the Iubenda-provided default purpose for a built-in service that you're adding to your policy:

1. The AddThis service is hard-coded as being for the "Interaction with external social networks and platforms" purpose, which is hard-coded as being in the "Experience enhancement" (id 3) category.

That might be all well and good for many users, and is probably a reasonable default category to put it in, but it is problematic for two reasons:

1.1. Some people might disagree that AddThis is that innocuous and would be more comfortable listing it under the Targeting & Advertising category instead.

According to Cookiepedia:

> The main purpose of cookies set by this host is: Targeting/Advertising

> The main business activity is: AddThis provides web widgets that site owners embed into their pages or other content, to enable visitors to create and share links to the content across social networks. They also make use of the data collected to provide advertisers and marketers with profile information for targeted, behavioural advertising.

Consistent with that, I noticed that OneTrust auto-categorized them as Targeting Cookies.

So although the intended purpose of AddThis is for social media sharing, it has the unintended side effect of also enabling targeting.

By bundling AddThis with other Experience enhancement cookies, it makes it impossible to opt in to other Experience enhancement cookies without also opting in to these (what could also be categorized as) Targeting/Advertising cookies (id 5).

1.2.  A more practical problem that this classification creates is a bug that is almost impossible to work around currently — but which would be so easy to work around if only it were possible to override the default purpose/category for a given built-in service (just temporarily move it to Measurement category in my cookie policy until the bug is resolved upstream):

Specifically, it looks like the Iubenda Wordpress plugin has AddThis classified under Measurement (id 4). As a result, even though Iubenda itself classifies it under Experience enhancement (and shows it under that category in your cookie policy), if you give consent for that category (id 3), it will not enable the AddThis scripts. And if your cookie consent isn't even configured to include any Measurement cookies, then there would be no way for the user to the AddThis scripts using per-category consent.

You can track this bug here.

2. reCAPTCHA has similar concerns about adding unwanted Targeting/Advertising cookies

(See for example, here and here.)

Since CAPTCHA is usually only needed when a user actually intends to submit a form, it should be possible to override the category of the "Spam protection" purpose from its default category (Strictly necessary) to one that makes the most sense for your specific site:

  • On sites where publicly-accessible forms (such as a general contact form) would be considered  a basic interaction, but not an essential one, then Owners should have the option to categorize Spam prevention in the "Basic interactions & functionalities" (id 2) category.
  • On other sites where the main (or only) use for spam prevention is for comments, then it should be possible for Owners to instead categorize it as "Experience enhancement" (id 3), to be consistent with the "Content commenting" purpose itself!

But as it is now, having it hard-coded as a Strictly necessary (which by definition is one that cannot be opted out of) means that users cannot opt out of those particular cookies, even if a website Owner wants to give them that choice.

One way that moving that purpose into another category could be leveraged is that users could leave that category turned off until they run across a feature on the site that required it (which, if they never encounter a need to turn it off, they can just leave it off). This kind of just-in-time consent gathering used for reCAPTCHA is described in this article:

> This form uses ReCaptcha. Before sending the form, please accept cookies before sending the form

3.  The "Handling payments" purpose is hard-coded to be in the "Strictly necessary". But that depends on the individual site and is not always accurate!

Sure, it would be accurate for an e-commerce site, or a commercial service that required payment in order to use the core service, for example, but on sites where payment (donation) is optional, it should not be classified as "Strictly necessary".

In those cases, since it absolutely is not strictly necessary to make a payment in order for the site to provide the Service, users should have a meaningful choice (as required by the GDPR) as to whether to consent to such cookies, but because they are classified as "Strictly necessary", they have no such choice.

2 people have this problem
  • Hello Tyler,

    Thank you very much for submitting this very detailed request.

    We are definitely going to discuss it internally and let you know as soon as possible.

    Kind regards,



    5 people like this
  • Hello guys,

    Any progress on this?

    LogRocket is misclassified - it should be considered Analytics - but there is no easy way to fix this

  • Hello, 
    It is detailed query. Users face this issue but i think it is not resolved yet. Anybody know what is the status of this problem? Thank you. 

  • Hi Tyler,

    Apologies for the delay in getting back to you.

    There still isn't a way in our product to do exactly what you ask, other than defining a custom clause and assigning a particular category to it.

    As you note, there are limitations both to copying and pasting a base service definition from a supplied one and to accept some categorization where the actual use case might differ subtly in practice.

    We recognize part of these limitations in our introduction to our Custom Service instructions saying the following:

    << But there will always be things that we don’t have, can’t integrate or that are highly personal. >>

    Please refer to this guide:  

    And we see how your ideas might offer some benefits to some users. As we regularly review our feature requests, though, we try to give priority to things that benefit the most users whilst remaining legally accurate. Striving for that balance means that we can't satisfy all requests as they are. The link above goes into a bit more detail about our approach to customization.

    We do not forget these requests, even if we don't get to implementing them as they are. They are regularly reviewed and re-considered and assessed based on how many users would benefit from them and how hard it would be to implement them in legally strict way whilst allowing for the flexibility.

    We appreciated your detailed submission and think that other users might have benefited from your insight as they read your post, not just us.




  • Same result as before the user faced issue. Any other ideas?

  • It is a thorough inquiry. Users encounter this problem, which I believe has not yet been fixed. Does anyone know the current state of this issue? I'm grateful.

  • I would also like this feature request implemented.  It is disappointing to me that it seems to have been rejected.  I'm just starting with iubenda, and I am very seriously considering quitting it before deploying my policies and starting over from scratch.  Customization beyond iubenda's options and few opportunities for custom text is a critical feature.  This should not be technically difficult to implement.  It's a shame that customization of ALL content isn't a current feature because I otherwise like much of what iubenda has done in terms of facilitating the addition of services into the Privacy Policy. 

  • +1

Login or Signup to post a comment