re-consider Newsletter Service, marketing automation

[patrick727]

sendpulse seems to show up in spam too often. We are going to switch over to a new service that may be more trustworthy for major email providers such as gmail

[Ojimadu]

The newsletter shows up mostly as spam for the few I have received. FWIW I did not receive the last newsletter. The newsletter never show up a couple of times too.

Campaigner, HubSpot, Pardot, MailChimp has nice reviews we might want to try out one of those.

[patrick727]

yes we are thinking mailchimp because its the one that I am most comfortable with.

Cheers!

[Ojimadu]

Let's give mailchimp a try and see how it goes.

[patrick727]

Agreed

[Keaycee]

Sendpulse has not been reliable for sometime now. @patrick727 @Ojimadu Have you made a review or inquiries about Mailchimp? However, i think they are the largest automated marketing platform and very reliable.

[dckc]

Is there any particular reason to have a newsletter separate from the blog?

If we want to distribute by email:

• https://blogtrottr.com/
• How to Create an Email Newsletter From Your Blog

[pmoorman]

Hey guys, I thought I could contribute a little to this discussion.

TL;DR: Switching to Mailchimp is not a good idea. Go for ConvertKit or Drip instead.

I have been doing email marketing for a couple different companies for quite some time now, and really there are only 2 reasons why people use Mailchimp:

1. Because they get 2000 subscribers for free
2. Because everyone else is using it, so it must be good

Unfortunately, using Mailchimp has a couple pretty significant drawbacks. Main things are...

• Deliverability :: Due to the way they structure their servers the deliverability has massive fluctuations (if you share a server with a spammer... you're out of luck. Because Mailchimp is cheap, there are quite a few spammers)
• Functionality :: is very beginner-focused, but leaves many essential features lacking once you grow. Especially stuff like automations works shit compared to other services
• Account blocking :: Because Mailchimp is cheap, they draw many spammers / sketchy people. Because of that they're hypersensitive to everything, and basically will block accounts for no reason.
• Bad support

Basically, MailChimp is for beginners and side-gigs.
Not for mission-critical operations.

I could write a 2.000-word essay about it, but here's some other people who have already done so:

• Big blogger
• Videofruit
• Specifically about deliverability
• This guy

Instead, I would suggest we switch to either ConvertKit or Drip. Both are also reputable companies, but they are way better.

Personally I've used both MailChimp, ConvertKit and Drip professionally, and I can vouch for both of them.
Out of the two, ConvertKit is easier to use (and beginner-friendly), and Drip is better for advanced functionality.

So my suggestion, go for Drip or ConvertKit.

P.S. If I can help in the switch, let me know.

[patrick727]

@pmoorman great feedback I'll look into those options and update the community.

Great timing

[traviagio]

I've noticed from other ICOs that Mailchimp is easy to hack (I think they don't have 2FA?) I am pretty sure when Enigma ICO got hacked, they were using Mailchimp. So I would suggest 2FA provided if possible.

[pmoorman]

@patrick727 what can we do to move this issue forward?

