How to manage your My Agile Privacy® Cookies

My Agile Privacy® keeps a list of the cookies and third-party services on your website. Most of them are found by the Cookie Shield on its own, and for most of them you don't have to do anything: the recommended settings arrive already configured. This guide is for when you do need to step in.

Where to find your cookies

Go to My Agile Privacy® › Cookie List. Every row is a cookie, with these columns:

• Cookie Name — the name of the service. Click it to open the record
• Auto Detected — a green dot if the Cookie Shield found it, grey if you added it yourself
• Preventive blocking status — whether that cookie is blocked before consent or not
• Suggested setting — the value we recommend for that cookie
• Allow automatic updates ? — Yes or No
• Additional code installation type — Javascript-Noscript code or Raw code, if you have attached any code
• Requires page reload on user acceptance — Yes or No
• Last update — when the record was last updated

Besides Published and Draft, a cookie can be in three particular states: Blocked without notification, Allowed without notification and Expired. You will find them in the filters at the top of the list.

How automatic detection works is explained in its own guide: How to automatically detect and block cookies with Cookie Shield.

Necessary or not necessary: preventive blocking

This is the most important choice on every record, and it is in the Is necessary? box.

• necessary — preventive blocking is not active. The tool always runs, regardless of user consent
• not-necessary — preventive blocking is active. The tool only runs after the user has given consent

Next to it you will find Suggested value for this Cookie: the value we recommend based on the nature of that service. The same information is in the Suggested setting column of the list.

Note: marking a cookie as necessary when it is not means running it without consent, and that can cost you your compliance. Unless you have a precise and documented reason, keep the suggested value.

The special cases: Google Analytics and video

For some cookies preventive blocking is not set from the record: it is governed by a central setting, because it concerns a whole mechanism rather than a single service. When you open the record, instead of the choice you will read where to change it.

Google Analytics (and Google Analytics via My Agile Pixel®): the setting is managed via Privacy Settings ▸ Consent ▸ Google Consent Mode v2. Here it is not a matter of blocking or not blocking, but of how consent is communicated to Google. How it works is explained here: Supporting Consent Mode v2.

YouTube and Vimeo: the setting is managed via Privacy Settings ▸ Cookie Shield ▸ Video privacy mode, where you choose between two behaviors:

• Anonymize video embeds — the video stays visible and is loaded in cookie-free mode
• Block with notice — the video is blocked and a clickable placeholder appears in its place

Automatic updates

The Allow updates? box governs automatic updates for that record. When we update the definition of a cookie — its description, its duration, its suggested value — your record aligns itself. You can read the date in the Last update column.

With the switch on, every update replaces the name and the text of the record with the new version.

We recommend leaving it on. It is what keeps your cookie declarations correct over time, without you having to follow how they evolve.

If you have rewritten the description of a cookie and want to keep it, set Allow updates? to No on that single record: from that moment on nothing will touch it. The downside is that the record no longer receives later corrections, and keeping it up to date becomes your job.

Attaching code to a cookie

You need this when you have a third-party script that must run only after consent to that cookie. The right place is the Script Installation type box, where you choose between two methods.

Note: on automatically detected cookies this box starts closed. To open it, tick Add custom code anyway: this is deliberate, because in the vast majority of cases automatic detection is enough.

Javascript-Noscript code. Use this when you have a JavaScript snippet. You fill in two fields:

• Custom JavaScript Code — the code that must run after consent
• Noscript Code — the <noscript> alternative, if the service provides one

Raw code. Use this when you have a complete block of HTML to insert as it is, for example an iframe or a tag that is not only JavaScript. You fill in the Raw Html Code field.

In both cases the code stays inert until the user accepts that cookie.

On the record you will also find the cookie's API KEY: it is the technical identifier you only need for advanced installations, such as the reconsent widget below.

If what you need is making a contact form with reCAPTCHA compliant, there is a dedicated guide that covers the case in full: How to make contact forms GDPR compliant.

The reconsent widget

When a piece of content is blocked because consent is missing, you can show a clickable notice in its place that reopens the preferences panel. The cookie record generates the code for you.

In the installation box, press Generate reconsent widget code. The code appears with that cookie's API KEY already in it: if your website is multilingual, choose the language from the Language menu, then press Copy and paste it into your page, where the blocked element appears.

You don't have to look up or replace any key: the generated code is already the right one for the record you are looking at.

The notice is only visible to visitors who have not accepted that cookie. When the user gives consent the message disappears on its own and the content becomes available again. You can rewrite the text between the two tags however you like; the classes must not be touched, because they are what ties the notice to the cookie.

Tip: if you have more than one element blocked by the same cookie on the same page, insert a single notice.

JavaScript dependencies

This feature is for advanced users and developers, and it serves one precise case: you have a script already present on your website that depends on a cookie and must be blocked until consent, but does not go through the installation box.

In the Custom JavaScript dependencies box you list those scripts by entering part of the file path or part of the inline code. From that moment on they are unblocked only after the user has accepted that cookie.

Note: an entry that is too generic can block unrelated scripts and break something on your website. Use specific portions of the path and check the result by browsing your website without having given consent.

Page reload

The Requires page reload on user acceptance? box is for tools that do not start correctly once the page has already loaded. When you enable it, the first activation by the user triggers a page reload.

Leave it off unless you have a concrete problem: an unexpected reload is annoying for someone who is browsing. The setting does not apply to cookies marked as necessary, which have no activation moment.

If you have any questions or need support, you can always use our contact form.