Onboarding 1.5 emails

[joethreepwood]

Context

Some context here.

In brief, @liyiy asked @lottiecoxon and I to think about re-engagement emails as part of the new onboarding flows, targeting users who have signed up but haven't completed onboarding or ingestion. This issue is to kick off discussion about solutions.

There are some best principles I think we should follow with these emails - clear CTA, defined benefits, don't be spammy - but let's start by looking at how some other companies in our space do this...

Research: Amplitude

Amplitude has the following schedule for coaxing you through their onboarding:

• Initial welcome email on the day you sign-up
• Personal follow-up later that same day
• Personal reminder four days later
• Another reminder three days after that

These personal emails seem to be manually written, but that may not be the case - it's not unheard of to introduce misspellings into automated BDR emails in order to appear more human. It's unclear how they're targeting, but they're trying to drive users towards an upsell path.

This doesn't feel the most appropriate for us as a target - I'd rather avoid hard-sells and focus on giving users actual value/support.

Either way, it's a lot of emails and feels annoying to the user. I'd rather avoid this approach.

Welcome email

First follow-up

Second follow-up

Third follow-up

Research: Logrocket

Logrocket has two flows - one for sign-ups, one for pricing. They're quite similar in message, but the pricing flow is a single email on the day while the sign-up flow is as follows.

• Initial, personal email on the day
• Personal follow up four days later
• Personal reminder after another four days
• And another reminder that same day

These emails are a lot clearer and shorter than Amplitude's.

Signup flow

Pricing email

Proposed timing

Most of the above are focused on getting users to register for a meeting, but my assumption is that that wouldn't be very scalable for PostHog and could involve a big investment of engineering time. They also send a lot of emails, which I think we should avoid. Why annoy users?

Instead, my initial proposal would be that we determine the average time between user signup and the first event being ingested. We then send a single email once this time has been exceeded, or after 24 hours if that time is less than 24 hours. We can optionally consider a second email four days after this.

Open questions

Open to any feedback on this, but the two big questions I'd appreciate context and ideas on are:

• How can we target these emails? Can we send tailored messages based on industry, name, role?
• What do we feel is the best action to push users to? Forwarding to docs feels like a poor solution and I believe 'Invite a teammate is already featured in the flow'. Do we want to create a video explaining how to deploy, or is suggesting a demo call the best solution?

[liyiy]

Amazing write up Joe! I totally agree with you that we should opt for less rather than more right now. Currently we don't have any re-engagement emails so the timeline of a 24 hour followup email and possibly a second one X days later sounds great. I think we should default to an email template for this still instead of automating a "person" emailing you.

How can we target these emails? Can we send tailored messages based on industry, name, role?

Right now we don't track data of what industries or roles our users are from in the flow in favor of opting for a shorter onboarding experience. I'm also not sure we have to make these emails super targeted in the first iteration, perhaps just a simple reminder and general infographic about posthog's capabilities to start the experiment with?

Also tagging @marcushyett-ph for thoughts here 😺

[marcushyett-ph]

@liyiy I agree.

I think we should optimize for self serve and focus the email on those users getting unblocked with setup (rather than booking a demo or chatting to customer success), so something generic that doesn't look like it's a person should work well here. (It would also be super weird if we sent you emails from your own self hosted instance that looked like they were from a PostHog employee)

My general hypothesis for why someone wouldn't ingest events in the first 24hrs are:

• They need help from someone (perhaps an engineer) from their team to ingest events into PostHog
• They started setting up PostHog and got distracted by something else and forgot about it
• They were comparing a bunch of different tools at the same time and got value faster with another tool

First week (excluding those above) are:

