RFC: Emails, Newsletters and Email Lists

[joethreepwood]

Currently, we don't do much with email other than:

• Sending the Array emails when a new update is announced (@joethreepwood, at least once a month)
• Sending occasional technical announcements, e.g. Async Migration reminder (@joethreepwood, irregular)
• Sending occasional marketing announcements, e.g. GitHub star valentine (@joethreepwood, very irregular and rare)

We also have plans for:

• Sending a new PostHog newsletter (@andyvan-ph, fortnightly)

Currently, these are all sent to the official PostHog users email list in Mailchimp, which has approx 660 users on it. The only exception is the technical announcements, which are usually targeted to a larger, custom list of affected users (e.g. self-hosting first users in org for async reminders) which is exported from PostHog product.

Going forward, I think there's a lot more we can potentially do with email, including:

• More announcements about product changes, such as beta invites
• Targeted upsell emails for users who may benefit from particular features, or hit tier restrictions
• Reminders to encourage lapsed users, or invite to Slack community

However, even if we don't pursue these projects at the moment email is still a fundamentally limited channel for us because of the size of our main PostHog users email list. 660 users isn't a lot, and the list isn't growing fast (11 new subscribers over the last 30 days, for example).

Opening for discussion (and keen for it especially from @corywatilo @smallbrownbike and @andyvan-ph ), but I'd propose we look at the following actions:

• Incorporating more/better CTAs across the site and product which encourage people to sign-up for optional emails, such as newsletters and Array announcements (potentially under different lists)
• Discuss a change in approach, whereby Array is sent to all users going forward.

[joethreepwood]

Worth adding that 100% of sign-ups currently come from an Embed Form, according to Mailchimp. Where this form is, however? I know it's not this one.

I'm not actually sure what other CTAs or sign-up options there are, as many existing CTAs are text manually added by authors to old PostHog blog posts, directing to /newsletter.

[charlescook-ph]

Ok cool - so taking the above, let's split this proposal into content and 'growth' (for want of a better term):

Content

• 1 Array every month
• 2 Newsletters (inc. tutorial, blog articles) every month
• One off announcements - if technical, goes to Array list, if marketing-y goes to Newsletter list (but we should continue to keep these very rare.

I think this is a big step forward for us, so no need to change. As I think discussed elsewhere, we should maintain two separate lists as one is product, the other marketing.

Getting more subscribers

• Array: agree we should just start sending this out to all users. It's not offensive to get purely product updates when you sign up to a product, and obv you can unsubscribe.
• Newsletter: I suggest we email all users a one off saying 'we have introduced a biweekly newsletter, here is the link to subscribe'. We definitely shouldn't just add people to it.
• CTAs: I think that these make sense for the Newsletter but not Array - you should get the Array automatically if you sign up to the product, but otherwise it's kind of meaningless to get it.
• CTAs: I'd advocate for including CTAs for the Newsletter in all individual blog posts ('like this content? why not sign up to get it regularly'). We already have a CTA at /blog.
• CTAs: I'd also include CTAs for the Newsletter at the bottom of each Tutorial with a similar message.

Otherwise, I think we should start getting some good newsletters out that people like and share before trying to do more on CTAs.

I think once we have done a good job on the above, then I totally agree @joethreepwood that more automated-type emails could be useful, but probably those are secondary steps to the above.

[joethreepwood]

OK, we can move forward with this.

I need to consider the best way to set this up as an automated process, as I'd prefer not to have to export the audience for every array. That would be slow and would probably decay over time as it would be tricky to make it work with unsubs.

It should be possible to make this work by using Hubspot as a middleground -- export email addresses to Hubspot using that plugin, then use Hubspot's integration with Mailchimp to sync that way. Not sure. Will investigate this properly when I'm back from holiday on the 7th.

[andyvan-ph]

Just catching up on this post-COVID. A few additional points:

• Opting everyone into Array would probably violate GDPR, so perhaps limit this to non-EU users?
• We need a newsletter opt-in option at the product sign-up stage as it's the best opportunity to acquire new users
• The newsletter also needs a dedicated sign-up landing page we can link to
• We should look at introducing a new user email engagement program as well
• We should have an announcement bar in the product when Array goes out

[charlescook-ph]

• Opting everyone into Array would probably violate GDPR, so perhaps limit this to non-EU users?
• We need a newsletter opt-in option at the product sign-up stage as it's the best opportunity to acquire new users

On these two points, we are actually already covered in our Privacy Policy, which everyone accepts when they sign up to the product. So we won't breach GDPR:

If you are a registered user of the Websites and have supplied your email address, PostHog may occasionally send you an email to tell you about security, system information, new features, solicit your feedback, or just keep you up to date with what's going on with PostHog and our products.

('Websites' is just the contractual definition in the policy used to cover anything that has xx.posthog.com in it, ie. including the app).

[andyvan-ph]

Ok, perhaps we should do the following:

1) Create two new lists for 'Product Updates' and 'Newsletter' 2) Add everyone to both 3) Tell them we're doing this and why (with one email per week promise and option to opt-out) 4) When people choose to unsubscribe, they get presented with choice to only unsub from specific lists or all of them 5) In that choice, we recommend keeping 'Product Updates' as a minimum for technical updates

