Filtering is pain, especially in Analysis Workspace, where there aren't regex options. It would be great to be able to handle filtering at the segment level. I propose adding a new container option called 'filter' or similar.
This would do exactly what it says. Only show you data for items filtered within the segment. Because we have so many products and product categories on our site we are reliant on combinations of segments and dimension components to get the views we need. Having a segment that filters for you would save a lot of time and effort in building workspaces. We try to build templated workspaces where all that needs to be replaced is the segment. however, because we have to rely on the filter or a dimension value, we must take more steps to design the report.
If filtering had regex support, would that scratch the itch? Or is this different?
This is different, but please enable regex support for filtering. : )
Picture this, I have 15 million products on my site. I capture the product on any view or related action. In some cases, I am setting > 24 products on the same server call (product list pages, cart pages, order confirmation, etc).
I have category managers who may only care about 1000 products. I am trying to solve the best way to allow them to zero in and/ or aggregate data on just these 1000 products. What is available to me are segments and filtering.
The best I can do with segments is 'Hit Based', wihich is limiting. If > 1 product exist in a server call all products will be returned by the segment, whether I care about them or not.
This leaves me with the option to filter. I have the option to use 'contains at least one of', which is we are leveraging today. This is also limiting because:
1. The longer the list the longer it takes the report to run. I have attempted 1500 or so strings and it gets to be painfully slow.
2. Seeing the aggregate metrics from a filter is difficult. I have to look at the column subtotals, which do not exist for calculated metrics.
3. It becomes difficult to compare two different filter sets.
Is this detail helpful?
Michael, I'll restate to make sure I understand. (By the way, thanks for providing the use case!)
You're trying to filter out specific products. For non-list variables, you can use a hit segment for this, but for lists that doesn't work because there are multiple values in a hit. I'm not saying we should do this, but for the sake of understanding, if we implemented a product container in the segment builder, and you filtered out specific products, would that meet the need? You want the rest of the hit, but you want to exclude a list of products, their associated events, their merchandising eVar values, and their units and revenue from the data.
Or do you just want to not see the product in the products dimension, and keep the units and revenue around?
You bring up a good point about how to handle all the other variables in the hit. I also think I am overthinking this because the solve is to use classifications. In my example, if I created a classification for 1000 products then I am good to go.The challenges are:
1. Classifications take time (up to 72 hours is the SLA, but they are definitely faster)
2. It is not scalable. I wouldn't expect end users in my org to want to classify or wait the hours for the tool to update.
So I guess I am trying to figure out a way to classify fast, on the fly, and temporarily.
Well, if fast classifications are the answer, we are already working on that. It may be a few quarters before it's both complete and rolled out across the customer base, but it's been designed and work has begun.
However, I am interested in whether a product or list-var container would be helpful in the segment builder, so if anyone else has comments, feel free to chime in.
Yes - literally yesterday we were bemoaning the lack of this functionality!
A product or list-var container would definitely be useful
Thanks for chiming in, Andy! Can you describe the use case, and if you can, the business impact of not having this functionality? That helps us identify priority relative to other changes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.