I want to include the ticketing keyword in t_keyword and I'm getting stuck on the parameters. Basically we want to be able to select all customers who bought a ticket to a performance with a particular keyword. Can anyone help?
I think I've got it. Created a view with customer_no, perf_no, tkw and tkw description.
Hi Gloria,
That should work, but keep in mind that you won’t be able to combine criteria that look at that view with other criteria that look at the ticket history to find a single purchase that meets the keyword criteria and other purchase criteria. For example you can’t say give me anyone who spent $50 on something with the comedy keyword. If you tried to do that what you would really get would be someone who spent $50 on anything and also spent any amount on something with the comedy keyword. That might be o.k. for what you want to do, but just something you should be sure to warn you users about so they fully understand what they can and can’t do with the criteria.
Interests are the standard link between constituents and keywords, though you have to set up a weighting procedure to make it work. For example, anyone who purchases something with a particular keyword gets a weight of 1 added for the corresponding interest. Then you can build a list based on people who have a weight for that interest. Of course, you still run into the same issue about not being able look for a single purchase that meets the keyword and some other purchase criteria. But the advantage is that you can start to use interest functionality for suggestions/upselling, and can easily get creative with the weight value so you can see who is really interested in something (made lots of purchases) as opposed to just tried something out.
Kevin Sheehan
Documentation & Learning Resources Specialist
Tessitura Network
1 888 643 5778 ext 329 Office
ksheehan@tessituranetwork.com
Hi Kevin,
What about if we use the criteria in an extraction? If I create a keycode that looks for all purchases with a ticket keyword, then add other keycodes, it will pull correctly, right?
No. Segments (keycodes) in an extraction are completely separate criteria sets joined by OR. So if I had one segment with one of your new criteria for keyword and a second segment with a criterion for season, I would get anyone who had purchased something with the keyword (regardless of season) and anyone who purchased something in that season (regardless of keyword) but not just people who bought something with that keyword in that season.
Any time you want to build a list or extraction that looks for a single transaction (a single ticket purchase or single contribution) that meets multiple criteria, you have to use IN as the operator and all the criteria have to be looking at the same table. Think about it like rows and columns on a spreadsheet. A ticket purchase generates a row on the ticket history spreadsheet. Any criteria that looks at that spreadsheet can be combined using IN (or any of the alphanumeric operators) to look for a single row, a single purchase, that meets all the criteria. But your view is an entirely different spreadsheet. So if you use criteria for the view, you will be looking for one row on the view spreadsheet that meets the view criteria and one row on the ticket history spreadsheet. For more detailed explanations of these concepts, you might want to check out the Criteria Sets document.
If you want you could add some additional columns to your view for things like season and maybe order date (be careful if you do that though that everyone understands that they still can’t use those criteria with other criteria from the ticket history unless they are looking for a HAS style result). Alternately you could add a column to your ticket history for keyword and then just add a criterion to reference that column. The trick with that is what to do if a performance has multiple keywords. You could certainly record them all in the column, but I’m not sure how or if you could set up the criterion to parse apart the data (I’m a bit of a SQL novice).
To sum up, what you have set up is definitely good and will be useful, you just need to know what results it can give you and what results it can’t give you. This all comes back to the differences between IN and HAS, which are the trickiest part of criteria sets, whether you are dealing with custom criteria or standard criteria.
I would like to learn more about what Kevin describes above as a 'weighting procedure' for keywords. We would like to track people's interests using the keywords attached to the productions they have purchased, but want to make sure that they actually have an interest in the genre as opposed to just buying that type of show once. A weighting procedure sounds like something that would help.
I have searched the documentation and can't find anything other than the standard keyword setup. Can anyone point me in the right direction?
Becci Brace - TN PAC
Hi Becci,
There is not any documentation on interests at this time.
To use weights for interests you have to set up a stored procedure in your database that evaluates people’s purchases and then calculates a corresponding weight for interests/keywords associated with those performances. For example, for each purchase of a performance with a particular keyword increment the corresponding interest weight by 1. In your case you might want to set it up to start incrementing only after a constituent has purchased 2 performances with a particular keyword. The procedure would then need to be scheduled to run on a regular basis. You’ll have to get an IT resource to do this for you.
You can find a sample weighting procedure on the Tessitura website with the recording of the Lean Mean Marketing webinar, and if you listen to the webinar you’ll get some explanation to go with the sample code.
A question came up here regarding whether or not Credits could be involved with weighting - or at least in pulling lists of patrons who have attended performances which feature a particular artist associated with any performance. Any thoughts?
You can write your weighting procedure to do whatever you want it to do, but the tricky part would be linking credits to interests. Normally an interest is also a keyword, so you set it up once, add the keyword to performances, and then you have an easy link between performances and interests. To use credits, you will have to set up the credits up twice, once as credits and once as interests. To link the credits to the interests you would have to either add the interest keywords to the performances, or handle the matching in the weighting code. Handling the matching in the code might be a bit cumbersome, though. I think you would have to get much more specific, saying credit a corresponds to keyword a. While if you are using keywords, you could be more general and say find the keywords on the performances a constituent bought and increment the weight on those interests. You don’t have to be specific because the keywords and interests are the same thing.
To sum up, there is extra work involved for someone. Either extra performance setup to apply the credit keywords to the performances or extra coding work to map the keywords to interests. The extra setup work is probably simpler and more dynamic (i.e. you won’t need new coding whenever you add new artists), so that’s what I’d go with.
Hope that makes sense and helps.
+1 888 643 5778 x 329
Thanks that is helpful. We now realize however that the entire list of Interests appears in patrons' accounts whether or not they are selected or weighted. Given that there are 100s of artists, conductors and composers associated with performances across our seasons, that would be an unwieldy number of Interests to weed through for patrons or frontline employees. I suppose we would need to go with more general Interests to preclude this - or figure out a way to only display selected Interests that are weighted.
For the web, you could filter the interests displayed to constituents based on keyword category. And when you are displaying to them the interests they have already selected, the Web API will only return those they have selected, not all possible interests.
For your employees, you can’t filter the list of interests, but you can sort it. So if you use keyword category, you could sort by that column to make it a little easier to find certain groupings of interests. For example, maybe you could group artists by season (updating the category to the more current season for those artists who return from year to year) You could also use control groups to hide some interests, but the only way to unhide them would be to have an administrator remove or change the control group.
If you wanted to do this for weighting only, not self-selection, control groups might actually be the way to go. That way you could still have other self-select interests listed for your frontline staff but hide from them the artist interests that are populated automatically based on purchases.