Author Topic: Mass Mailing from search results confusion (Read 9142 times)

ken · May 18, 2011, 04:49:19 pm

@adharris,

Thanks for submitting the patch!

I tend to agree with your proposal for making the Unsubscribe Group a feature of the normal email process. (I assume the default is that if no group were specified, then the current practice (unsubscribing people from all included groups) is followed.)

Let's say I send a fundraising letter to a number of groups, one of which is the Newsletter group. If the person unsubscribes, they're probably saying "don't send me fundraising letters" rather than "don't send me newsletters".

Creating a group called "Don't send fundraising letters" and using it as the Unsubscribe Group would be a neat way of tracking people who we don't ask for money. I see two possible downsides ...

It fails if people don't use the Unsubscribe Groups consistently (so that we end up sending people similar material from which they think they've unsubscribed)
It is not straight-forward to handle the case where you discover a person should be unsubscribed, but through a means other than an unsubscribe request (eg, during a fundraising call, someone says "please don't ask me for money"). The system makes it easy to add a person to a group of which they are not currently a member, but not intuitively easy to remove them from a group of which they are not currently a member (you either have to add them then remove them, or do a search and use the action "Remove from group")

Ken

adharris · May 19, 2011, 08:02:20 am

The more I think about this the more I come to the conclusion that there are some fundamental issues with how groups/mailings currently work in CiviCRM.

I see two conceptual uses for groups as they exist now: as mailing lists and as "containers" for contacts who share a trait. The problem is that both group types use the same status options to mean different things.

For example, lets say I had a non-mailing group for a committee. Membership in this committee is a bit more constant then subscription to a newsletter; the only reason a contact should be removed from this group is because they are no longer on the committee. In the current system, if I want to send an email to my "committee", I have two options, each with flaws:

