Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update aggregated conversion node to only have queried linkable specs #1381

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion metricflow/dataflow/builder/dataflow_plan_builder.py
Original file line number Diff line number Diff line change
Expand Up @@ -361,7 +361,7 @@ def _build_aggregated_conversion_node(
# Aggregate the conversion events with the JoinConversionEventsNode as the source node
recipe_with_join_conversion_source_node = DataflowRecipe(
source_node=join_conversion_node,
required_local_linkable_specs=base_measure_recipe.required_local_linkable_specs,
required_local_linkable_specs=queried_linkable_specs.as_tuple,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One of the things I love most about GitHub is how they don't allow me to comment on lines that haven't been modified. Seriously, have these people ever even reviewed code before?

Anyway, this does not work because of line 269 above. The queried_linkable_specs do not include any filter specs. So if you don't include required_local_linkable_specs you miss out on propagating any specs requested as filter elements that originate in the base measure dataset.

That's why the missing spec assertion is tripping in that conversion metric test. When we try to run a query that filters on visit__referrer_id, which is local to the base measure, that only gets added to the set of required local specs generated on line 269.

I do not know how to fix this while also fixing the other issue you're trying to resolve here. I don't even know if that's possible without a major overhaul to how we deal with filters. That said, it might be worth postponing a fix for this, since it's not clear to me what our filter behaviors against these nodes are meant to be. There are some fuzzy edge cases around applying a filter to two parts of a conversion calculation, and my sense is we do not correctly differentiate between input-measure-level filters and query-level filters, so whatever we do is going to produce unexpected results for somebody.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the issue here was that the final aggregated conversion node had the extraneous group bys, could we just pass the final aggregated node through a FilterElementNode instead of fixing it like this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe? To be honest, I don't even know what's supposed to happen here, much less whether or not removing that column from the base output will solve this problem in a reasonable way.

The basic question here is how should query-time filters get applied? If I run a query for conversions computed as visits / buys, and I filter to something like WHERE visit__referrer_id = 1234 OR buy__coupon_id = 1234 in order to get all conversions from partner ID 1234, what is supposed to happen? If I add a filter to a conversion measure input to exclude buyer__is_campaign_sourced for our organic_reach_conversion metric, what should happen? What should happen if I apply the query-time filter for partner 1234 with the organic_reach_conversion metric?

I don't think we ever answered these questions, and while some of them are pretty obvious (the organice_reach_conversion filter should be properly applied) the others are less obvious to me, and I think there are a few where it really is just a product decision around how we want this to behave and what kind of traade-offs our users will have in the configuration experience.

join_linkable_instances_recipes=base_measure_recipe.join_linkable_instances_recipes,
)
# TODO: Refine conversion metric configuration to fit into the standard dataflow plan building model
Expand Down
Loading