Denylist

AdminCP > Logs > Search Analytics > Denylist. Admin-curated patterns that prevent matching queries from ever being captured.

The denylist is evaluated as the final capture gate before a row reaches the buffer. A matching query is dropped silently: no row, no aggregate, no widget contribution.

When to use it

• Suppress staff test queries that would otherwise skew the dashboards.
• Block recognised PII patterns (email addresses, phone numbers, internal ticket IDs).
• Filter out bot-scan signatures that consistently scrape the search endpoint.
• Drop a single noisy query that keeps appearing in clusters and miscolours the canonical label.

Match types

Each entry has a pattern and a match type. Patterns are case-insensitive for Exact and Contains.

Match type	Behaviour
Exact (case-insensitive)	Block when the query equals the pattern exactly.
Contains (case-insensitive)	Block when the query contains the pattern as a substring.
Regex (Unicode)	PCRE pattern with the Unicode flag. No delimiters required. Invalid patterns are rejected at save.

Test a pattern

The denylist editor includes a Test query field. Enter a candidate query and click Test to see whether the pattern matches without saving the entry. Results are reported as Matched or No match beside the button.

Effect on existing data

Denylist entries apply to future captures only. Rows captured before the entry was added remain in the raw log until the retention window expires. To remove already-captured rows for a specific pattern, run a targeted DELETE against xf_mc_sa_search_log; the aggregate catches up on the next Daily rollup cron pass, which can be triggered immediately from AdminCP > Tools > Cron entries.