Yes. You can use event Jinja inside an aggregate when you create the aggregate directly in a scenario Condition node and enable personalization.
You cannot use the same setup in Data & Assets > Data manager > Definitions. Standalone definitions, such as Aggregates, Running aggregates, Event segmentations, and Expressions, do not support Jinja in the same way, so the definition may not save or work as expected.
Why this works
After you enable personalization in the Condition node, trigger event properties become available in Jinja. This lets the node evaluate the aggregate filter dynamically for the event that starts the scenario.
For example, the node can check whether a customer has a purchase event with the same purchase_id as the trigger event, instead of checking for any purchase.
Figure 1 shows the aggregate created inside the Condition node. Figure 2 shows the same aggregate used in the main condition.
Figure 1: The embedded exists(purchase) aggregate uses purchase_id equals {{ event.purchase_id }} inside the Condition node.
Figure 2: The main condition checks whether the embedded exists(purchase) aggregate is true.
Example
In the example setup, the condition uses an embedded exists(purchase) aggregate.
Inside the aggregate, the filter is purchase_id equals {{ event.purchase_id }}.
The main condition then checks whether exists(purchase) is true.
This pattern works because the aggregate is created inside the scenario node, where Jinja can use trigger event properties.
Summary
You can use this type of Jinja-based aggregate inside the scenario Condition node.
If you create the same logic as a standalone definition in Data & Assets > Data manager > Definitions, it does not work.