search

rchain / bounties

RChain Bounty Program
MIT License
90 stars 62 forks source link

re-consider Newsletter Service, marketing automation #219

Closed patrick727 closed 6 years ago

patrick727 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

Cheers!

Ojimadu commented 6 years ago

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

patrick727 commented 6 years ago

Agreed

Keaycee commented 6 years ago

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 commented 6 years ago

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

If we want to distribute by email:

pmoorman commented 6 years ago

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...

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:

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 commented 6 years ago

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

Great timing

traviagio commented 6 years ago

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 commented 6 years ago

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

I saw that @lapin7 created a new issue (issue https://github.com/rchain/Members/issues/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:

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 commented 6 years ago

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 commented 6 years ago

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

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 commented 6 years ago

@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 commented 6 years ago

@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 something@rchain.coop 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: members@rchain.coop or official@rchain.coop 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:

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 commented 6 years ago

There are general addresses: info@rchain.coop ops@rchain.coop invoices@rchain.coop .....

lapin7 commented 6 years ago

For info@rchain.coop 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 commented 6 years ago

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 commented 6 years ago

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:

jimscarver commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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:

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 socialmedia@rchain.coop

pmoorman commented 6 years ago

@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 commented 6 years ago

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.

pmoorman commented 6 years ago

oke, I see what you mean.

I'm still learning about "how things work here", so to speak. Appreciate your clarification.

Anyway... I hope the feedback helps make this decision easier, and if you need some assistance executing the change, then I guess you know who to call on. :+1:

patrick727 commented 6 years ago

thanks @pmoorman there had been a choice for newsletters and email communication moving forward. dm me and we can talk more about it

pmoorman commented 6 years ago

@patrick727 Done, see my DM in Discord

dckc commented 6 years ago

notes on discussion with Pieter, Ian, from discussion of mockups #446

Pieter: at each step in onboarding, we lose some of our audience. How about some sort of spreadsheet to see who made it how far? IB: good idea, but it might not be pretty; things are pretty messy

one position:

3rd party marketing automation for member onboarding too?

meanwhile: Privacy Policy Last Revised: August 9, 2017

dckc commented 6 years ago

I checked the privacy policy Last Revised: August 9, 2017. It does say we may use 3rd party services:

COLLECTION OF INFORMATION

We collect information you provide directly to us. The types of information we may collect include your email address and any other information you choose to provide. ...

SHARING OF INFORMATION

We may share information about you as follows:

  • With vendors, consultants and other service providers who need access to such information to carry out work on our behalf; ...
pmoorman commented 6 years ago

SUMMARY

What's the use case, anyway?

The problem we face right now, is that throughout the onboarding flow we lose many people. I don't have the data (but @ian-bloom could look it up) but for every 100 people that decide "I want to become a member" maybe only 10 or 20 or so actually become an active member. That means we miss out on 80 people that could have become enthusiastic members that contribute to the platform, engage in building DApps on the platform, and tell their friends & bosses.

The current numbers are "very ugly" according to @ian-bloom. This really hurts RChain as a project.

What I basically want to do is use email to greatly improve the percentages of people that activate. This means we'll get faster (and probably compounding) member growth and developer growth.

To make the onboarding smoother, we need to capture events such as Dan uploaded his passport and use those events to trigger personalised help to move Dan further in the flow.

Onboarding-wise, we could do things like:

Can't we build this ourselves?

I guess we can, but building out the logic to do it is time-consuming and depends on developers. In a 3rd-party tool they have optimised everything for making this easy to do.

The results is that with a 3rd-party tool we'll be able to build much more sophisticated (and thus effective) solutions, much faster.

Overlap between marketing part and onboarding part

In our discussion, Ian made a distinction between the 'marketing part' where we have someone's email but they're not a member, and onboarding where they are already a member.

According to Ian, a 3rd-party would be permittable for the marketing part, but not for the onboarding part.

Upon further thought, this presents a few problems:

My request

@ian-bloom @dckc as per the discussion: I would love if the Executive Committee can decide on these matters, so we know what options we have:

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

  2. To decide where or not to update the privacy policy to tell that we'll also passively collect data (which we'd do in either case, so really we should)

  3. To decide that we can use a 3rd-party provider for the marketing part (= before people become members).... which we do right now anyway

  4. To decide whether or not we can use a 3rd-party provider for the onboarding part (which, btw, we also do right now, through SendPulse)

In either case, the current state of "using 3rd party services but not telling anyone" is a no-go, and we can't let this sit like this.

My hope — as a marketer — is that we judge the possible privacy infringements of our vendors to be sufficiently acceptable to allow us to greatly improve our marketing & onboarding experiences. That will allow us to attract and activate many more enthusiastic DApp developers.

It's a case of 'losing the battle, to win the war'

Getting DApps developers enthusiastic & activated on RChain should be a priority, and having proper tooling to work with is a big part of that.

dckc commented 6 years ago
  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 commented 6 years ago

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 commented 6 years ago

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

pmoorman commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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...

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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?