I saw that @lapin7 created a new issue (issue #253) about better onboarding new coop members.

It would be great if we could integrate that into the marketing automation also.
For instance, the flow could look like the below (@lapin7 , let me know what you think!):

1. We make it really easy on the website to sign up to "join the RChain cooperative" => person leaves email address

2. We receive them in the marketing automation tool, and schedule out an onboarding sequence, that tells people exactly what they need to do. That way it's not so confusing, because we can really spell out step-by-step what they need to do.

3. We could track on the member website whether people have completed certain actions (e.g. uploaded their passport, activated with Github, etc.), and then send them more information about the next step. That way, everyone get a personalised help.

4. Once they're onboard the Coop, we also automatically nudge them to complete the "who are you" form. I know that now for instance @dckc pushed me to fill that out, but really a marketing bot could just as well do that.

We could expand this as we go, to make it fully automated, and to make sure nobody gets lost in the complexity of onboarding. We could also for instance treat developers differently than marketing members (because they're probably looking for different sorts of information).

Two questions:

• Is this rough idea something worth pursuing? (maybe we should really discuss this in O> Onboarding coop and RAM members [#15 cont.] #253 I guess)
• @patrick727 what's needed to make a decision on the platform, and move forward?

If we want to implement the above, I would suggest we use Drip rather than either MailChimp or ConvertKit. Drip will give us by far the best feature set to implement automations like this.

If we agree, I'll send @patrick727 a private message so I can set it up, and we can discuss within issue #253 more about the exact details of the onboarding sequence.

Let me all know what you think!

[lapin7]

That looks great to me. I'm looking forward to a workflow in Drip. If the final result is a personal page where the user can manage own data. Such a page would also give a summary of the issues that the collaborator has been working upon and it could play a role in the invoicing and payment process.

[pmoorman]

@lapin7 thanks for your input. Then I'd suggest the following course of action:

• Let's go with Drip (best suited for stuff like this)
• Let's escalate this onboarding topic towards it's appropriate place: issue O> Onboarding coop and RAM members [#15 cont.] #253
• Who should I contact to get the necessary details to make the migration (@patrick727 ??)

Also, @lapin7 the stuff you're mentioning like personal pages etc. is something that I would consider outside the scope of the marketing automation. But it's good to know that that's where we want to go, so we can set things up with that already in mind.

[Ojimadu]

@pmoorman Great idea you've got. The website already has a join the coop link and the only requires one to sign up with an email and a password. From there we can add automation and track the things you said above. Like @lapin7 said I would like all these to be done on the member page. Let's talk more at #253
For the Newsletter, thanks for your indepth view let's get feedback from @patrick727 so we can try out Drip.

[pmoorman]

@patrick727 I'd like to execute the email marketing platform before the end of the month, so we can tick off this issue.

I have created a fresh account on Drip, but there are a couple of things that I need to make the proper migration:

Needed actions

1. Ideally, we need a [email protected] email address. :: This echos the comment of @traviagio regarding security: at least people can see now that it comes from the same domain as the website. For similar reasons, this will also increase deliverability.

My suggestion: [email protected] or [email protected] or something like that.

2. Export of emails (from SendPulse) :: I don't know who has access. If someone can give me access, I can do it. Otherwise, a .csv file is also fine.

3. Verify sending domain :: Internet service providers use DKIM and SPF authentication to help identify who sent an email so they can determine what to do with it. For this reason, you want to send from your own domain (otherwise it'll be sent from Drip's domain, which is standard).

For this we need someone with DNS access to rchain.coop to put the following CNAME records in:

Host: drip.rchain.coop => Value: u6798616.wl117.sendgrid.net
Host: s1._domainkey.rchain.coop => Value: s1.domainkey.u6798616.wl117.sendgrid.net
Host: s2._domainkey.rchain.coop => Value: s2.domainkey.u6798616.wl117.sendgrid.net

4. Import into Drip + setup credit card + start mailing :: I can import everything, and record a video for everyone so it's easy to get started. It's not rocket science, anyway.

For the credit card: I don't know how this is typically done, but I guess someone like @lapin7 can maybe help here?

++++++

Right now, there are a few things blocking me from executing:

• the [email protected] email address we'll work with
• A .csv or similar export from SendPulse OR access rights to SendPulse (so I can make the export myself)

Point 3 is technically optional, but just good practice to do. So not a blocker. The creditcard becomes a blocker once we import the addresses. Right now I can work because first 100 emails are for free in Drip.

@patrick727 or @lapin7 can you help me removing the blockers above?
Other than that, everything is ready to go.

[lapin7]

There are general addresses:
[email protected]
[email protected]
[email protected]
.....

[lapin7]

For [email protected] there's a problem. The response is not quick enough. So what I could do is forward all that mail to a RAM (RChain Active Member). What do you think?

[pmoorman]

Btw, as a relative newbie, I have a question about how the "rewards allocation" works:

I see in the spreadsheet that already 71% of the rewards are allocated, but as far as I can tell, no real work has really been executed.

I mean... we've talked about it, but we haven't really done anything yet.
This seems to me like a massive dis-incentive for whoever ends up doing the work.

It seems we should either significantly raise the budget, or consider how we split the rewards @Ojimadu

[lapin7]

So anyone can raise an issue, if s/he thinks it's good for RChain. The limitation is to find 2 others to back your idea up. At least 3 people are necessary to set the budget. If you're alone then no budget is allocated and thus no rewards being given. At least 3 participants on the issue have to express their view on the reward for each person. If you don't get 2 other participants backing your view up, then you don't get a reward.

The system is completely decentralized to the level of issues. The workers decide about budgets and rewards. If conflicts arise then they have to solve it them selves. So we agree/disagree about small to the point issues.

In my view is talking about an issue like planning what to do. And planning is work. So the folks should be rewarded. One aspect of planning is raising the budget.
The rewards are based on what you think how much you should earn and what you think how much the other participants should earn.
If you think that nobody has done anything yet, then you can add negative rewards so that the budget has still enough to pay for the real work.

Anyway this system is evolving and of course there will be more rules and restrictions in the future, but the progress is amazing to me:

• From Jan to July 2017 there was nothing. Only a few collaborators, no system.
• In August a free to spend budget of 100.000 RHOC was approved
• Then we got a few collaborators
• Then we decided to use Github as a management tool
• Then we started bridging our channels (@drbloom, @jimscarver, @kitblake, @entropee , ...)
• We made a reward system with spreadsheets (@jimscarver, @lapin7)
• We made an onboarding system through google forms, but it got overruled by others
• We still have a lousy onboarding system, with lots of manual tasks
• The issues got into a spreadsheet by screendump, copy/paste/clean and the folks were manually added
• From August to November Budgets were set by @lapin7 and rewards as well, because nobody took the pain to go for the RHOC's. It was based on participation with comments in github issues
• December I stopped filling out budgets/rewards and the folks got angry by not being paid
• Now the issues and the collaborators get filled by a script (thanks to @dckc)
• The folks enter for the first time in January the budgets and the rewards
• Results of work done has been of little concern
• Issues are still poorly formulated and not SMART, the github features are not much used
• In December there has been abuse of the system and the problem of trust became a problem
• In January the folks start to correct each other by entering negative rewards see M> Community Co-operators #115
• In February Results and Rewards will get more attention
• A long the way, things get better and the productivity is IMMENSE. :-) look e.g. at M> Translate video Exclusive chat Lawrence Lerner & Nash Foster  #251
  M> Translate video Exclusive chat Lawrence Lerner & Nash Foster

[jimscarver]

My opinion is that is is a disservice to members to use any 3rd party mail system or smtp provider as we are exposing them to tracking.

My suggestion is that we use mailtrain on cloudron as it manages email and many other useful apps for the community with practically zero system administration.

It took only a few weeks for the my.divvydao.net cloudron smtp provider to become well trusted.

It can be expected that some spamish newsletters will go to spam independent of the smtp provider due to spam filtering. If someone has a problem direct them to mark the email not spam to fix it. Repeat if necessary.

[Ojimadu]

@pmoorman I actually prefer setting a budget at the end of the month where I can get a better grasp of what was done since most issues are not 'smart' including this one. The budget and reward I set on this particular issue was quite arbitrary save for HJ and patrick this was quite a few days ago as I could not actually determine who did greater work for much part of this but now that is different, the level of work done has increased and that has to be reflected in the budgeting but the budgeting is a subjective one based on individual perception and I may not have the best perception so I implore you to set the reward as you deem fit.
Based on the work outline you submitted I think the budget has to be raised but I will prefer we set rewards for this month and then set a corresponding budget next month based on the work done as more work is likely to be done next month.

@lapin7 I actually hoped you would set reward for december but was suprised you did not but I got the message you passed across :)

[pmoorman]

RE: Operational / budgets

@lapin7 and @Ojimadu thanks for clarifying. It's good to better understand also a little bit of the background of how this reward/bounty system evolved.
Appreciated!

RE: privacy & tracking

As for @jimscarver 's comment: I think you're raising a good point about the tracking. On the upside though: we would be able to use basic tracking infrastructure to help give people a better onboarding experience (for instance: we'd register/track that they already uploaded their passport, and then don't bother them about it anymore). I think that – considered on the whole – this kind of tracking is a positive outcome for new members, rather than a negative.

To summarise:

• Drip will offer many more options, especially if we want not only newsletters but also to run the onboarding flows on it.

• Something like Cloudron offers better privacy protection.

Personally I'm still thinking Drip would be a very good option, but then again: I'm relatively new in this community, and I might misread the general sentiments. Other people's opinions much appreciated (@lapin7 @patrick727 @Ojimadu @traviagio )

[Ojimadu]

Am not exactly familiar with how the different mail system works but don't we already use a third party mail system, Sendpulse?
@jimscarver I don't get the aspect of tracking you are referring to here If I understand @pmoorman correctly, we are only using basic tracking like upload of ID, verification or if a new member already has an activity on the github repository so a mail mail can be sent to them encouraging them to flesh out their profiles and things like that and not personal/intrusive information.

[pmoorman]

almost all email marketing providers will automatically track stuff like opens, clicks, etc. How intrusive that is, is a matter of taste really. MailChimp, Drip, SendPulse, etc. are all mostly the same in that regard.

We wouldn't track super intrusive stuff, but we would roughly remember what you did while you interacted with us.

The real question should be:

"To what extend is our tracking helping/hurting people?"

In my opinion, a little bit of tracking would go a long way to providing a much better onboarding experience (and future educational experience). So much more 'helping' than 'hurting'.

[patrick727]

@pmoorman please do not move forward in creating an independent drip account.
I appreciate your drive and wanted to tick this off before yesterday.

I reached out for approval of the service shift and was haulted.
This one is less of a deal and I will push for, remaining considerate of the Board, etc.

these types of accounts fall under [email protected]

[pmoorman]

@patrick727 no problem. I understand that those choices need to be signed-off on by more than just 3 Github upvotes.

I'll wait here, ready when you are ;-)

[patrick727]

3 Github votes never was the decision making force for these types of activities.
3 Github votes was for you to choose a budget for an issue you made.

This is suppose to be the choice of the driver.
I used this issue, along with others like logo, etc as a place to organize feedback, and demonstrate github for project management.

Seems its getting mixed up.

[dckc]

1. To decide that we should put the privacy policy on the website

It's obviously true that the web site footer should link to the privacy policy. No reason to use executive committee time for that. Just Do It.

You note that we already do 3, so again, no reason for a decision there.

As to 2... I don't see motivation in your proposal for passively collect data; nor tracking whether email was opened. What am I missing?

I hope we can reduce this to one proposal to the executive committee, which would allow a simple "yes" response to address the question.

It seems to me that the question is: Shall we take advantage of mature 3rd party marketing automation services to smooth onboarding of coop members, even though it would entail sharing member contact information with these services?

The reason I think it merits executive committee time is that neither Ian nor I support the position enough to work toward it, but we recognize the possibility that it might be in the best interest of the coop.

One thing that nags at me: how would membership credentials (username / password) get set up? At what point would the service direct the lead back to a site of ours for that? If you would sketch one possible design, that might help.

[ian-bloom]

My greatest concern is for the privacy of our member's email addresses, names, and PI (personal information). This data should never be shared with a third party without our member's consent. We are not just being respectful. Members will have claim to significant crypto-assets in the form of their yearly REV rebate.

It might be argued that data captured from a Newsletter Signup does not need to be kept as private and secure as our membership data; however there will be significant overlap. I understand that you, @pmoorman, are a marketing professional wanting to track and monitor in order to see where we fail in funneling leads, but we can be effective in enrolling members without recording every possible action, click, scroll, time-on-screen measurement, etc.

The "ugly" numbers that I referred to in our conversation are the numbers of people who begin the member registration and drop off before paying or uploading their ID. There are obvious improvements that the New-Member WG is planning to implement such as clarifying early on during registration that there will be a $20 fee, ID upload, and live ID verification over webcam. Registrants must also be better informed as to why Co-op needs the ID, how it will be stored, and who will have access to it.

We can argue about the pros and cons of using a 3rd party service for the newsletter, but any MEMBER communication should be handled in-house.

[dckc]

You made your position clear earlier, Ian. But I think it's worth getting input from others.

[pmoorman]

@dckc I think you summed it up well for the Executive Meeting. I suggest we go with that phrasing you suggested:

I hope we can reduce this to one proposal to the executive committee, which would allow a simple "yes" response to address the question.

It seems to me that the question is: Shall we take advantage of mature 3rd party marketing automation services to smooth onboarding of coop members, even though it would entail sharing member contact information with these services?

---

@lapin7 I think your response above is out of the scope of this issue. The topic of the issue is to: "re-consider Newsletter Service, marketing automation". If you need someone to take action on the things you talk about, that should be a new issue.

---

@ian-bloom in response to the points you made: it's ultimately — like Dan's phrasing suggests — a trade-off between efficiency in getting developers on board vs sharing data with 3rd-party services. Within the marketing-focused folks in RChain, there is a fear that lack of speedy execution will cost us significantly in terms of the numbers of developers and thus DApps we'd get built on RChain.

Anyway, I think with the above couple of comments we should have enough of a perspective on both sides of the coin to let the Executive Committee make an informed decision here.

[pmoorman]

@ian-bloom @dckc what is the process to get this issue on the executive committee?

As noted above, Dan summed up the ask well, and I suggest we submit the following to the Exec Committee to review & decide:

I hope we can reduce this to one proposal to the executive committee, which would allow a simple "yes" response to address the question.

It seems to me that the question is: Shall we take advantage of mature 3rd party marketing automation services to smooth onboarding of coop members, even though it would entail sharing member contact information with these services?

What is the process to get this on the next Executive Meeting agenda?

[dckc]

I'm standing by for a response to my March 24 question: how would membership credentials (username / password) get set up? At what point would the service direct the lead back to a site of ours for that? If you would sketch one possible design, that might help.

I think the process for getting this on the executive committee meeting agenda is to convince a committee member to make an agenda request. I made a request.

I think the conversation would be more clear if you'd remove the "we should put the privacy policy on the website" from the March 24 comment where you lay out your argument.

I'm deleting the off-topic comments about invoicing.

[allancto]

@dckc @pmoorman @lapin7 and all. @jimscarver and the digital id people have been spending many hours of dilligent effort on this question, @llerner and lifeId and others have also been working. Can we not utilize their work, perhaps in conjuction for now with our legacy centralized systems, to address the issue of how members are to communicate without compromising their identities? @jimscarver ?

[dckc]

I'm reasonably confident none of that work is sufficiently mature. I haven't seen anything in the space that would not be more trouble for new members than what we are already doing.

[cboscolo]

I don't mean to string this thread out any more than it already is, but with talk of a Germany office, and many coop members living in the EU, the coop will quickly find itself in the crosshairs of GDPR if it is storing user PII. (I know I cringed when I had to send a picture of my license to join the Coop.)

We (lifeID) would be happy to help solve any identity issues in a privacy-preserving way if we can!

[allancto]

@dckc @cboscolo perhaps I'm misguided, but can we do both? If the current project is far enough along, I'd be happy to volunteer for a more future based sub-experiment to evolve as rapidly as it evolves and hopefully be appropriate someday for all of us to adopt. There are many reasons members need to communicate reliably and securely, @Jake-Gillberg is also talking about this. @leithaus mentioned it in the community debrief today. We may be a long way from being able to provide the same degree of service that Google can, but email/ chat/ voting may not be awesome mass market apps, but they're critical to the RChain membership here and now. If we need to open a new issue around pilots for the future I'll be happy to do that, i'm certainly an advocate of eating our own dog food.

[dckc]

@cboscolo how would it work?

I'd be happy to learn that my confidence about lack of mature next-gen solutions is due to ignorance.

A new issue is probably better, unless the solution you have in mind really does handle the scope we're talking about here, which goes from somebody answering a "sign up for the newsletter" call for action thru joining the coop and KYC (see pmoorman's Mar 24 comment above).

[cboscolo]

@dckc your (lack of) confidence in next-gen identity solutions is reasonable and I certainly don't want to over-sell its readiness. But, what I do know is that current "state of the art" in tracking user info is ripe for privacy abuses and, as I alluded to above, likely opens the door to fines in the case of GDPR violations. Not to mention that the user experience for the KYC steps is clunky. So, it may be at least worth considering how we could prep for the future.

I'm not sure how to answer the "how would it work" question, because it is not entirely clear to me yet what the "it" is. Sorry for the lack of context, I was asked to look into this thread about 6 hours ago. Are there any docs I can read to come up to speed on the system being proposed?

[jimscarver]

EU members do not need to go through the KYC process thankfully but GDPR is still an issue with respect to email and other personal data we collect. Thanks for bringing it up @allancto

Jlink labs offers an affordable GDPR solution for email https://www.jlinclabs.com/gdpr-email-consent-solution.html

I have been speaking with folks from jlinklabs and they say they can support mailtrain in addition to the services they list. I am cooperating with them on contract language we can use to support gdpr among decentralized organizations beyond email.

I am moving the GDPR discussion to #254

[cboscolo]

@jimscarver your comment that "EU members do not need to go through the KYC" surprises me.
Are you sure about this? (Sorry if this question belongs on #254)

[pmoorman]

@dckc said:

I think the conversation would be more clear if you'd remove the "we should put the privacy policy on the website" from the March 24 comment where you lay out your argument.

Fair enough. Done.

I'm standing by for a response to my March 24 question: how would membership credentials (username / password) get set up? At what point would the service direct the lead back to a site of ours for that? If you would sketch one possible design, that might help.

Not sure I understand your ask correctly, but here's what I think...

• In an ideal world we'd try capture an email address (not password) earlier in the process, so we have more control over the communications.

• Once they show interest to become a member, they go to the "become a member" page, and (re)submit email+password there. This is just the same as it is right now. Maybe we can pre-fill the email address if we have it already on record, but people might want a different email for "serious stuff" like joining the coop.

• After that the coop database has the email+password, and passes off the email to email provider again, with a tag "start onboarding" or whatever. Modern email tools can normally also understand that one person might have multiple email addresses (pre-signup & post-signup), and that they are related.

That's it, I guess. Not much different from what we have right now. Other variantions might also work, as far as I'm concerned.

[pmoorman]

@allancto @cboscolo

Allan said:

perhaps I'm misguided, but can we do both? If the current project is far enough along, I'd be happy to volunteer for a more future based sub-experiment to evolve as rapidly as it evolves and hopefully be appropriate someday for all of us to adopt.

Yes, this is a good idea. I would suggest we spin out this part of the discussion into a separate Github issue, so we can explore further. I would also be interested to be involved with that, and see what lifeID can do!

BUT.... on this issue I would like to make a decision with the eye on implementation in the next few weeks. That's what I would like to focus this issue on, and I think in that regard next-gen tools simply aren't ready yet, like @dckc already stated.

[dckc]

@cboscolo writes:

Are there any docs I can read to come up to speed on the system being proposed?

Ahahah... that's a good one. Oh... you're not joking, are you?

Presumably you fumbled your way through the RChain onboarding / membership process. The system being proposed is anything substantially better than that. :)

This issue is just one part of it... Take a look around the other greeter issues to see some of the thinking.

[cboscolo]

@dckc I was half-expecting that response but wanted to start by asking.

What I am looking for is any info on the backend infrastructure that we are trying to fix. Is there a repo somewhere that I can look at to see how it works? Who is actually working on it?

[dckc]

Is there a repo somewhere that I can look at to see how it works?

That was one of my first questions too. I gather there is not.

Who is actually working on it?

I had hoped the greeter issues would give some sense of that... @kitblake and @ian-bloom are playing leading roles. For the member-site aspects of it, item 5 in the notes from the March 2 executive committee meeting gives a concise view.

[pmoorman]

I suggest we close this issue, since the Executive Committee doesn't see enough support for going with 3rd-party email services at the moment, and is taking the lead towards further action:

From the Exec Committee minutes:

[Ian Bloom]: I would like to nominate inblock to help onboarding process and voting tools
...
ACTION: Ian will work with Deanna D to define requirements and implements registration verification payment voting