Trying to filter by genre, which for us are assigned as keywords on the Production level, but I don't see that as an option in Analytics.
Has anyone else run into this issue?
Thanks, Ryan
HI Ryan,
I was asked to filter a existing widget by genre in Analytics. We use Type drop down at performance level on Ticketing Set Up for adding a note of genre, so was able to just use that as my filter. Table in Analytics is Performance Detail, column is Type.
Appreciate not everyone will use that drop down for genre and it would be useful to be able to filter by keywords as well. I believe for this you may need to assign one of your custom data points in Analytics to look at a Keyword, but I have not had to do this yet.Would be interested to know in what you end up doing!
Donald Graham Ticketing Systems & Data Manager Birmingham Hippodrome, Hurst Street, Southside, Birmingham B5 4TB
Keywords aren't a standard field in Analytics, unfortunately. Donald is correct -- you'd have to use one of your custom fields.
I believe that custom fields are on the Constituent. Alas I would love Custom fields on Performance or Prod Season objects.
I'm not sure that's true: we have custom fields on Plans.
The issue with Ticketing Keywords in the Seats and Tickets Cube is that they can have a many to one relationship with Performances, Productions Seasons, Productions and/or Titles, and so adding them would create possibilities of value inflation in results. It's not insurmountable, apparently, but requires a lot of caution.
Gawain is correct since you can have more than one Keyword on a performance (many to one relationship). If one was attempting to use one of the custom fields in Analytics, it would need to be similar how it brings Constituencies into Analytics (a comma delimited string) that way it could show 1 row per constituent on a performance. The Custom field must include a customer number in which to join in the where clause. This means that the custom field would only show for performances with existing orders in Analytics (since they would then be associated with a customer_no). All these issues complicate creating the custom field in this use case.
Yeah. I'm not going to argue the point. We are talking about very different things.