Hi everyone! I'm writing the code for fact table and creating metrics based on it. 1) event_name filtering In the where clause I have this code because the event_name should be there in a fact table as I understand:

WHERE 1=1

AND event_name = '{{ event_name }}'

And if I have these lines in my code, can I create filters like on the screenshot? Both the ones with "=" and "in" structure? Will it work or should I write it differently? 2) other filters If I want to have metrics with different filters on the "platform", then I shouldn't write it in the "where" in fact table script at all? I just need to create appropriate filters for this fact table?

⭐ Our official support hours are 6:30am - 5pm Pacific Time, Monday through Friday. You may occasionally hear from us outside of these hours. Your support request has been logged in our system. Our support team will get back to you very soon!

Hey, Aksinia! One sec - let me double check with someone on the team more familiar with Fact Tables.

Hi, I can help you out. If there's a filter that should apply to every single metric, then you should add it directly to the

WHERE

clause of the fact table definition. For everything else, you should use filters. So in your example, you should remove

AND event_name = '{{ event_name }}'

from the WHERE clause. That way, your fact table will include all events. When you create a metric, you would add the appropriate filter to restrict it to the specific event. Same with platform, you should create filters instead of adding it directly to the WHERE clause

Thanks! And if I want to filter dates, this rule is no longer fair and I need to write additional conditions in the Where clause? For example:

AND timestamp_micros(e.event_timestamp) BETWEEN '{{ startDate }}' AND '{{ endDate }}'

AND s.event_date BETWEEN date('{{ startDate }}') AND date('{{ endDate }}')

Sorry for the late response. First, the

{{ startDate }}

, and

{{ endDate }}

placeholders are just meant for performance optimization when your data is partitioned by date. They can serve as hints to the query engine to limit the amount of data that needs to be scanned. Not really meant to actually affect the value of a metric. Second, for the error it's likely an issue with the fact table SQL itself. I have a PR open to add more debugging for fact table filters that I hope to merge today that should provide more info. https://github.com/growthbook/growthbook/pull/1945

Thank you for this important feature! It helped me find a bug - https://growthbookusers.slack.com/archives/C01T6Q1SVFV/p1702538732455039