Members get removed from existing audience when resubscribing to an audience that they already belong to

[jsunsawyer]

We're running into an issue where if a member is already subscribed to an audience, then tries to resubscribe, they are removed from that audience.

If doubleOptIn is set to true, the user is removed from the audience. They receive an email to confirm their subscription. Once they confirm, they are re-added to the audience – any historic data tied to this member is seemingly lost.

If doubleOptIn is set to false, the user is subscribed to the audience as a new member. Again, any historic data seems to be lost.

Should the plugin be handling checks for existing audience members?

[codyjames]

This is actually a bigger deal than it seems. Any chance we can get an update on this?

[nathansnelgrove]

I would also love an update on this. It would be very useful and help me clean up my Mailchimp account if this worked as it should. The docs imply that you should have no issues with this is you're not using hidden fields, but I can confirm that this is not the case.

[aelvan]

Hi,

As noted in the docs:

You will not get an error message if you submit an email address that's already subscribed to your audience – this is intended behavior. If you want to check if an email is already in your audience, you can use the template variable craft.mailchimpSubscribe.getMemberByEmail or the controller action mailchimp-subscribe/audience/get-member-by-email, and check if the response is null, or what the status of the member is.

But I wasn't aware that resubscribing/updating a user erased historic data, which is kind of a bummer. I'll look into if there is a better way to handle this.

[nathansnelgrove]

I can't say for everybody, but for my use case, I don't think I need the user to get notified if they've already subscribed. But if somebody subscribes again, and they have Tag A from their previous subscription, and their new subscription adds Tag B to their information, that shouldn't override Tag A. It should just add Tag B in addition to it.

The same would be true for interest groups, etc.

This works well with the Mailchimp for Wordpress plugin, but I'm unsure how they implement it.

[aelvan]

I've tested this now, and I don't see the behaviour that @jsunsawyer describes. But maybe I don't understand the issue. Here's my test procedure:

1. I subscribe a new user to an audience, adding some fields, some interests, tags, marketing permissions, etc. I confirm that the information is stored.
2. I resubscribe (using the exact same form), and choose some new interests and change marketing permissions. I confirm that the user gets updated with the new data. In the activity feed for the user, it now shows the changes I did to marketing permissions.
3. I create a campaign and send to my audience. I confirm that the user gets the newsletter, and that it shows up in the activity feed.
4. I resubscribe, this time from a subscribe form that only contains email address. All fields, interests, tags and marketing permissions are still intact on the user. The activity feed still has the same information as prior to the last resubscribe.

@jsunsawyer Do you get different results?

@nathansnelgrove To be clear, tags are only removed if new ones are added, or if the form contains an empty tags[] input field. If you have an existing user, you can get the member information about the user, and add the tags that the user already has - either as visible options, or as hidden inputs.

But, I realise that there might be use-cases where you use tags in a way where this is not ideal. One question though, I can't quite wrap my head around how you'd be able to remove tags in your scenario?

[nathansnelgrove]

@aelvan interesting. This isn't the behaviour I'm seeing.

So my use case: I have a personal blog. When people get subscribed to the list, they get tagged "Personal Blog". I also have a portfolio website. On my portfolio, if they subscribe, they get tagged "Portfolio". The input checkbox is hidden in both forms on both websites. The personal blog is WordPress; the portfolio is Craft. Because I'm in Canada, I'm required by law to enable double opt in, so double opt in is enabled on both sites.

A couple scenarios:

• User A signs up on my portfolio first. They get the "Portfolio" tag. Then, they sign up on my blog. The "Personal Blog" tag is added and they now have both tags. I can confirm, then, that my blog is working as intended.
• User B signs up on the blog first. They are given the "Personal Blog" tag. Then, they sign up on the portfolio. The "Personal Blog" tag is removed and the "Portfolio" tag is added. This sign up form is definitely causing the issue, or at least my implementation of it is.

It wasn't clear to me in the documentation that I had to fetch the user info and loop through it in order to avoid overwriting it, which I suspect is what it happening here.

