List Manager Isn't Pulling Enough Data. Is my Criteria Wrong?

Nothing looks immediately problematic.  I don't think you're checking attendance (scanning) mind, just purchasing.  Could you post what the code looks like when you select "Show Query"?

As far as "attending vs purchasing" if the group never came, it probably means they never purchased either. A lot of our group check-ins are pay on arrival and we won't print the tickets until it is paid for. So no check-in means no purchase. Could that be what is skewing my numbers? 

Thanks for that.  I find the Ticketing criteria set to be highly problematic, so I like to see what it's actually doing behind the scenes.  In this case, though, it seems to be doing what you would expect.

My next thought would be to review your Ticket History, as this is actually a defined subset of your actual ticketing transactions, and so may not include some transactions.  However, Ticket History also powers Season Overview, so I don't think that's it.

My next suspicion falls with the dates and the Mode of Sale.  Season Overview doesn't show you sales broken down by arbitrary date ranges, you are always looking at Seasons/Fiscal Years/Batch Periods within the Fiscal Year, so perhaps the computation for comparing the two might be off?  Also, it doesn't report on Mode of Sale: perhaps some of these groups were sold their tours in a different Mode of Sale?

Since we're talking about such small numbers, perhaps digging through these different options in Analytics might be a good way to figure out what is going on?

The Ticketing criteria set IS highly problematic.  But that is because the ticket history table is either far too expansive or far too incomplete.  The thing with ticket data is that you are either looking for something simple that seems to be complicated by the amount of data that table contains, or else you are looking to do something that involves this plus that plus this other thing which still seems fairly logical but is somehow cut off across different data points, some of which are on that table and some which are not and thus produces confusing results.

At least, that has been my experience.

Correction: Season Overview isn't looking at Ticket History, as I dig through the load procedure.

The big issue to me is that different criteria in the set are looking at different views.  This means that when you ask for something in one criteria, it may not be "working with" another criteria.  So if you say

• Attendance Admission Total > greater than or equal to 3
• Ticket History Performance is PERFCODEX

You won't get customers who had 3 or more scans to PERFCODEX, you'll get customers who have, lifetime, scanned attendance somewhere 3 or more times who also purchased a ticket to PERFCODEX.

You can't even trust the criteria name preamble (i.e. Ticket History), although that may have been fixed a bit in v16.

Correct.  That is what annoys me as well.

I think it was way back when I first learned about list criteria (IN vs HAS, and all that jazz), that someone must have given me the extra tip - the Search Household checkboxes on list criteria can basically double as a visual way to confirm 'are all my criteria referencing the same dataset behind the scenes'? The checkboxes for criteria all pointing to the same view will select or deselect themselves in sync, or not if things are disconnected like the Attendance vs Ticket History trickiness. Just an extra tip to help people wrap their heads around the concept, without necessarily needing to parse a SQL query.

So basically there is no way in List Manager to get what I am looking for in a very specific way? And I love how the ticketing criteria are so problematic, since that is where we live as a museum! Everything we do is ticket based hahaha 

If I do this in Analytics as you suggested, can I still get a list of emails? I'm assuming yes since I can get zip codes and addresses, but just wanted to double check to be sure.

So basically there is no way in List Manager to get what I am looking for in a very specific way? And I love how the ticketing criteria are so problematic, since that is where we live as a museum! Everything we do is ticket based hahaha 

If I do this in Analytics as you suggested, can I still get a list of emails? I'm assuming yes since I can get zip codes and addresses, but just wanted to double check to be sure.

One thing to try if you haven't already, would be dropping email address from the list criteria, and just addressing that in the output set instead. If that changes your list count, or you see emails you don't expect appearing or missing from the output, that could provide some clues. I don't know your setup, but wondering if there's any chance the ticket history of a group and the email address you want are living on separate but related accounts (such as the group owning the ticket order, and the person with the email address set up as the order initiator). Good luck!

There ARE ways to do just about everything in List Manager.  I am fully SQL fluent, so I just manually do things that way, but I know that is unrealistic for most staff.

I have been doing some List Manager training with staff internally, and one of the very first things I learned in teaching it to others is that it is important to A) understand HOW table rows work with relation to the criteria and the IN/HAS fun, and B) that it is VERY often necessary to use multiple lists, e.g. this list of these attributes plus this other list with these other attributes but not this third list.  Is that a bit cumbersome?  Yes.  But if you can create lists that are modular and/or dynamic enough for your semi-regular needs, it can still be highly effective.

I should say that our grousing about Ticketing isn't actually a problem for your particular list setup, the query shows that everything is looking at the same view (vs_ticket_history).

I'd try Evan's suggestion first, then maybe turning off MOS, in case that returns a list small enough for you to parse through the results looking for the accounts you are expecting.

Are these tour group accounts identifiable in any other way?  Maybe we could start with them?  How did you identify the 20 customers in Season Overview?

I am also wondering if perhaps it were 20 tickets in Season Overview, held by the 6 constituents in the list? I agree that Evan's suggestion is a great place to start.

I was able to find them by how our EDU department labels performances. She is super good about labeling them as "Riverglen Senior Living Group Tour" or "UConn Group Tour" so I could quickly skim our Season Manager calendar and see a bunch of tours labeled "Senior" or "Retirement" which is what I was looking for. 

So I knew the orders for them existed, my thing was that I don't remember if half of these orders ever got processed. We book tours months in advance (meaning we build the performance and attach an order to it weeks to months out), but like I said earlier, they don't pay or get tickets printed until day of. So some of them might have never shown up (meaning no money or tickets) and I just don't remember because it was last year. 

I ended up trying it in Analytics instead and got a little bit better of a result, but now half of them are missing emails which I know isn't right because the constituent record has to have an email for us to send their tour confirmation to. But I may just pull the order numbers or customer numbers for those ones to be able to find the email if necessary. 

Not sure if this applies to you but the way we do group orders the Owner is the Organization in question and the Initiator is the group Individual contact where the email address for that person lives. Most of our Organizations don't have emails attached and we get that information by looking for the Owner and the Initiator of the orders.