Closed joethreepwood closed 4 months ago
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 πΊ
@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:
First week (excluding those above) are:
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)
Email 2: 4 days after signup (without ingesting events)
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)
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?
@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 π )
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.
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.
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
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)
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)
π―π―π― 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.
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.
(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:
(This is from a 100% dry legal perspective btw - I'm not coming at this from an explicitly commercial or product experience angle)
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.
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:
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!
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!
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:
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:
Is this issue intended to be sprawling? Consider adding label epic
or sprint
to indicate this.
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:
Thanks for this Joe...
My 2 cents on the questions above, @liyiy may have other thoughts.
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?
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:
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.
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: