Ignore cookie-database sites in tracker mapping
Cookie-database and consent-directory sites (Cookifi, Cookiepedia, cookiedatabase.org, CookieServe, ...) rank highly in web search only because they catalog cookies, not because they set them. The mapping agent could attribute a tracker to the directory operator itself instead of the vendor the page names. Instruct the agent to treat such results as reference directories and extract the named vendor, never the operator, while keeping a CMP's own product cookie attributable (OptanonConsent -> OneTrust, CookieConsent -> Cookiebot). Add a conservative code backstop that discards attributions to pure aggregators, scoped to exclude CMP vendors so legitimate own-cookie attributions survive. Signed-off-by: Émile Ré <emile@probo.com>
This commit is contained in:
@@ -24,6 +24,8 @@ Return a structured JSON response with:
|
||||
- Stop searching once you get a confident match; do not exhaust all query slots if the first one succeeds.
|
||||
- When evaluating web search results, verify that the tracker name discussed in the result shares a meaningful prefix with the pattern you are identifying. Trackers with different prefixes are distinct — for example, _hjCookieTest (Hotjar's _hj prefix) must not be confused with a pattern named cookietest (no _hj prefix). If the search result discusses a tracker whose prefix does not match, discard it and continue searching or lower your confidence.
|
||||
- A generic token shared with a vendor's terminology is NOT a match when it appears as a suffix or substring behind a different, meaningful prefix. The leading prefix is what attributes a vendor, not a common word elsewhere in the name. For example, probo_distinct_id carries the custom prefix probo_, so it must NOT be attributed to Mixpanel merely because Mixpanel uses a distinct_id key — the prefix probo_ does not belong to Mixpanel. Likewise, a key ending in _session or _uid is not attributable to a vendor just because that vendor also uses such a word.
|
||||
- Some web search results come from cookie-database or cookie-banner directory sites (e.g. cookifi.com, cookiepedia.co.uk, cookiedatabase.org, cookie-script.com, cookieserve.com, and similar "cookie database" / "cookie scanner" directories). These rank highly only because they catalog cookies, not because they set them. Treat such a result ONLY as a reference directory: read which actual vendor the page names as the setter of the tracker, and attribute to THAT vendor. NEVER set third_party_name to the directory operator itself (e.g. "Cookifi", "Cookiepedia", "Cookie-Script", "CookieDatabase", "CookieServe") — they are never the third party that set the tracker. If such a page names no concrete vendor for the tracker, ignore it and continue searching or return an empty third_party_name with third_party_confidence below 0.3.
|
||||
- Exception: a consent-management vendor's OWN product cookie is still attributable to that vendor on the strength of its naming convention, independent of where the search result was hosted — e.g. OptanonConsent / OptanonAlertBoxClosed -> OneTrust, CookieConsent -> Cookiebot, cookieyes-consent -> CookieYes. Judge that on the naming convention alone, the same way you would any other vendor.
|
||||
|
||||
4. Common cookie naming conventions to recognize:
|
||||
- _ga*, _gid, _gat*: Google Analytics
|
||||
|
||||
Reference in New Issue
Block a user