Do a search for all members of my committee group, and use the ability to send a search based mass mail to these results. This is cumbersome because it adds an extra step to the email process which seems unintuitive. (I already have a group, why can't i just send them an email?) Also, it will quickly increase the chances of unsubscription groups being used in an inconsistent manner.
Chane my committee group to a mailing list type group. Now i can send an email to them directly via traditional CiviMail. However, if anybody clicks unsubscribe in this email, they are removed from the committee group. Because unsubscription is the same as being removed from a group, this effectively removes them from the committee itself.

It seems to me that there are two tasks when creating a mail: first select who should receive the mail, and second figure out who in that list should be removed because they have been unsubscribed. Right now, CiviMail combines the two tasks into one step: select the groups. I think that this should be abstracted out. I should be able to send an email essentially "Send an email to all contacts in Group A, using unsubscription data from group B"

To me, this would mean altering CiviMail so that all mailings, search based or not, require an unsubscription group. Then, because unsub is processed using a separate group, all groups mailing or not would be available in the include/exclude groups options.

Effectively, "Mailing Groups" become topics about which email is sent. A Contact can say dont send me email about a specific topic, but they cannot affect whatever attribute made them eligible to receive the email in the first place.

Like Ken mentioned, issues will arise if unsubscription groups are not used consistently. I think that this is also true with how CiviMail currently works, so I'm not sure that this is really a step backwards. However, a somewhat solution would be to restrict the creation of new mailing lists to a specific, trusted, user role. That way the normal uses have a discrete number of unsub groups to choose from.

The other problem Ken raises, unsubing a contact manually, is something that should be addressed, but I am not sure the best way to do it.

Obviously the above would result in some pretty major workflow / conceptual changes to civiMail, and should be thought through before implemented. The good news is, however, that after seeing how the current system works, i think these proposed changes would be really straightforward.

xavier · May 19, 2011, 09:46:46 am

Hi,

very interesting points.

I'm wondering if one should be able to un-subscribe from a a group that isn't public. Pretty sure unsubsribing from a mailing received shouldn't be meaning remove me from the committee indeed.

More often than not, when we do mailing there is a mix between public groups (eg. newsletter subscribers and private ones committee X). Right now if one unsubscribe, it will be from all the groups she belongs to and that are a target of the mailing.

I do agree using the same logic as the search result mailing, having a base group for handling the un-subscribes seems the best option. The only difference might be to alert if the base group isn't one of the target groups (and probably automatically use the first selected group as the base group).

Another option could be to display the list of groups the contact is subscribed to and let her choose what to unsubsribe too ?

X+

adharris · May 19, 2011, 01:08:08 pm

I do think there is a use case for unsubscribing from non-public groups. Suppose I created a mailing list "VIP News", with the purpose of sending out updates to people close to my organization. Obviously, each contact should be able to unsub from VIP News, but the nature of the group means that normal visitors should not be able to opt-in to the group. Hence, it would need to be a private group.

I think the demarcation lies in the group option of "Mailing List". If a group is marked as a mailing list, it should be available to be unsubscribed from, regardless if it is a public group or not. Groups that are not marked as mailing lists should not be available to unsubscribe. In order to email one such group, you must however select a base group.

So in the simple case where there is one committee that we are tracking in CiviCRM, there might actually be two groups related to the committee. We would have an "Advisory Committe" group which is not a mailing list. To send an email to the Advisory Committee, we could have a "Advisory Committee Newsletter" mailing list. Then to email the group, you could create new mailing with Base Group = "Advisory Committee Newsletter" and include the "Advisory Committee" Group. Then committee members would be able to unsub from email updates, but would still be be members of the main group.

Perhaps a good rule would be that if you are sending an email to a mailing list group, then that group must be an unsubscribe group. If you are sending an email to a normal group, then you must select a base group which is a mailing list. If this was the rule, then it would be possible to automatically select the appropriate base in most cases. (The other problem here would be that some cases might require multiple base groups. The UI doesn't support this right now, but I'm pretty sure the schema and the rest of the processing code does)

I think the idea of presenting the groups to the contact on unsubscribe is an excellent idea, although i think there are many hurdles before it can be implemented. For example, my understanding is that it's currently hard to to tell if the contact is a member of a smart group.

Donald Lobo · May 19, 2011, 03:59:23 pm

my 2 cents on this across a broad spectrum of areas:

1. This comes up periodically in the forums. It is a minor annoyance to most people but has not been major enough for anyone to address it (as yet). I think this becomes more of an issue for larger groups / as groups use more out of CiviCRM

2. Keeping things simple is important. The current model is quite simple and i'd like to ensure it does not get more complex than that. Most people dont know (and probably dont care) about the differences between a public group and a public mailing group etc. They just want to send out mail

3. Expecting people to create two groups: "Advisory Committee" and "Advisory Committee Newsletter" to send mailings might be a bit too much. There already is a "how do we manage so many groups"

4. We need to be super careful and and be more than complete with regard to unsubscription. A lot better to read "more" into people's intention with regard to unsubscription (i.e. yes unsubscribe them both from fundraising and newsletter groups) rather than read it as, oh they only meant to unsubscribe from newsletter but they still want to listen to our multiple fundraising emails

5. Keeping the "unsubscribe" group in sync with the mailing group seems to be a lot more process dependent than anything else. I'm not sure its a good idea for regular group based mailings

lobo

ken · May 19, 2011, 04:22:03 pm

@Xavier,

I feel we need to allow unsubscribes from non-public groups. We regularly construct groups for targeting mailings, and I'd be loath to make those public. For those sorts of groups it would be much better to identify a more-permanent group from which to unsubscribe so we can respect that for next time.

Ken

ken · May 19, 2011, 04:36:15 pm

Folks,

Another option would be to "add" people to an unsubscribe group when they unsubscribe to a mailing.

Then, when I create my next mailing, I add the unsubscribe group to the list of groups which are excluded from a mailing.

This can be done manually by creating an "unsubscribe from mailing" CiviReport and using that to add people to the unsubscribe group. (Automating it would be better.)

Ken

ecki · July 15, 2011, 04:49:57 pm

OptOut / Unsubscribe / Groups: thats confusing for the Admin as well as for the user. Suggestion:

- do not differentiate between unsubscribe and optout. You add one link, which contains the receivers idendity and the mailing
- this link displays a page describing the options:

- please do not sent me any bulk mail anymore (optout)
- please remove me from the following mailinglists
-- list
-- list

The later might be a kind of filtered view of group memberships, or a specific new object. In case this is too complicated to be implemented a "do not send me mails of type :<mailing title> anymore".

I would also an feedback option.

BTW: the spam prevention on this forum sucks big time. Why do I need it as registered member anyway?

xavier · July 15, 2011, 09:30:50 pm

Is this specifically with mailing from search result?

Quote from: ecki on July 15, 2011, 04:49:57 pm

OptOut / Unsubscribe / Groups: thats confusing for the Admin as well as for the user. Suggestion:

Agree.

Quote from: ecki on July 15, 2011, 04:49:57 pm

- do not differentiate between unsubscribe and optout. You add one link, which contains the receivers idendity and the mailing
- this link displays a page describing the options:

- please do not sent me any bulk mail anymore (optout)
- please remove me from the following mailinglists
-- list
-- list

I would also an feedback option.

It will be easier indeed (as well for regular mailings). The list of lists might be empty, and some of the lists might be private. Not sure if it's wise to let the user unsubscribe from a private list (eg. can you unsubscribe the board group? should you know you are in the "low potential" group?

But single link and merging the two actions is definitely a better solution. Would be good to let the user leave a comment/feed back indeed and save the unsubscribe as an activity.

Could you code/sponsor this work?

Quote from: ecki on July 15, 2011, 04:49:57 pm

The later might be a kind of filtered view of group memberships, or a specific new object. In case this is too complicated to be implemented a "do not send me mails of type :<mailing title> anymore".

Not sure what we could do with this information. How would you process it?

Quote from: ecki on July 15, 2011, 04:49:57 pm

BTW: the spam prevention on this forum sucks big time. Why do I need it as registered member anyway?

Yeap, but a forum full of spam sucks even more

X+

mclyde · August 05, 2011, 06:34:46 am

I am confused with the current setup - (using 3.4.5)

* I selected a group of users via a contact search
* selected the action send mass mailing (as I had more than 50 users selected, the send email to contacts recommended this)
* in civimail setp 2 I am required to select an unsubscription group

Does "unsubscription group" mean remove them from future mailings to this group? Since this was a one time mailing I did not create a group, so not sure how that would work . There does not seem to be any way to add a new group at this step, so I have to go back and create one. Is it suppose to be the same group as the group receiving the mail or at least that group contains the group receiving the mail?

Or is this supposed to be a distinct group of members who have opted out of these mailings (and others) so this provides a way to update an opt-out list of all mailings?

Do I have to add this unsubscribe group to the Exclude list or are they automatically excluded?

Thanks!
Merlise

Donald Lobo · August 05, 2011, 07:44:18 am

hey merlise:

the unsubscribe group is basically a container group to record all unsubscribes. Typically the flow should be to use the same unsubscribe group for all search based mailings, so users can opt-out of such mailings.

the system automatically excludes people from the unsubscribe group. u dont nee to exclude them in the exclude groups

lobo

obiuquido144 · January 24, 2012, 03:04:18 pm

Hi everyone,

Great discussion here!

I am a long time Base Group confusion follower and noticed this change today when upgrading. It's a great step forward.
Although not a native speaker, I would like to propose a wording update to the Help box (and maybe even the field title), which I believe would make the changed behavior more understandable for a) someone who comes to the form knowing the old Base Group behavior and not knowing the background discussions about the new behavior, or b) a new CiviMail user.

With the current wording I keep losing the context of what is being referred to. Also the word 'unsubscribe' is being used in 'unsubscribe from an email' as well as 'unsubscribe from a group' which IMHO creates confusion and fails to draw attention to the risk of potential 'unauthorized' removal of contacts from Groups 'by the computer'.

For your reference, the current wording is here:

Quote

Indicate which group a contact is removed from upon unsubscribe.

Because this mailing is using the results of a search to provide the recipient list, you need to specify group to manage unsubscriptions to this email. If a contact who matches your search results is already unsubscribed from the Unsubscription Group, that contact will be removed from the recipient lists.

If a contact unsubscribes via the unsubscription link in this mailing, they will be unsubscribed from this group. If they are already in the group, then they will be removed. If the contact is not yet in this group, they will first be added and then unsubscribed

Contacts who are in the Unsubscription Group but do not match your search critera will not be included in the mailing. If you wish to include these contacts please include the group using the form below

And my proposed Help box text is something along these lines:

For future-proofing and also improved self-explanation, I'd prefer to use "Opt-out Context" (or at least "Mailing Context") instead of "Unsubscribe Group".

Quote

Opt-out Context lets the system adequately process recipients' requests to be unsubscribed from search-originated mailings.

If a recipient unsubscribes from this mailing via the provided link, he will be added and removed from the Group selected as Opt-out context, effectively preventing him from receiving future mailings where the same Group is selected as Opt-out Context.

Currently, the Opt-out Context is mapped to one of the available Groups of contacts. As mailings originating from results of a search typically inherently defy being ordered under one Group of contacts based on the contact's role, it is advised to create a few initially empty "Mailing Groups" based on the type of the mailing action and use those as Opt-out Context. You can even have a single "Mailing Opt-outs" Group for search-originated mailings if you don't require the extra granularity.

(Contrary to the behavior of the "Base Group" field in older versions, contacts who are members of the Opt-out Context Group but were not matched in your search will not be included in the mailing. If you wish to include these contacts please include the Group using the form below.)