[aelvan]

Yeah, ok, we're on the same page now. I can confirm that if you resubscribe a user that already has tag "one", and pass in another tag "two" and not "one", only "two" will remain after the resubscribe.

You're use-case for tags seems to make sense, it's just not one that I'd thought of. I guess an "append-only" type of setting could solve this. Although, how would a user unsubscribe/remove one of those tags? Or is that not relevant?

The original issue by @jsunsawyer still sounds like something different; "any historic data tied to this member is seemingly lost". Need more info about that.

[jsunsawyer]

@aelvan I'll try to give this another look when I get some free time. (hopefully soon!)

Off the top of my head, I remember seeing users' subscribed/unsubscribed history go away. Is this the case for you in any of your tests?

[nathansnelgrove]

@aelvan I'm doing some experimenting and I can confirm I am also experiencing the same bug as @jsunsawyer. When I add an email that's already on the list, all prior history is removed and the "manual addition" is considered the first step in the history of that subscriber.

I just confirmed this by trying the test case I've been using to file this bug report, which I assumed was related.

It seems to me like what's happening is the subscriber is getting completely removed, then re-added with the new tags or interest groups.

As far as your question for me:

I guess an "append-only" type of setting could solve this. Although, how would a user unsubscribe/remove one of those tags? Or is that not relevant?

An append-only setting would tremendously simplify whatever incantation I need to do to get the details for a user and loop through them. Allowing them to unsubscribe or remove one of the tags isn't relevant for my use case, but I could envision times where it would be. I just figure they can manage their subscription by clicking the links in the footers of the emails they receive.

[aelvan]

When I add an email that's already on the list, all prior history is removed and the "manual addition" is considered the first step in the history of that subscriber.

Does it actually say "Manual addition" in the activity feed for the subscriber? That seems weird, because for me it says "Added via API" when subscribing through the plugin.

[nathansnelgrove]

It did a couple times, but now it doesn’t. I think I made some changes to my config file that must have fixed that. That was a month ago, so I couldn’t even tell you how to reproduce it at this point (assuming it was a bug and not just user error).

…

On Jan 25, 2020, at 9:57 AM, André Elvan ***@***.***> wrote:  When I add an email that's already on the list, all prior history is removed and the "manual addition" is considered the first step in the history of that subscriber. Does it actually say "Manual addition" in the activity feed for the subscriber? That seems weird, because for me it says "Added via API" when subscribing through the plugin. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[jsunsawyer]

Here are the results I'm seeing. It's probably worth noting that the production version of this shows subscribers' sources as API instead of Hosted Signup Form. Not sure if that makes a difference here.

Step 1: Subscribe with Double Opt In set to false

Step 2: Unsubscribe via Admin

Step 3: Subscribe with Double Opt In set to true

[nathansnelgrove]

This looks right to me. The issue is with double opt in. Everything gets wiped, and rather than add new segments or tags if somebody has previously subscribed, it just removes their email and re-adds it. Then you lose the info you had for them previously.

…

On Jan 27, 2020, at 1:49 PM, Jason Sawyer ***@***.***> wrote:  Here are the results I'm seeing. It's probably worth noting that the production version of this shows subscribers' sources as API instead of Hosted Signup Form. Not sure if that makes a difference here. Step 1: Subscribe with Double Opt In set to false Step 2: Unsubscribe via Admin Step 3: Subscribe with Double Opt In set to true — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[jsunsawyer]

@nathansnelgrove To verify, by "This looks right to me.", you mean that this is the issue you were also experiencing, right? Because this is definitely removing the previous subscribe history.

[nathansnelgrove]

That’s correct — it’s exactly the problem I experience.

…

On Jan 27, 2020, at 2:12 PM, Jason Sawyer ***@***.***> wrote:  @nathansnelgrove To verify, by "This looks right to me.", you mean that this is the issue you were also experiencing, right? Because this is definitely removing the previous subscribe history. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[twosixcode]

I'm encountering this issue as well. Was there a fix for this or a plan to address it?