Does your org ask for email addresses from walk-up ticket purchasers at the front gate or box office?
Do you ask "how did you hear about us?" or "what prompted your visit today?" (or similar) and use source codes to track general marketing efforts? (not asking about direct marketing efforts with discounts or promo codes, but rather general brand advertising or press for guests buying at full price?)
If your org does either of these--or have tried in the past, but didn't find it successful--we'd love to hear your advice! Tips for collecting useful data without annoying the customer too much or slowing down the transaction time too much.
thanks!
Tiffany Zarem
Marketing Director
California Academy of Sciences
At TLCC2018, Erica Simonitis from the Met Museum presented on using collective constituent records to track geographical data as part of the General Public, But Not Anonymous session. She said they created 100k constituent records, one for each US zip code and one for each country. A record is attached to each general admission transaction. It looks like Erica is no longer with the Met. I'm curious to hear if anyone else has gone this route.
-Annie
Annie Petroff (Past Member) Liberty Science Center has been using the one Account per ZipCode route for many years.
Oh, great! We’re looking at the pros and cons of zip code collection via survey vs. collective constituent records.
I have some questions for you, if you have a moment:
Thanks in advance!
Annie
This is an interesting idea. What does this method get you that the survey functionality doesn't? General public pricing rules based on geography come to mind, but what am I not thinking of?
Pricing rules and interceptors are two benefits of using consituent records, and we use both. We also find it beneficial to have all of the location data in one place. So we don't have to look at constituent data for our known customers, like members and web purchasers, and survey data for our anonymous constituents.
Annemarie Ryan thanks for responding here.
From my point of view, the last item is most important, these Zip Code accounts just work in most of the standard ways as any other account in T-Stats, in Lists, Reports that user Lists... That would not work very well without customizations using the Survey Method, which hides this information off in a less universally accessible location of an order specific survey result.
Another question for or Annemarie Ryan
Do you know where you got the zip code and country lists? Did they require much clean up or ongoing updates?
Tech Services did the implementation for us, but I found the notes in our JIRA ticket and they used the following website for US zip codes: https://www.unitedstateszipcodes.org/zip-code-database/
We also added a utility to insert any new/missing zip codes into TR_CITYSTATE. We reserved all accounts in the 4400000 range so if a new zip code is added we just have to update TR_CITYSTATE and format the constituent record. So far, we've done very little updating.
I know that we created a country account for every ISO country but not sure where we got our source list.
Just a little bit more information about the accounts themselves. At the Science Center we were working with a brand new database so the zip code actually matches the postal code. So if a user types 07087 into the account field they are pulled to that zip code record. At The Met we couldn't do that, so we jumped ahead to account 4400000, and our users just add 44 to the front of any zip code. (So for the last example they would type in 4407087) This eliminates the need to search for accounts, they are just typing the number into the field and hitting enter.