Brokers...am I right??????

Hi Chris - I haven't fully cracked this myself, but here are some musings in case anything here is worth acting upon. I've approached this problem by trying to create a custom SQL query within List Manager, just to keep it agile and easy to edit over time. Ideally this list query is finely targeted to pull in suspect accounts whenever it's refreshed (with a minimum of false positives), so you could run it against something like Single Sale Order Listing to flag the specific bad orders that need to be addressed.

If you can get a solid list built to reliably flag a likely reseller, you could make it dynamic and combine it with a report schedule to deliver on a regular basis to try to catch these with a shorter turnaround time. That could be a ton of report server email traffic, though - one idea we've had is to try to set up an Analytics pulse where notifications are sent whenever this reseller list has more than 0 constituents in it, but skip any notifications if it's empty. The downside there is that it would only ping on a 24 hour cycle based on the Analytics load.

Right now I'm not fully satisfied with my 'suspected reseller' list, but here are the segments it's looking for. Rather than look for accounts that are passing a ticket threshold by performance, it just looks at all orders from the past 24 hours - that may be less helpful, but a bit easier to code for. These are the three queries joined together in our list right now, let me know if getting the actual SQL would be helpful for you:

1) someone booked 7+ tickets and resides outside of our main geographic area in the PNW, or

2) has 3 or more orders created all coming from the same IP address (right now this pulls in some false positives from our employees reserving their staff comps on our office network, so I need to figure out how to exclude our onsite IP address), or,

3) has booked 11+ tickets across any number of orders.

There are probably other segments still to be brainstormed, and these could still use some more work - but hope this might help toward finding a good solution!

Hi Chris, Just curious and want to learn...why are you getting slammed by Chargebacks? Who is initiating these? The broker or patrons who went through the broker? What reason are they giving for the chargeback? 

We have been a few uptiks in chargebacks, but nothing crazy.

Hey Jessica. It's always an account that has either one order with our ticket limit or multiple orders with our ticket limit or multiple order that equal or go over our ticket limit. They are almost always out of state and have email addresses that are clearly not real. Usually some of the tickets get used but we've seen it when none of the tickets get used or when all get used. They then do a chargeback with the credit card. We haven't won yet even providing all the information we do. We will be doing our move over to Merchant Services in the coming months and I'm hoping that will help curb this problem some. I'm also working on an analytics dashboard to try to find these accounts in advance and at least be aware of them, that I think is starting to take shape. Once I have it the way it works for us, I'll be happy to share it here.

Don't have an answer to your question, Chris. Just commenting to commiserate that we also got slammed with chargebacks in the last month or so, matching the pattern you're seeing. It's not just you! 

I created a couple dashboard for analytics that seem to be doing what we want. We have two: one that looks at people who are at our ticket limit (8 tickets) across one or more orders and the other is looking for orders with 9 or more tickets across one or more orders. Remember to change the data source to your local Seats & Tickets cube. Hopefully you all can find them useful. If you want to see different ticket amounts, there is a filter on each widget that controls the total ticket count to see.

PotentialBrokers-8ticketsonly.dashPotentialBrokers-9andabove (1).dash

Thank you for posting! We have an issue with people booking too many tickets (over a 100 sometimes!) on our free days and this will help us weed some of those folks out. 

I've written a sql query just because it was easier for me, but I feel as though some of these criteria could be duplicated in Analytics.

1. Out of state address or out of state area code. (I uploaded a custom table that can associate phone area codes to their US states/cities, so probably can't be duplicated in analytics. You could use Geo Area as Evan suggested, depending on your normal out of state attendance.)
2. Multiple orders to the same production season in a single day or consecutive days.
3. Purchases over $500 worth of tickets.
4. Purchases usually no more than 7 and no less than 2 days out from performance date, enough time to resell but not too far out that the chargeback shows up before the show.
5. Shows with lots of ticket inventory, so multiple performances, almost always Broadway
6. Customer account create date was same day or day before order. (I don't think account create date is in Analytics, but this proved to be a very important criteria in our search)

We calculated these criteria by analyzing what amounted thousands of dollars worth of chargebacks from 2 spring Broadway and another earlier this fall. We diligently ran this query through our run of another Broadway show first weekend of October. The most recent Broadway show was more family oriented, so it might not have been as desirable a target for credit card scammers, but normally we would start receiving chargebacks within a week and a half after the show ends, but we have yet to see a single chargeback after we cancelled nearly a dozen orders for that show.

There is a filter inside the widget of each where you can enter the amount of tickets to display. For museum entry, you may have to play with the dashboard a little for filtering based on how you build the events for entry, etc. Happy data diving. 

I have noticed a lot of the same indicators with broker accounts. in addition to all that you wrote, I've noticed a lot of broker emails end in "@manboto.com", so orders with that email are always red flags. 

May I offer a suggestion for your #2...Place all of your staff into a "Staff" constituency, and then just exclude the constituency from your report.