Extraction Criteria: Customer Interests and Ticket History

Hello!

As we approach our 2023 season, we are trying to market to our constituents based on their interests. We'd like to send them information on different shows that we believe they would be interested in based on their past ticket history, but if they've already purchased tickets for that show, we'd like them to fall into their next highest interest and get information on another show that they would also likely be interested in. 

The problem we're running into is we can't look at both interests and ticket history for upcoming shows in the same extraction. The interest weight lives in one place (though it does calculate interest weight based on ticket history perf no's) and the ticket history is in another, so using the two criteria in a single extraction segment doesn't seem to yield the right results.

Is there a way to get ticket history pulled in so that we can evaluate both interest AND current season ticket history in one segment? We don't want to suppress buyers of upcoming shows, because then they wouldn't be able to be caught in another interest segment. Is there another way to accomplish this?

Thanks,

Michael Dorsey

  • Hey Michael,

    So you are getting a customer segments using Extration and you want to pull Ticket History and weighted interest through you Output set? 

    I usually start with what list criterion do I need to get my list, through either Lists (or Extractions if it particularly complex).  And then when I have the right people then plan out the data pull through Output Set elements.  With the Output Set it souds like you'll have a single Max interest but mulltiple rows of performances/productions from Ticket History that you'll probably have to filter by something like Season (2023).  There's a bit more info here

    Now if you want all the 2023 performances in a single Output Set row, like a comma delimited string (or built into a HTML table in the case of outputing to word fly), you'll need to make a local View, which a few of us I know have done before.

    Best


    PS: the weighted interest sounded great BTW

  • Hi Heath,

    Thanks for your response! Actually, what we want to do is use the weighted interest and ticket history as criteria in the same segment of an extraction, to qualify constituents. The idea is something like this:

    Segment 001

    • Interest = Opera
    • Weight >= 15
    • Ticket History NOT IN Vanessa (this year's opera performance)

    Segment 002

    • Interest = Dance
    • Weight >= 15
    • Ticket History NOT IN Scottish Ballet

    If a person has an interest in opera that weighs 15 or greater, then we want to market Vanessa to them, unless they've already bought tickets to Vanessa. If they have, then we want them to be evaluated for segment 002, and so on until they fall into a segment. We'd have a catch all with some editorial content if someone happens to have tickets for everything. If we suppress ticket history separately, they won't get any email whatsoever.

    I can see where we could use output elements like you suggest to figure out who has purchased tickets for the upcoming festival; however, we're hoping to make this more automated, using the segment ID's in conditional statements in WordFly to populate the appropriate content for each recipient. Any ideas on how I could put their interest weight and their entire ticket history into one view to use as list/extraction? I've got a local view for weight, but it doesn't play nice with criteria that uses T_TICKET_HISTORY.

    Now, all that said, I have been caught up with trying to make this work in exactly this way, and did not consider that output elements might be another way to get to the constituents we want. It sounds like it would make the process a bit more manual, but it would do the trick. Thank you for the suggestion!

    Michael

  • Oh I see.  Can I interest you in a DOES NOT HAVE?  The should work between unrelated tables.

    I have a whole lot of love for this idea and it starts to get into algorithm territory which I was interested in building for our eDMs during Covid. I might steal some of it for my playtime. I was talking to Tom about this a few years ago as you could put machine learning at the back of this to wicked effect.

  • WOW, it was really that simple? I'm ashamed to admit it, but I use "Does Not Have" so infrequently that I didn't even think to give it a try. The answer was right in front of me the whole time. I can't thank you enough for pointing this out, Heath -- this is a big help!

    You and Tom are in a different league. Right now, we're trying to establish a basic system for this season, and revisit it after the festival (and an upgrade to v16) to fine tune the process. Feel free to steal whatever you'd like! I'm happy to share other parts of our rudimentary system as well, if you're curious.

    Thanks again!

    Michael

  • Tom's definitely in a different league.  I have dreams.

    The only reason that I'm all over IN / HAS etc is that I ran a Lists Training course across the company about a week ago and I have an Output Set one coming up 

  • BTW, re: weighted interest, I can't take all the credit for this piece. I recycled some of the logic that our pre-built customer interest procedure uses (that I believe Tessitura made for us) to create interest (we're calling it "Affinity") weight, then changed the T_KEYWORD infrastructure that it's based on (different "affinities"), and made the procedure so it only looks at the past X number of seasons, as interests can change over the years.