Managing subscribers who are families

[vultan]

Hi there -

I'm looking to use phpList to manage members and mailing campaigns for a community group. People register for our group as families. We have subscriber attributes that are common for an entire family, such as home address, number of kids, etc., but each adult member of the family also has their own email addresses.

I'm not sure how to set this up. I could treat each member of a family as a phpList subscriber, but then I'm duplicating for each member all of the shared attribute data. I could treat each family as a single phpList subscriber, but then I'd only have one email associated with the family, and I want each family member to be able to receive campaign emails. Is there a proper or at least effective way to design a phpList installation to do this?

Thanks!

[Cornwell]

I'm wondering if having all the family-related information in a separate database would work, and linking to this via the foreign key field? But I have not used foreign key myself and I don't know if it has to be unique.

[vultan]

I'm wondering if having all the family-related information in a separate database would work, and linking to this via the foreign key field?

Thanks, Cornwell -- that may be the way to go. Any recommendations for separate online databases with easy-to-use interfaces that work cleanly with phpList?

[Cornwell]

phpList uses a database, probably mySQL. Does your hosting service provide phpMyAdmin as a database tool? If so one way would be to put your family information into a spreadsheet, save it as csv and then import that into the phpList database as an extra table called something like families.

If your membership list does not have too many comings and goings then you could also use phpMyAdmin to add and delete records - there's no need to upload a fresh version of the table each time. If there's a higher turnover then you'd probably have to look to having an online membership form.

Regards, Roger

[vultan]

Thanks, Roger -- that's helpful.

[Shoe123]

I could treat each family as a single phpList subscriber, but then I'd only have one email associated with the family, and I want each family member to be able to receive campaign emails. Is there a proper or at least effective way to design a phpList installation to do this?




Get

[Dragonrider]

I could treat each family as a single phpList subscriber, but then I'd only have one email associated with the family, and I want each family member to be able to receive campaign emails. Is there a proper or at least effective way to design a phpList installation to do this?

So long as each individual has a unique email address, phplist will send the message to each person on a list. If a family have a single shared email address, only one message will be sent to that family group. Does that help?

[vultan]

So long as each individual has a unique email address, phplist will send the message to each person on a list. If a family have a single shared email address, only one message will be sent to that family group. Does that help?

That would help with the email addresses, but it wouldn't help with the redundant family information. See my initial posting:

We have subscriber attributes that are common for an entire family, such as home address, number of kids, etc., but each adult member of the family also has their own email addresses.... I could treat each member of a family as a phpList subscriber, but then I'm duplicating for each member all of the shared attribute data. I could treat each family as a single phpList subscriber, but then I'd only have one email associated with the family, and I want each family member to be able to receive campaign emails.

If a family has a shared email address, then yes, it would do the trick; but not all families do.

[Cornwell]

I'm wondering if having all the family-related information in a separate database would work, and linking to this via the foreign key field? But I have not used foreign key myself and I don't know if it has to be unique.

Did you investigate this approach any further?
Roger

[vultan]

I'm wondering if having all the family-related information in a separate database would work, and linking to this via the foreign key field? But I have not used foreign key myself and I don't know if it has to be unique.

Did you investigate this approach any further?
Roger

Hi Roger: I didn't. It was above the threshold of "a bunch of work to set up as a prototype, and we're also exploring other options." I might get back to it at some point.

[Cornwell]

Fair enough: I too have a pile of ideas that are bubbling under but not of sufficient urgency to lead me to find the time to implement them.

[bizshop]

Other than the redundancy, unless you have a huge number of subscribers the load of having the duplicate fields will likely not be large.

That being said, I'd make a single attribute for each email address called 'family' where you would put their family name uniquely (maybe need smith1 and smith2 for example)

Then a separate Mysql table with one of the fields being that unique family identifier for the family particulars (address,kids,etc) since these are not used by the phpmail program. This may be what the foreign key does, but I've not explored that.

[vultan]

Other than the redundancy, unless you have a huge number of subscribers the load of having the duplicate fields will likely not be large.

That being said, I'd make a single attribute for each email address called 'family' where you would put their family name uniquely (maybe need smith1 and smith2 for example)

Then a separate Mysql table with one of the fields being that unique family identifier for the family particulars (address,kids,etc) since these are not used by the phpmail program. This may be what the foreign key does, but I've not explored that.

Thanks, Bizshop. Yeah, I'm not worried about the space or time issues in the redundancy, but rather the fact that they'll grow inconsistent over time. A separate database would likely work. Though, of course, I was looking for an easy solution. I can handle it, but the non-profit I'm helping to support consists of folks who aren't very technically literate. Of course, I could build something to hide the separate database, etc, but I was hoping to spend less time than that...

[jsrds]

Did you try to find this idea any further?