Matching Policies to Filter Events
Identifier Matching Policies to control which events appear in your Identifier's feed. Previously, Identifier-level filtering relied on Ignore Terms, which allowed users to exclude events containing specific terms from an Identifier's feed.
These policies replace Ignore Terms, and introduce greater flexibility through three distinct policy types: Excluded Keywords, Included Keywords, and Lucene Queries. Where Ignore Terms applied a simple exclusion filter, Matching Policies support exclusion, inclusion, and full query-based filtering, giving you more control over what appears in your Identifier's feed.
- Up to 10 Matching Policies can be assigned to an Identifier.
- All existing Identifier-level Ignore Terms will be automatically migrated to Excluded Keyword Matching Policies on their respective Identifiers.
There are three types of filtering Matching Policies, each designed for a different level of filtering precision.
An Included Keyword policy ensures that only events containing at least one of the specified keywords appear in the identifier's feed.
How it works: When you use an Included Keyword policy with keywords like product-x and product-y, the Identifier's feed will only return events that mention at least one of those terms. Everything else is filtered out.
In Lucene query terms, this is equivalent to: AND (product-x OR product-y)
Configuration: Each policy supports multiple comma-separated keywords, up to a maximum of 50.
When to use:
- You monitor a broad domain identifier but only care about events that mention a specific product name, geography, or business unit
- Your identifier for a company name matches many unrelated mentions; adding included keywords like a product name or executive name narrows the results to what is relevant
Important: An Included Keyword policy is restrictive by design. If none of the specified keywords appear in an event, that event will not show in the feed. Be deliberate about which keywords you include to avoid filtering out legitimate results.
Matching Policies and Subdomains
- Filtering Matching Policies assigned to a domain Identifier do not inherit down to its subdomain Identifiers. Each subdomain Identifier must have its own policies configured.
- A Matching Policy can be assigned to one or multiple subdomain Identifiers, either when editing an Identifier directly or from the Matching Policies list view.
Create a Matching Policy
There are two ways to create a Matching Policy for an Identifier:
- Create the policy from the Policies menu.
- Create the Matching Policy from an Identifier's configuration.
Click-through the following product demo to learn how to create a Matching Policy.
Modify a Matching Policy
When you change the content of an existing Matching Policy:
- Existing events are re-evaluated. Only events that still match the updated policy are kept in the feed. Events that no longer match are discarded
- Future events are evaluated against the updated policy. New events collected going forward will be filtered according to the modified rules
This means changes take effect both retroactively (for events already in the feed) and prospectively (for new events).
Building Lucene Query Policies
The Lucene Query Policy type unlocks the full power of Flare's search syntax for Identifier-level filtering. Here are some examples showing how to construct queries for common filtering scenarios.
Best Practices for Building Lucene Query Policies
- Start broad, then refine. Begin with basic terms and add filters (date ranges, excluded terms, field-specific searches) incrementally to narrow results
- Use parentheses to group related terms and operators clearly
- Leverage date filters such as metadata.estimated_created_at and metadata.first_crawled_at to focus on relevant time windows
- Escape special characters. If searching for symbols like +, -, (, ), {, }, [, ], ^, ", ~, *, ?, :, or \, remember to escape them with \
- Be cautious with wildcards. Broad wildcards (*) can return very large result sets. Combine them with other terms to keep results manageable
- Test queries in the search bar first. Before applying a query as a Matching Policy, run it in Flare's tenant search to preview the results and confirm it returns the expected data