Smart cookie scanning: self-learning for an always compliant site

If you enable the auto-learning option, anyone who browses your site, on all pages, will help train your CookieMan, and every detected cookie will be cataloged.
This is the option we recommend. However, there may be circumstances where enabling this option results in the cataloging of unwanted cookies.
There are indeed some unofficial crawlers that, during their site verification activities, might install cookies for their own needs.
Official crawlers, such as Google’s, do not have this issue because they are recognized as such by CookieMan and do not impact the cookie inventory.
Unofficial crawlers could do so.
If you detect some cookies that you don’t recognize, we recommend enabling the option Limit cookie self-learning and adding the IP addresses allowed for detection.
IP addresses can be entered one below the other in the IP whitelist area.
You can enter as many IP addresses as you want, such as yours, your developer’s, your digital agency’s, etc.
In this way, only when users browsing from these IP addresses detect new cookies, CookieMan will accept the request for registration.
By enabling this option, you will see in the list of cookies those registered through the auto-learning process, marked with a symbol to indicate that they were detected from known IP addresses.

Yes, self-learning is designed to ensure that your site meets the requirements of GDPR and other international regulations.

CookieMan ‘s self-learning uses intelligent cookie scanning to detect any changes in your site in real time.

Unlike traditional scanners, which are limited to static and periodic scanning, intelligent cookie scanning via self-learning performs continuous checks, ensuring accurate and up-to-date mapping of cookies and other functional features of your site. This functionality is critical to ensuring compliance with regulations such as GDPR, CCPA and other data protection laws.

The self-learning of CookieMan:

• Performs verification and learning activity from the client in asynchronous mode: thus, it is the activity of each visitor on your site that makes it possible to constantly and continuously monitor
• Has accessto all pages where a visitor, including by entering login credentials, can access
• It also has access to direct landing pages
• It integrates with the CookiePedia to define the complete way the cookies found
• Also note other aspects that may change on your site (e.g., Google Consent Mode activation, TCF 2.2 integration) by reporting them to help you keep your site secure and compliant

There are many cookies that are recorded with a variable part in their name, typically an identifier representing a user or a blog article, etc.
There are other cookies that have an identifying part in their name, but they are always registered with the same name.
Let’s look at some examples:

• the cookie et-saved-post-* is used by some WordPress site themes. The cookie is recorded with the name et-viewed-post- followed by a number that identifies the post code. For example, if you view one post, the cookie et-saved-post-123 might be saved on your PC. If you view another post, the cookie et-saved-post-456 will be recorded, and so on.
• the cookie _ga* is used for integration with Google Analytics. Each installation has its own identifier, so for a site, the cookie will always be recorded with a name like _ga_AS1554DD. There is a variable part, but it will always be the same for a given site. If there are multiple cookies, it’s because multiple Google Analytics accounts have been integrated, and it is correct for both to be added.

What we want to achieve is a different management approach for the two types of cookies:

• for the first type, we want only one cookie to be added, called et-saved-post-*, even though there will be multiple cookies recorded with different variable parts
• for the second type, we want a cookie to be added for each detection, such as _ga_AS1554DD and then _ga_BA16255

With CookieMan, you can easily manage this option:
In the cookie definition, enter the name with the asterisk, for example, et-saved-post-* or ga*.
Then, in the Options section, enable the option Make the variable part of the cookie dynamic only for the et-saved-post- cookie in our example.
The result will be as we described.

Remember: if the cookie is automatically added to your site by CookiePedia, it will be CookieMan that has defined it correctly.

Scanning is an activity that allows the CMP (cookie banner) solution to check whether any components (e.g., plug-ins) have been installed on the site that have caused the installation of some new cookie that had not previously been surveyed.
Since it is mandatory to show the visitor the full list of cookies and let him or her choose which ones to give consent for, it is essential that the list of cookies is always up-to-date.
However, the scanning process is a process that has some critical issues, which by its nature, cannot be solved:

• although close, the scanning activity is performed in a scheduled process and, between scans, the information rendered to the visitor is not updated (among other things, CMP solutions often attribute a cost to the increased scanning frequency)
• pages that cannot be reached because they are not linked within the site will not be scanned by the process (e.g., landing pages)
• pages that cannot be reached because they are protected by login credentials will not be scanned by the process that cannot reach them
• dynamically constructed pages will not be scanned by the process
• pages that register cookies only when certain conditions occur (such as completing an online order) will not be scanned by the process

That is why CookieMan uses a different technique: the self-learning.
Find out how it works.