Hey, is it possible to remove the metric timestamp...
# ask-questions
p
Hey, is it possible to remove the metric timestamp (
m.timestamp
) and first_exposure_timestamp (
d.timestamp
) comparison logic when calculating metric value on the results page? Basically, we need to simply use
m.value
without any date filters. cc:@ripe-optician-43107
r
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!
r
P.S. The screenshot is from the full query that GrowthBook runs when calculating the results and it automatically includes the filtering that Laura mentioned and that we want to exclude
b
Hi Laura and Paulius, thanks for reaching out! I’ll ask the team about this and get back to you soon with an update
🙏 1
🙌 2
r
Hi, could you please send me a screenshot of what you did before, but with the rest of the dashboard page in view? You can block out any sensitive info. Thanks!
If you could also explain more about your use case that would help me determine what we can do
p
Hey, here is the screenshot of the dashboard.
So, our goal is to have a metric and use it as denominator in other metrics. We need to calculate clients created during Phase period (Oct 25 - now), and we have client created date as timestamp in a metrics query and it's being filtered by Phase date ranges. However, by default, metric value is filtered by first_exposure_timestamp (m.timestamp >= d.timestamp) which is higher than client creation date and it messes our results.
I'm also attaching the full query from the results page for the mentioned metric.
r
Hi Laura, my apologies for the delay! I was able to connect with our Data Scientist about your questions related to the timestamps. The short answer to your question is "No, not safely." A hacky workaround would be putting a huge negative conversion delay and a huge positive conversion window to ensure the date logic doesn't drop any rows. We wouldn't recommend this, though, unless you're very confident the resulting SQL achieves your goals.
p
Thanks! 🙏