Match Analysis

before an event reaches your feed, it passes through an ingestion pipeline that matches it against your identifiers and filters it through several independent conditions, such as your identifier configuration, categories, severity rules, and matching policies match analysis shows why an event did or did not match a given identifier, reporting the result of each condition so you can see which were met, which were not, and what to adjust in your platform configuration with match analysis, you can find out why an event you expected did not get matched, down to the identifier settings, category, severity rules, or a matching policy that filtered it, so you can trust the feed or adjust your configuration find out why an event that did appear matched, so you can understand your coverage and refine your identifiers to reduce noise viewing match analysis for an event match analysis is on the advanced tab of an event's details follow these steps to see the match analysis for an event click an event in the tenant feed or in global search to view the details panel, then click the advanced tab in the match analysis section, select an identifier from identifier scope the event is evaluated against the identifier you select review the result of each condition to evaluate what conditions matched or did not match conditions evaluated an event can fail to match an identifier for several reasons its category, its severity, or the matching policies assigned to the identifier did not align with the event's data, among others select an identifier to see exactly which condition was not met an event matches only when it passes every one of the following conditions condition what it checks identifier query whether the event contains the identifier's search terms and queries the matching terms are listed and highlighted in the event categories whether the event's category is one of the selected categories in the identifier's configuration severities whether the event's severity matches the severity defined in the event’s configuration matching policies whether the identifier's matching policies allow the event to be matched an included keyword policy passes the event when it matches, while an excluded keyword policy blocks the event tenant ignored terms whether an ignored terms policy on your tenant removes the event tenant duplication policies whether a duplication policy removes the event these policies remove an event when the same content already exists in your feed the result shows the existing event match analysis in global search when running match analysis from global search, the event is evaluated in real time against your configuration as it exists now past results are not stored, so the analysis does not reconstruct the configuration that applied when the event was originally ingested because your configuration may have changed since, every matching condition can show as met even though the event was filtered out initially and never entered your tenant feed when that happens, the cause is usually one of the following rate limiting was in effect when the event was initially ingested when an identifier or tenant reaches its rate limit, event ingestion is paused for a certain time for more information, see rate limiting docid\ i7enux9t9ne6o67sr7no5 the identifier was created less than 48 hours ago matching policies docid\ zg1zxobulcijhudrj hkg or severity rules docid\ ltsdxtp9ncx7 fohtdsmk were edited or removed after the event was initially ingested