I'd be happy to hear your feedback and corrections, and if a consensus is reached I'd be happy create a patch with the improved message.

IMO ironing this out is very important for old Civi users and potentially a good step towards the future decoupling of Groups and Mailing Intents.

Thanks,
Boris

Dave Greenberg · January 25, 2012, 05:56:16 am

Hi Boris - Thx for the thoughtful input on the help. I need to check out the changes in behavior and also see if I can get a few more eyeballs on your suggested terminology changes - will post back here shortly.

xavier · January 25, 2012, 06:47:01 am

Hi,

Afraid I don't find this clear(er).

Quote from: obiuquido144 on January 24, 2012, 03:04:18 pm

Opt-out Context is mapped to one of the available Groups of contacts. As mailings originating from results of a search typically inherently defy being ordered under one Group of contacts based on the contact's role

Anyway, I'm still not sure I fully understand the goal of this group

If I user opt out, it goes out of every single mailing list, no matter the group, so you don't need any group, do you?

Is it's the other (non mandatory) token to unsubscribe from groups? In general, that distinction between opt-out and un-subscribe is really confusing for all my users (and myself).

IMO the UI should be a single unified one that:
- list all the public groups, with the one(s) the user belong to checked
- mix in the private groups the user belong to

add a optional field to provide an explanation/comment (and save as an activity)

X+

obiuquido144 · January 26, 2012, 03:31:44 am

Hi Xavier,
you caught me uneducated, as our org doesn't use the full functionality for automatic tracking, opt-outs, unsubscribes, I didn't know there was a difference between global Opt-out and Unsubscribe from a Group (i.e. Mailing list). So my Opt-out terminology actually adds to the confusion, sorry for that.

So a distinction needs to be made between the Opt-out and (Newsletter/Group) Unsubscribe in the text.

Here's my 2nd attempt:

Quote

In search-originated mailings, the "Unsubscribes Register" identifies a Group from which recipients are removed in case they click the optionally available Unsubscribe link (as opposed to the global Opt-out link).

If a recipient unsubscribes via the Unsubscribe link, he will be removed, or added and removed if not yet a member, from the Group selected as "Unsubscribes Register", effectively preventing him from receiving future mailings where the same Group is selected as Unsubscribes Register, while allowing him to still receive other email correspondence.

For search-originated mailings, which in their principle contain contacts across multiple Groups, it is necessary to provide the system with a target Group for handling the optional Unsubscribe requests: the Unsubscribes Register.
If your organization already uses "core" Mailing Groups for e.g. "Monthly Newsletter Recipients" and "Exhibition Opening Invitation Recipients" which you then combine with one-time recipients coming from a search, the best is to select the "core" Mailing Group as the Unsubscribes Register. (However please note that if a one-time recipient unsubscribes, i.e. is added and immediately removed from the Group serving as Unsubscribes Register, and later is manually added to the "core" Mailing Group, he will not begin receiving emails again. This is a current limitation of the system.)
On the other hand if you don't use any stable Mailing Groups because the recipients of your mailings are for example determined by Tags, it is advised to create a single "Mailing Unsubscribes Register" Group and use it as Unsubscribes Register for all your search-originated mailings and satisfy the system's requirement in this simple way.

(Please note that contrary to the behavior of the "Base Group" field in older versions, contacts who are members of the Unsubscribes Register Group but were not matched in your search will not be included in the mailing. If you wish to include these contacts please include the Group using the form below.)

Thanks to both for reviewing this idea.

CiviCRM Community Forums (archive)

News:

Author Topic: Mass Mailing from search results confusion (Read 9142 times)

ken

Re: Mass Mailing from search results confusion

adharris

Re: Mass Mailing from search results confusion

xavier

Re: Mass Mailing from search results confusion

adharris

Re: Mass Mailing from search results confusion

Donald Lobo

Re: Mass Mailing from search results confusion

ken

Re: Mass Mailing from search results confusion

ken

Re: Mass Mailing from search results confusion

ecki

Re: Mass Mailing from search results confusion

xavier

Re: Mass Mailing from search results confusion

mclyde

Re: Mass Mailing from search results confusion

Donald Lobo

Re: Mass Mailing from search results confusion

obiuquido144

Re: Mass Mailing from search results confusion

Dave Greenberg

Re: Mass Mailing from search results confusion

xavier

Re: Mass Mailing from search results confusion

obiuquido144

Re: Mass Mailing from search results confusion