• They need more information to make a decision, (e.g. specific feature they need is not available or documented, they're working on competitor comparisons, budget approvals, etc)
• They're still building their product and aren't quite ready to implement tracking yet

Perhaps I'm missing a few use-cases here - but I think for a first iteration we should focus on:

Email 1: 24hrs after signup (without ingesting events)

• Reminder they set up PostHog yesterday and are almost ready to start using our awesome features (e.g. trends, funnels, recordings etc)
• Link to guides for getting setup (and ones explicitly focussed at sending to team mates) with the ability to invite a team mate
• Link to the demo environment if they want to quickly compare what PostHog can do, vs other tools

Email 2: 4 days after signup (without ingesting events)

• Similar to above, with more focus on tutorials and how to do key things with PostHog
• Links to booking a demo with customer success
• Link to get help from us on slack

Potentially out-of-scope for the first iteration - but it's something I've seen be pretty effective in the past, particularly for email 2: avoid sending people emails on weekends, Monday mornings or Friday evenings (as they usually have very low action rates for high effort actions like onboarding)

[joethreepwood]

Nice, sounds like this should be pretty straight forward then.

@liyiy I'm happy to draft these emails this week, if that's helpful? I just need to know how we'd send them. Do I need to build them in Mailchimp, or shall I just share the raw copy here and let @lottiecoxon handle the design?

[liyiy]

@marcushyett-ph sounds great thanks!! @joethreepwood how difficult would it be to set up an email reminder for people who haven't finished onboarding with mailchimp? I assume mailchimp has more to do with marketing campaigning? so we might want to keep this one internal then with our own email delivery service 😃 (so yes, raw copy here, unless this can be easily done in mailchimp, then mailchimp 🐒 )

[joethreepwood]

Mailchimp has an automations service for doing retargeting emails, though it's not something I've looked into before or used with PostHog.

A quick investigation suggests we can automate welcome emails with Mailchimp, including adding some basic If/Else logic and time delay triggers. However, to gate it effectively we'd need a way to automatically add new users email addresses to a Mailchimp audience (we do not have this and currently do it manually, so we'd need to create an app). We'd also need some way to pass product information (has not signed in) over to Mailchimp (probably via the API) and create tags based on it.

Short version: It's possible but not straightforward.

It should be possible to do it with Hubspot instead - we already automate sending user info there on sign-up for @simfish85 and @camerondeleone - though I don't believe we pass over any other usage info. Again though, I'm not super familiar with automation in Hubspot.

If our internal tool is easier to work with and fits the bill, I'd suggest we use that - and I'll get the content done for you this week.

Also, +1 email from Amplitude.

[simfish85]

We can likely do this with HubSpot sequencing which allows for automation based on certain properties being set in HubSpot. This would require updates to our HubSpot ~plugin~ app to actually send the relevant properties but I'm pretty sure that kind of update would be needed regardless of the mail automation solution we chose.

[liyiy]

I think I'm leaning towards sending these emails from our internal system instead so we can be more selective with who we send re-engagement emails to? This is probably do-able with HubSpot too but there'll just be a bit more extra configuration with the plugins etc, though the flip side is that HubSpot will have metrics for us, I'm open to suggestions on this @rcmarron

[rcmarron]

My one concern with sending the emails from our internal system is that these emails (as described above) seem to be more marketing than transactional. As a result, I think we'd want to be compliant with GDPR. This means only sending them to users who've opted in and including the unsubscribe link. With MailChimp, we're going to get the unsubscribe link for free, and I'd assume we have a way of syncing users who've opted into marketing emails with mail chimp already (have to look into this one)

[marcushyett-ph]

From my perspective I think we should make these emails non-marketing if we can. I'd love @charlescook-ph perspective on the potential boundaries here?

The emails we're currently planning are in the legitimate interest of users, i.e. they signed up because they wanted to use PostHog and we're doing what we can to help them achieve that, we will not keep spamming or messaging them after the second email.

I think it can be fairly argued that these emails are necessary for the product to work, as much as you need to send someone an email when you give them an invite.

@rcmarron your point around unsubscribes is interesting (if we do decide to class these as marketing emails, we need to be able to use the existing opt-out list)

[clarkus]

💯💯💯 on @marcushyett-ph's points on emails. We're have a handful of features that are going to rely on email as an interface coming up soon or in-progress now. I think investing in email as an interface for the product is going to be pretty critical for nailing self serve. +1 to spending some hours on figuring this one out.

[joethreepwood]

I'd assume we have a way of syncing users who've opted into marketing emails with mail chimp already (have to look into this one)

There's no opt-in, currently. All users are considered subscribed, as per our TOS. All users are synced to Mailchimp manually using the process covered in the Array email section of the Handbook. Users can unsubscribe once they get an email. This prevents them from being re-added to the list at the next manual update.

Yes, the manual update is a pain and will become increasingly painful.

[charlescook-ph]

(Sorry if the below is obvious, been tagged mid thread so you may already know all this!)

Yep so at the moment anyone who signs up to an account by default is forced to accept our Privacy Policy.

In that, we say:

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. We primarily use our blog to communicate this type of information, so we expect to keep this type of email to a minimum. There's an unsubscribe link located at the bottom of each of the marketing emails we send you so you can stop receiving such emails at any time.

In terms of how the opt in process could be more GDPR-friendly:

