Email Signups at Events/Conferences/Trade Shows

Options
Hi Everyone,


I don't think I am searching well enough to find an answer in the community because I have a feeling others might be wondering about this as well. We're trying to figure out the most efficient and user-friendly way to collect email addresses at events. We've tried with LO surveys in the past, but users tend to get frustrated with them and often they won't allow multiple entries for some reason even if you have the setting turned off. We've resorted to offline means of collecting emails, but we want people to immediately get into the system to start receiving welcome messages from us and in our other email cycles.


Wondering what others have done?


Thanks for any advice or insights on your successes!


-Shawn
Tagged:

Comments

  • To use a survey for this, I would not use the constituent creation fields. Just use regular short text fields to avoid all the existing constituent and email in use issues. Then later on you can pull a survey report, and use it for a constituent import. The import will kick out the problems that an actual email sign-up form would complain about. You could probably have them in the system by the next day.


    If you stick with offline, then you'll still be doing the constituent import. Are you going right into Excel or something?


    In both cases I would be asking for First Name, Last Name, Email Address, and Zip Code at the least. (You can get city, state and country from a zip code, so you'll have a pretty good record.) Adding Street Address would give you a complete address, which is great, but you may not think the extra field is worth it. Zip code will really help with duplicate resolution though.


    If it were me, I would probably do an API form for the survey so I could add some bells and whistles. For instance we use a JS script that checks for email misspellings on our donation form. Are you carrying around a tablet? Then you could make the email field an actual html5 type=email field. That changes the keyboard on most mobile devices to the one that shows the @ symbol.

  • Brian Mucha:

    To use a survey for this, I would not use the constituent creation fields. Just use regular short text fields to avoid all the existing constituent and email in use issues. Then later on you can pull a survey report, and use it for a constituent import. The import will kick out the problems that an actual email sign-up form would complain about. You could probably have them in the system by the next day.


    If you stick with offline, then you'll still be doing the constituent import. Are you going right into Excel or something?


    In both cases I would be asking for First Name, Last Name, Email Address, and Zip Code at the least. (You can get city, state and country from a zip code, so you'll have a pretty good record.) Adding Street Address would give you a complete address, which is great, but you may not think the extra field is worth it. Zip code will really help with duplicate resolution though.


    If it were me, I would probably do an API form for the survey so I could add some bells and whistles. For instance we use a JS script that checks for email misspellings on our donation form. Are you carrying around a tablet? Then you could make the email field an actual html5 type=email field. That changes the keyboard on most mobile devices to the one that shows the @ symbol.

    Dear Brian,


    These are awesome suggestions. We are indeed carrying tablets around. Not sure I am following your suggestion on the API form. Any articles you can suggest on that?


    Cheers!

    Shawn
  • I'm just talking about making it more mobile friendly than an out of the box survey. The API allows you to completely create your own html form and submit it to Luminate, so you aren't stuck with the form that Luminate generates. You could add missing features like sections that reveal depending on previous answers.


    I don't have a survey handy, but consider our donation form: http://luriechildrens.org/donate


    We added a bunch of little things, to make it more mobile friendly:
    • Responsive design
    • browser-side field validation using LiveValidation, so the user shouldn't get error messages after clicking submit
    • I made the email field as <input type="email" /> rather than <input type="text" /> and my Other Amount field is <input type="number" /> - see what happens to your keyboard on mobile in those fields.
    • Added the mailCheck plugin. Try to misspell an email address as name@gmail.con - not foolproof but it helps
    • Added geoCoding to the zip code field. so the city-state-zip autocomplete
    You get the idea, nothing too magical. You might not need many of these, but if you have the resources to build HTML and JS it is nicer.


    There's a lot you can do without a full on API form for your survey. You can use CSS to make the fields nicely large and stuff like that.


    You can probably add field validation using Live Validation or some other plugin. There are tons out there to choose from. You might be able to add a few other features, especially if you have access to the PageWrapper.


    If you don't edit your PageWrappers, one trick it to use survey captions to add Javascript or CSS to your stock surrvey.

Categories