@jasonsamuels This is a great question and one I love to deal with but typically I'm dealing with much more scale (saving 30 tasks by adding 3 or 4 steps) So all my "tricks" wouldn't really help you.

However if I'm reading the statement on that help page correctly you could add a simple filter and exclude everything else.

The ID of the additional attendees will have an increment like 456123-1

So 456123 is a valid ID and 456123-1 or 456123-2 or 456123-n are values you want to exclude.

If that's true you can filter on the ID and if it contains a "-" (dash) do not continue.

@PaulKortman that's a brilliant suggestion, but unfortunately didn't pan out. None of the IDs sent in the Eventbrite output contain a dash, but instead includes a seemingly sequential ID for each of the duplicate attendees. I suspect that reference in the documentation is just out of date.

@jasonsamuels Is there no pattern in that ID that you can match or figure out? if there is any sort of pattern we could develop a step (spreadsheet-like formula for example) that would sus out if there are "duplicates"... here's some possible patterns I'm thinking of:

• 6 digits for single ticket purchases, 9 digits for the multiple ticket purchases
• A space (or other character) separating the main ticket ID from the "duplicate" ids

I just re-looked at your screenshot and realized that there's a barcode and an ID, and the ID is in the barcode plus the duplicate ID (like 001) --

So what does the ID and Barcodes: Barcode look like for a single ticket purchase and a multi ticket purchase?

Also does the ID change for each ticket or just for each purchase? (meaning if the ID changes for each ticket the ticket barcodes for a multi-ticket puchase would end in 001 002 003 etc, but would not share other numbers in common.)

@jasonsamuels This is a tricky one. Is there any other information in the "Data Out" tab that might be able to be filtered on? Anything that separates the original attendee's ticket from the additional?

If not, your best best here is going to be to reach out to the folks at Eventbrite to see if they are willing to make a change in regards to how those additional attendee IDs are structured in their API.

@PaulKortman Duplicates can be easily sussed out via the order_id field. When somebody purchases ten tickets, they come through as ten attendees each with a unique attendee id value but all with the same order_id value.

As best I can tell, the barcode field is the same length string in all cases, a 23 digit number consisting of the concatenated 10 digit order_id, 10 digit attendee id, and then always ending in "001." I've looked at both single ticket and multi-ticket purchases, and it's the same in both cases.

@jesse As far as I can tell there's no marker in the data which can identify the original attendee from the duplicates being sent through. The suggestion above about filtering out based on a dash in the id value would likely have worked, except that's no longer how Eventbrite structures that data (my suspicion that the documentation is out-of-date was subsequently confirmed by Zapier support). As for reaching out to Eventbrite to ask them to make an API change, I don't even know where I'd start with that and honestly am reluctant to hope that they would be responsive to such a request.

So I did put some time into re-working the Zap yesterday, moving the data into a Google Sheet first in order to deduplicate it, and then from the Google Sheet to Eventbrite. The way it's setup now is that one zap has a new attendee in Eventbrite as the trigger, a filter to only continue if the opt in value = Yes, then Find or Create Row in Google Sheets. That last step looks for the email address and order ID in the Sheet, and creates a new row if not found. The net effect is that a row is only created if it wasn't in there previously. Then a second Zap listens for a new row in that spreadsheet, which then transmits the data to Pardot.

The net effect of re-working it is that rather than one Zap consuming 30 tasks on a ten ticket order, we now have two Zaps consuming 22 tasks on a ten ticket order. So we're using as much as 27% fewer tasks, which is progress, but not as much as I hoped. And on the flip side, it also means that single ticket orders now consume 4 tasks rather than 3, and that's going to become problematic as we get closer to our event. (Context: my org runs one of the largest juried craft shows in the country every February in Baltimore, and artists who participate in the show get ten comp tickets to hand out to their friends and patrons. So we start to see those multi-ticket comp orders come in as soon as ticket sales open in December. But as the show date approaches, the volume of orders will shift dramatically towards attendees who primarily purchase one or two tickets per order.)

So I'm still scratching my head for a solution. I tried using Zapier Paths rather than a Filter to try and stop the Zap in it's tracks when the lookup in Google Sheets came up empty, but when I tested that step it told me the Zap would stop because there was data in the lookup step (even though not found in the Sheet). I wondered if that was a quirk in the testing interface that might not hold if it were provisioned and tested in a live environment, but didn't proceed to that testing. Aside that am still thinking this through, and certainly open to suggestions if anyone has an idea.

Hi @jasonsamuels

It sounds like you're on the right path and I'm glad that you were able to reduce the steps a little.

I tried using Zapier Paths rather than a Filter to try and stop the Zap in it's tracks when the lookup in Google Sheets came up empty, but when I tested that step it told me the Zap would stop because there was data in the lookup step (even though not found in the Sheet). 

If you have a find or create step then the Zap will always return data from that step - either the data that was found or the data that was created. BUT there is a field that might help you here. If you look at the input of a Google Sheets find or create row step, you'll see there's one called 'Zap data was found' - the field has 'true' in it if the row was found and 'false' if it was created. Would that help you to add a filter here?

@Danvers thanks for that tip! So I re-worked it again based on that suggestion and.. good news, bad news.

I now have a six step Zap running which triggers from a New Attendee in Eventbrite, uses a Filter to stop the Zap if email opt-in does not = Yes, Looks up or Creates a row in Sheets, uses another Filter to stop the Zap if the Sheets lookup found an existing row, then Looks up or Creates a Prospect in Pardot, then adds that prospect to the welcome and subscribe list (kicking off an Engagement Studio workflow in that system).

