I don't think I understood the question,  can you please give an example?  Here is a simple of example of a query:

There is logic built into the system that if you bring in an event variable into search (non-statistical), it will not throw an error. That said, consistency is key.

For instance, if I took the following and copied it out of the events section in my rule, the system would not have a problem with that.

 

$process.metadata.event_type = "PROCESS_LAUNCH"
(
re.regex($process.target.process.file.full_path, `\\\\psexec\\.exe$`) or
$process.src.process.file.full_path = "psexec.c" nocase
)

 However, when it comes to statistical search and dashboard charts, we introduce the match/outcome sections. Because of that, I can't just add a UDM field to my match section when I am using event variables. 

And just like in a YARA-L rule, I can't use an event variable in the match section.

 What I can do, is add a placeholder variable to my filtering statement with that event variable and then use that placeholder variable as my match variable in the match section.

This applies to both stats search and dashboards. I could also get rid of the event variables and then I don't have to deal with any of the issues I just mentioned. I tend to get rid of the event variables for simplicity but the above is a work around if you prefer to keep them.

There is logic built into the system that if you bring in an event variable into search (non-statistical), it will not throw an error. That said, consistency is key.

For instance, if I took the following and copied it out of the events section in my rule, the system would not have a problem with that.

 

$process.metadata.event_type = "PROCESS_LAUNCH"
(
re.regex($process.target.process.file.full_path, `\\\\psexec\\.exe$`) or
$process.src.process.file.full_path = "psexec.c" nocase
)

 However, when it comes to statistical search and dashboard charts, we introduce the match/outcome sections. Because of that, I can't just add a UDM field to my match section when I am using event variables. 

And just like in a YARA-L rule, I can't use an event variable in the match section.

 What I can do, is add a placeholder variable to my filtering statement with that event variable and then use that placeholder variable as my match variable in the match section.

This applies to both stats search and dashboards. I could also get rid of the event variables and then I don't have to deal with any of the issues I just mentioned. I tend to get rid of the event variables for simplicity but the above is a work around if you prefer to keep them.

I get it now, I was just curious about their difference because I’ve seen in other sources that they use the $event variable, while others don’t use the $event variable declaration. Now I fully understand the difference. Thank you so much, and I hope more features are added to the native dashboard.

one more question is it also have a benefits if we use the udm fields in match section compare to placeholder? Is there any difference on that. I think it much more clearer and organized if I use placeholder. 

Originally, we had built it to use match variables but have since loosened this to accept UMD fields or match variables or a combination of them. We are looking to broaden the datasets supported so part of me is inclined to use match variables from a consistency perspective but currently we accept both.

Thanks John, noted on that. We are looking forward to have more new features in Native Dashboard like more colors optional in bar graph, pie chart and etc.