Email slurping

[jhogendorn]

We gather emails from a wide number of sources:

• meetup.com
• eventbrite signups
• members
• mailing lists
• newsletter subscribers
• various online forms, such as donations etc.

It would be very handy to have MM be the thing that centrally captures all these emails so that we can export a managed list for email marketting. This would also allow us to track conversion, ie people who come in for a tour or event. Another thing it would enable us to do is provide a 'newsletter only', or community access (ie forums,discord) membership level ($5/m sort of thing).

[jabelone]

Sounds like a great idea to finally get our mailing list(s) under control. I'm not entirely sure what needs to be implemented though so just want to confirm what you'd like to see.

Are you thinking MM should use the API for each of those services to pull in a list of all email addresses? That way we could have a single export mailing list feature (or send it directly to mailchimp).

Or are you thinking of something else?

[jhogendorn]

Api usage would be obviously the best practice, but maybe a long term goal? I think eventbrite will be easy enough, and meetup we will probably retire soon. The mailing list stuff is old/static. The online forms I think are managed with jotform so theres probably an api there.

A very short term approach might be csv import and support for a member type that is kind of, email data only? And perhaps some way to put a text field on the website to capture peoples emails that can be put through that same funnel. (things like mailchimp do this for you, but i'm thinking the path of the data goes via the portal)

[jabelone]

Right ok cool that makes sense. So it's just some way of being able to import all of the email addresses we have on various systems into one system (MM). Then MM becomes the source of truth for our mailing list(s).

I think the best way to achieve this while balancing complexity and time, would be to have a manual import process. Essentially you'd be able to import a CSV of names/emails into the system. Then the system can generate an up to date mailing list whenever we need one (or can send it straight to mailchimp on a regular basis).

This means both our member emails, and the emails from all of our other sources will be collected and managed in one place. I'm thinking basically another page with a table (like the member list) that will have a combined list of all emails in the system, with the option to remove specific ones (that aren't members) or to "mute" them - ie remove then from any mailing list export.

Sound good?

[jhogendorn]

Sounds good. Data model wise i would treat them all as another type of 'member', rather than its own table of emails. if you look at other similar member management systems, like tidyclub etc, their data model is to have 'contacts' and contacts can have active memberships etc. Same thing here. atm we have active / inactive / new, when what we probably want is a flow something like contact > new > active / paused / banned / expired / cancelled

In the end, yes, MM should be a source of truth regarding our data, and that data includes the emails of everyone we interact with.

[jabelone]

Yeah I'll be updating the member state system when I implement the automatic payments in #9. Since Stripe will be keeping track and deciding if someone is active or not, I'll do something like separate the access system state (which is linked to Stripe) and add a new property which is member type.