Support custom item parameters in item_params

[dgitis]

I wanted to start a discussion around supporting custom item parameters in item_params. In particular, I'd like to discuss where we unnest those parameters.

With the changes to the base_select macros in 7ff99d7, it seems quite elegant to unnest item_params in the base_select_renamed macro as we are already unpacking and repacking the items record there.

However, this macro is called in the base_ga4__events model. I dislike changing the base model because it should be the biggest table and the full refresh required when adding item_params is literally making the process of adding a new item parameter as expensive as possible.

The alternative is unnesting in the stg_ga4__event_items model. This makes more sense to me as adding a new item parameter would only require a refresh of this model and any downstream models.

I wanted to give others a chance to add their opinions before jumping in with a PR to address this.

[adamribaudo-velir]

Just want to confirm 2 things:

1. you're talking about unnesting the item parameters out to the level of the item, not the event right? So if I have an item parameter of variant_id, it would be accessible under items.variant_id? I can't wrap my head around the SQL for that, but interested to see it.
2. users would need to specify the item parameter names in the project yml, yes?

We don't apply any custom business rules from the project yml until stg_ga4__events so I wouldn't do it in the base select macro.

I'm also up for creating a separate items model that has all the unnested item data and a join key. Seems cleaner than 1 above.

[dgitis]

We already have a separate items model, it's stg_ga4__event_items which is a table with one row per item. I guess then you agree to use that model and, the more that I think about it, the more I agree.

I'd also like to rename that model to stg_ga4__ecommerce_items to make the name more distinct from the event models. Since the model is a view, it won't really affect the model directly, but it will break downstream models. I'm not sure if changing the name is worth the effot.

[adamribaudo-velir]

Oh right! Forgot about that one.

I see what you mean about the model name. Slight preference to leave it alone to not break any user dependencies. If we see a lot of stg_ga4__ecommerce_* models coming in the future, I could be convinced we should update it.

[geo909]

Hi,

Is there any chance this will be considered in the future?

[adamribaudo-velir]

@geo909 @dgitis

I have a draft PR here. I think it works but I need to find a dataset to test with that has custom item parameters. #331

[geo909]

@geo909 @dgitis

I have a draft PR here. I think it works but I need to find a dataset to test with that has custom item parameters. #331

Hey, thanks for the quick reply!

I will be completely honest, I got confused, thought this was for default event-granularity parameters, not for item parameters. I'm still new to ga4 and I'm being confused with basic concepts, apologies. :( I thought that it would make sense to add any default_custom_parameters in the stg_ga__events model instead of only the stg_ga4__event_<each_event> model. But I don't want to hijack this PR, apologies. Let me know if there is any other issue about this or if it is a good idea to open one.

Regarding your PR, unfortunately we also don't have custom item parameters in our data so I cannot test. Running the code with mock custom_item_parameters, however, did create the corresponding fields in stg_event_items.