RE: GDPR, though, I do wonder if that falls foul of the consent guidelines. Also, even if it were techincally compliant, I feel like it falls short of the transparency users would expect. I think we should have some kind of opt-in/out process as part of the sign-up, even if it's an auto opt-in unless actively unchecked.

[charlescook-ph]

I agree we should definitely not just be 'technically compliant' so would suggest the following tweak to your approach:

1. Create the two new lists
2. Add everyone to 'Product Updates' and in that include a link to sign up to the 'Newsletter' and encourage people?

I think it is both technically and philosophically fine to send people Product Updates using their existing consents ('it is useful for me to hear about app updates and get more value from the product', but I think getting added to a Newsletter wouldn't meet our bar here for what our users expect without making it very active consent.

[andyvan-ph]

Just a mental note from poking around in Mailchimp.

If/when we do this, it would be best if we use the existing PostHog Users list for the newsletter and create a new list for Product Updates to import into. This will save us reconfiguring any existing email signup forms.

[joethreepwood]

The issue here which I need to look into, btw, is how unsubscribes are handled. If anyone knows the answer to this off-hand, it would help speed this up...

We'll start by exporting a list of all users from PostHog, which in itself is a bit tricky as it's not possible to customise the exported columns (i.e. you get a spreadsheet over 9,000+ columns, too big for some spreadsheet tools to handle). It's also impossible to know how much the list has grown since last export, which is a pain.

There are workarounds I've used before, which I can document in the Handbook when I look at this properly when I'm back from holiday. However, what we'll likely need to end up doing is exporting this list before every email we send and importing it into Mailchimp. What I'm unclear on right now is: How will this affect users who unsubscribe and will they be resubscribed at next export? Because that's definitely against policies and values.

Either way, we'll probably be best creating two lists as Andy says, but each with a segment defining self-hosted vs. cloud. This will enable us to more easily target one-off messages for things like async migrations. It'll need a touch more process, but will save us time in the long run.

[andyvan-ph]

I think the answer there is the after we do the initial export, we need people to be added to the mailing list automatically when people signup to the product. Will require some dev work, but I think it's worth the time given how important it is to actually communicate with our users.

[joethreepwood]

If that's the case, we need to speak with @marcushyett-ph and @clarkus about how we can bring that into the product and communicate it.

[andyvan-ph]

I guess the only other question is whether it's better / possible to maintain one primary list and use segments to divide people up. Mailchimp does recommend only having one list, but not sure if it's possible for people to unsubscribe from a segment etc.

[joethreepwood]

If that's the case, we need to speak with @marcushyett-ph and @clarkus about how we can bring that into the product and communicate it.

Just adding a secondary point here, which is that this will still require either a process for exporting, or an integration with mailchimp.

[marcushyett-ph]

I've not read the full thread - but we could build a plugin (if we don't already have one) to export users to mailchimp and then use mailchimp's build in tools to manage opt outs?

[clarkus]

I scanned through things here and I think I get the gist of what y'all are proposing. Here are some quick thoughts:

1) I think email is a vastly undervalued and underutilized interface for the product and the company. I 100% agree we should be more purposeful there. 2) A good experience with email is all about timing, frequency, and ensuring the user controls their preferences such that they get what they care about when they care to receive it. This means that we should always be transparent and clear with unsubscribe links. This means that any list a user can opt into, they should be able to clearly opt out of. If we can do all this in a centralized place, even better. 3) I like the idea of secondary upsells in the product that prompt users to be more engaged with emails and the community, but it's a delicate balance. We shouldn't disrupt regular work for that kind of stuff. There are probably times that are best for prompting users, so identifying those is critical. I agree that onboarding is a prime opportunity for this, but I bet there are others. 4) There are other channels available to us for this - in-product announcements and alerts are kind of one-offs for us right now, but I think we could be more consistent with using them to announce new stuff. 5) There are product features that could be based around email - subscriptions to content for example. That greatly complicates the management of email subscriptions, so balancing all this stuff will be key.

Anyway not a ton of solutions, but I like the idea and think we should pursue email as a product / company interface. I agree that exporting is a big part of this as well - we have some export patterns, they're just not applied to every list quite yet. I agree it's a good system standard and really drives home the "you own your data" aspect of the product.

[joethreepwood]

Good news!

I just finished chatting through this with a contact who is a bit of a Mailchimp specialist. The upshot? We don't need an integration, or any in-app changes. Mailchimp will automatically prevent us from re-adding unsubbed parties to the same list again.

This means we can simply export a full list of customers from PostHog and import them to two separate lists (one for Newsletter, one for Array), each with two segments (one self-hosted, one cloud). Users will be able to unsubscribe from each list in the relevant email (Mailchimp requires this anyway). Ahead of each newsletter/array, we can safely repeat this process to ensure we're working with the latest customer data, without creating resubs which annoy customers. We'll also be able to use the segments to target specific messages.

We've made all the decisions this RFC was intended to solve, so I'm going to close it now. I'll get the lists created and communicated this week (probably tomorrow), documenting the various workarounds in the handbook.