The good news is that your suggestion worked, I was successfully able to halt the Zap by filtering on whether the Sheets lookup step found an existing row. Because of that I was able to kill the second Zap which picked data up from the new row in Sheets, consolidating the process into one Zap which is a bit more efficient.

The bad news is that I'm not realizing any reduction in task usage, because the initial filter and Sheets lookup steps still count against our task usage before the second filter stops the Zap. So the unsuccessful runs where it stops on a duplicate still count as 2 tasks, while successful runs are now counting for one additional - 5 now instead of 4 because the filter steps counts as one. In sum, a ten ticket order now has one Zap consuming 23 tasks as opposed to two Zaps consuming 22 tasks.

If there were only some way to have a Filter stop duplicates in their tracks as the first step.... I haven't yet tried Zapier Storage, but wonder if I can set up a step that writes just the order_id to that and then a Filter step at the beginning which stops the Zap if the order_id exists there already. Might try that next.

I did wonder whether a storage step would reduce tasks but I think that it will use the same amount of tasks as Google Sheets.

I feel as though the only way to significantly cut down on tasks would be if there was a way of spotting if a ticket was from a multiple ticket order based on the id. You could then stop the Zap immediately after the trigger.

Alternatively, have you looked at the New Order trigger, would that give you the information that you need?

@Danvers I have looked at the New Order trigger, and that won't work. It omits a significant amount of attendee info, including the custom question of whether to opt in to our email list which this workflow requires. And I've poured over the data from the New Attendee trigger repeatedly and far as I can tell there's no marker which separates duplicates from the original.

I appreciate your time and input on this though, all of you. It's a tough one.

I agree that storage would essentially use the same amount of steps as a spreadsheet lookup.

@jasonsamuels would you be open to triggering off of the new order and then using a webhook to query the order for the full information from Eventbrite?

From my reading of the eventbrite documentation you can hit the order by order ID here: GET https://www.eventbriteapi.com/v3/orders/{{order_id}}/ I found this at https://www.eventbrite.com/platform/api#/reference/order/retrieve-an-order and the authentication is a simple header Authorization: Bearer {api key} so you could do it with one webhook step -- this would be true for all orders single or multi-ticket...

I think this might be the "ticket" -- pun intended.

@PaulKortman thanks again for the creative solution! Am giving this a shot now, encountering some difficulty getting it to authenticate - keep running into a 401 not authorized response, but will keep at it for a bit. Am a little beyond my technical depth at this stage, but I enjoy a challenge.

You should be able to find your API Key here: https://www.eventbrite.com/platform/api-keys and then use that in the following Webhook setup

@PaulKortman Thanks again! I was close, had it input into the interface like so:

Now that I got it to authenticate though, realized a critical flaw in the plan .. that API call returns order level data, not attendee level data. In other words it's the exact same data as gets returned by the New Order trigger. ‍♂️

It made me think though, but wait .. maybe I can use this webhook to make an API call on the attendees associated with the order, at which point I'll try to just utilize the data for the first attendee. So I dug into Eventbrite's API documentation for the Attendee Object (https://www.eventbrite.com/platform/api#/reference/attendee) and .. it can't be done. The API only supports retrieving an Attendee by Attendee ID (which is not included in the API output from a New Order).

I was just about ready to give up when I looked at one more thing and spotted something key. The API reference for Retrieving an Order (https://www.eventbrite.com/platform/api#/reference/order/retrieve-an-order) indicates the availability of a bit more data than I'm seeing come back in Zapier. Most importantly, it can include an array of attendees that belong to the order along with their answers to custom questions. It seems like the reason why that data isn't available in Zapier right from the trigger is because the reference indicates that this requires the attendees expansion.

So it turned out @PaulKortman was right .. this is the ticket! I created a Zap that triggers off a new order, then turns that around to a webhook to query the exact same data but with this query parameter added:

And voila, SUCCESS! The output returned from the webhook now includes attendee data for the order as an array. From that I added a step to Filter the Zap based on whether the array for the custom question response includes "Yes", then proceed to looking up or creating a prospect in Pardot based on the email address, first name, and last name from the Order.

I should note that while this workaround is effective for this particular use case, it has some serious limitations. Most notably, because the attendee data is returned as an array it renders as strings of duplicated data separated by commas, like so:

Because of that situation, data from the attendee level isn't very usable. I attempted including the attendee last name in the subsequent step as a test and ended up with a Pardot prospect named Jason Samuels, Samuels, Samuels, Samuels, Samuels, Samuels, Samuels, Samuels, Samuels, Samuels. However, because all I need to do for this use case is read and filter on the custom question "Sign up for our free email newsletter" it's okay. The filter step works as expected, and the customer name and email are available at the Order level to pick up and pass along.

I now have this down to one Zap consuming 4 tasks every time it runs successfully, regardless of whether the order is for one ticket or ten, and with a caveat that every customer who does not want to join our email list now costs 1 task instead of zero because the Filter step runs after the Webhook that re-pulls the Order data.

This one was a journey, and thank you again to everyone who chimed in here to help. Perhaps a feature request could be made to Zapier to provision a new Eventbrite trigger that deduplicates attendees from an Event Order. From a technical standpoint, it would be a matter of including that expansion as a query parameter in the API call and then dropping all data after the first comma within each object in the attendees array.

Great work @jasonsamuels I had caught that the API for the order did contain more information, but I totally missed that you needed to add the query string parameter. Good work finding that and finishing the zap from there!

Glad you were able to lower the task usage!

For what it's worth, I just noticed this other community forum post by @Danvers about using Using Extract Pattern and that could theoretically be used in conjunction with this to extract and utilize data from attendee arrays.

https://community.zapier.com/discussion/355/using-extract-pattern-to-get-phone-numbers-emails-and-other-types-of-text-from-a-field