• Terms of Service - you have to agree to these
• Privacy Policy - you have to agree to this, but I can change the wording so that we make it clear that opting into emails is actually optional
• Security emails - this is one where we have to send these to everyone - even if someone doesn't want to receive anything from us, we should email them if there is a critical security flaw or we've had a data breach (in the latter case, you're actually obliged to email people under GDPR)
• Product emails - optional but encouraged
• 'Marketing' emails - optional (but I'd call this HogMail, as it's not really marketing)

(This is from a 100% dry legal perspective btw - I'm not coming at this from an explicitly commercial or product experience angle)

[clarkus]

Do we have any content for our specific purposes in onboarding? Specifically we need to send emails when someone is invited, when someone drops off and needs to be pulled back in, and maybe more. We're at the point where we need representative examples of those emails so we can hand them off for implementation.

[joethreepwood]

Here's some initial content for re-engagement emails, as discussed at the top of the discussion. Open to feedback, it's really just a starting point at the moment.

We're at the point where we need representative examples of those emails so we can hand them off for implementation.

I'm happy to help with more content for this, but in order to do that effectively I'd need to understand a few things. Namely:

• What's the communication flow? (What emails, when)
• What's the desired intent? (What do we want everyone to do)
• What content do we have already? (And what's wrong with it?)

Ideally we'd fully map this automated flow out so we can visualise it all. I've seen some horrible cases before where this stuff is built iteratively and nobody has a holistic view of what comms are sent when!

[clarkus]

What you shared is perfect for moving things along. I'll check that out and leave feedback, but more than likely I'll just use it as a starting point for getting design assets together. We don't do anything for this now, so it's a greenfield for improvement. Thanks, @joethreepwood!

[marcushyett-ph]

What do we feel is the best action to push users to? Forwarding to docs feels like a poor solution and I believe 'Invite a teammate is already featured in the flow'. Do we want to create a video explaining how to deploy, or is suggesting a demo call the best solution?

Following up on these questions:

• What do we feel is the best action to push users to? I think the primary action should be to get them back into the product, assuming at least for the first email, they've just forgotten to finish setting up
• Forwarding to docs feels like a poor solution and I believe 'Invite a teammate is already featured in the flow'. If they don't have the skills then docs or team invite seem like the best things to do (we can't be certain and I'm sure we'll want to iterate, if we put UTM tags on all of the links - we can see if they're actually getting clicked and how that influences our decision)
• Do we want to create a video explaining how to deploy, or is suggesting a demo call the best solution? They wouldn't get to this screen without already deploying the product successfully (or Using cloud), we could create a video explaining how to set it up, but the actual instrumentation is genuinely a single copy-paste (if you know what you're doing and have the authority to do it), so a video feels like it actually might slow them down.

[posthog-contributions-bot[bot]]

This issue has 2119 words at 16 comments. Issues this long are hard to read or contribute to, and tend to take very long to reach a conclusion. Instead, why not:

1. Write some code and submit a pull request! Code wins arguments
2. Have a sync meeting to reach a conclusion
3. Create a Request for Comments and submit a PR with it to the meta repo or product internal repo

Is this issue intended to be sprawling? Consider adding label epic or sprint to indicate this.

[joethreepwood]

After chatting this through with @lottiecoxon I've thrown together this map of what I currently understand the email flow for onboarding to be. There are a few outstanding questions this has revealed (marked in red post-its) and a few potentially missing messages (marked as Qs).

The biggest two for me:

• Do we send any emails to users once they have successfully ingested, to help them get started with analysis?
• Do we potentially have a loop where invited colleagues will also get re-engagement emails at different times?

Link to map

[marcushyett-ph]

Thanks for this Joe...

My 2 cents on the questions above, @liyiy may have other thoughts.

• Do we send any emails to users once they have successfully ingested, to help them get started with analysis?
  • I think we should - but its probably out of scope of this first phase of on-boarding, we're really just trying to improve the biggest drop-off which is between signing up and ingesting events first, then we'll move further down the funnel.
• Do we potentially have a loop where invited colleagues will also get re-engagement emails at different times?
  • hmm, this is a very interesting nuance. We should only continue sending emails if no events have been ingested, but it feels fair to send a reminder (or two) to the person who was invited by the first person (and so on) - although the reminder content (as is) might not make quite as much sence for the person who has been invited

[liyiy]

I've left some comments on the map @joethreepwood. As for what's in scope for 1.5 we can just start with the re-engagement emails for now as the main goal is to increase ingestion rates vs increase discoverability and retention with the welcome email (on the radar for 2.0 though!!).

For the issue of the loop of re-engagement emails it seems like most users invite a group of people at once so we'll just send re-engagement emails to everyone until their org has ingested an event. Since it's just 2 emails total per person it probably won't be that spammy?