Help: URL filtering categories seem wildly inaccurate.

I'm conducting a post-implementation review of our Firepower Threat Defense appliances (running 7.2.4) and have hit a significant, recurring issue that is undermining stakeholder confidence in the entire platform: the built-in URL filtering database appears to be categorizing sites with a startlingly high error rate.

Our initial use case was straightforward: enforce acceptable use policy by blocking categories like "Adult Content," "Gambling," and "High Risk." However, we are consistently encountering false positives that are so far off the mark they defy logical explanation. For example:

* A well-known, reputable B2B industrial equipment manufacturer's parts catalog was categorized as "Adult Content."
* The download portal for a major enterprise database vendor was flagged as "Malware."
* Multiple internal web applications (hosted on-premises, with unique internal domain names) are being categorized as "Dynamic DNS" or "Parked Domains," causing policy violations for internal workflows.

Conversely, we've performed spot checks with known problem sites (using third-party categorization tools as a rough benchmark) and found clear misses. The "Cisco Talos Intelligence Group" branding suggests a high degree of accuracy, but our operational data does not support this.

I have a series of methodological questions for the community, as I'm now tasked with building a business justification for either continued tuning or a platform re-evaluation:

1. **Update Mechanism & Lag:** Is the categorization primarily driven by the "SRU" (Security Research Updates) or the "VDB" (Vulnerability Database)? We are on a 24-hour update cycle, but I've observed mis-categorizations persist for weeks, even after manual URL submission through the Cisco support portal. What is the typical turnaround for a reviewed submission?

2. **Cascade Logic:** How does the filtering engine handle multi-category sites? If a site hosts both a blog (Web Communication) and a download section, what determines the primary category? We've seen inconsistent behavior where adding a second, more specific category in a policy doesn't always resolve the block.

3. **Internal DNS Resolution:** For those with complex internal DNS architectures (split-brain, conditional forwarding), have you identified any correlation between DNS resolution paths and mis-categorization of internal resources? We are investigating if the FTD's DNS lookup process, when it queries external services for categorization, is somehow receiving external IPs for internal names.

My immediate workaround has been to create an extensive and growing list of manual URL overrides, but this is not scalable and negates the value proposition of a dynamic, cloud-delivered category service. I am compiling a detailed spreadsheet tracking false positives/negatives, categorization source (when visible), and time-to-resolution to quantify the operational overhead.

Has anyone performed a systematic accuracy analysis, or found a reliable method to improve categorization fidelity? The documentation is notably silent on error rates or the algorithmic methodology, which is a concern from an audit perspective.