CiviCRM Community Forums (archive)

Working on a particular project currently where the client is - quite sensibly - using smart groups to manage the segmentation of contacts in the database. This used both in order to gather useful marketing data about the nature of the audience, and for mailings.

However, when sending bulk mailings, it is imperative to enable the user to unsubscribe remotely. The nature of the unsubscribe process - as I understand it - is that the contact is removed from the group. And if a particular mailing was sent to multiple groups, and an unsubscribing contact was a member of more than one of those groups, they would effectively be removing themselves from all of those groups. I've seen instances where a contact has unsubscribed themselves, possibly simply because they were uninterested in the content of a particular message, unknowingly removing themselves from half a dozen groups, which actually probably was not their intention.

Clearly this then makes a mess of the segmentation role of our groups. So we've got round it by having duplicate groups, i.e. create two smart groups based on identical search criteria, enabling one of them as a mailing list. So even though mailing recipients can remove themselves from the mailing list version of the group, they remain in the segmentation list.

This approach feels like a kludge, so I'm keen to learn if I've missed something fundamental about how groups work, and if there is a more elegant solution to this issue.

A second, usability issue arises out this approach: we end up with lots of groups. The 'Manage Groups' listing is simply that, a list. I was thinking it would be useful if we could categorise groups and show them visually in these categories. We already have the concept of parent groups, which as I understand it is used for mailings. Could it also be used to help manage the display and presentation of groups through the 'Manage Groups' screen?

Hi
The idea of an 'unsubscribed' status for a group sounds a great way to tackle this problem. Indeed there could be scope for a number of user configurable statuses, as there are already are for memberships and event participants.

I doubt that this client would be interested in sponsoring such a development, but I'll mention it to them anyway. I would be willing to chip in to an MIH on this, as I think it would add significantly to the capability of CiviCRM and specifically CiviMail, and make the whole use of Groups clearer.