Messaging: Personless email announcement

[joethreepwood]

Messaging

Context

We have a launch for personless events coming up. There's an RFC for it here: https://github.com/PostHog/product-internal/pull/583/files so I won't reiterate

This comm needs to go to all users. It needs to go after the TOS update we're doing - #195 - Personless is also a blocker to other pricing changes which we'll communicate, so we need to get this out in short order. But deadline is TBD.

I have an art request out with @lottiecoxon - PostHog/posthog.com#8248 - which is in production and will feature here.

Requested input

Feedback from @raquelmsmith and @simfish85

Previews

First, rough draft. Details subject to change. Non-final art.

[simfish85]

Looks good to me - assume the \ in enhance_persons is just escaping and won't be in the final copy

[joethreepwood]

Note: Need to add in the TOS update here too.

[joethreepwood]

New version also include TOS news. CC @fraserhopper and @charlescook-ph

Still not final art or links.

[joethreepwood]

Now featuring the world's fattest pig

[andyvan-ph]

• I don't "added a new event type" is correct. Afaik, direction of travel is events are just events, and we're giving people more control over what data is collected. Something like "We're giving you more control of data collection and, good news, it makes PostHog up to 12x cheaper..."

• I think your original final para was better. This one makes it seems like the blog is about our terms.

[camerondeleone]

Looks good! Just one small suggestion

it makes PostHog up to 12x cheaper, depending on your volume

I think you can get rid of "depending on your volume". "up to" already covers that and could read a little overly caveated.

[joethreepwood]

[raquelmsmith]

nit: I don't think we normally capitalize posthog-js.

[raquelmsmith]

I don't think we should call it a "new event type." It should be more around:

We've split our costs up so you can fine-tune your bill. Now getting advanced person data like person properties and UTMs for never-identified traffic is optional and separate from our event costs.

[joethreepwood]

Yep, this terminology was all rough until we had a name. Will respin it tomorrow now we know it's person profiles (since we at least want to use that name specifically).

…

On Mon, 15 Apr 2024, 21:13 Raquel Smith, ***@***.***> wrote: I don't think we should call it a "new event type." It should be more around: We've split our costs up so you can fine-tune your bill. Now getting advanced person data like person properties and UTMs for never-identified traffic is optional and separate from our event costs. — Reply to this email directly, view it on GitHub <#196 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUA6UKPOZOSR23OPHGVUDSTY5QYGPAVCNFSM6AAAAABGG6MFB2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJXG4ZDEOBRG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[corywatilo]

IMO both this announcement and the blog post explain the how but not the why. To me we're missing the story that connects the two.

I went ahead and wrote up a blurb to try to explain why we're doing this. Feel free to use here, in the blog post, or ignore entirely.

---

TL;DR: We're making it 12x cheaper to track anonymous users on your website or product by restructuring how we track events.

Most companies track user events in one of two ways (or use both):

• Anonymous tracking (like what Google Analytics collects) - you get basic info like the user's browser, OS, and UTM source
• Identified events (like what PostHog has always offered) - send custom properties (like email, plan, etc) and get a deeper level of insights as a result

Since PostHog began in product analytics, we've only ever offered identified events. This works great for building deep insights, but this per-event pricing doesn't scale with large volumes of traffic (like on a marketing site) where you don't know their email (yet, don't have any custom properties that are worth tracking, and don't get the full value of identifying those visitors.

So today we're introducing an updated event pricing that makes it cheaper to track anonymous visitors. (In fact, if you don't need to identify users, event tracking becomes ~12x cheaper!)

We're also changing how we refer to events:

• All events are now anonymous, and come with basic properties (browser, OS, geo IP, limited UTM properties)
• Enable Person profiles (a new add-on) to get the full power of PostHog events as you've always known them today
  • As an existing customer, we'll enroll you in this automatically, but you can change it at anytime
• Tracking an event + enabling person profiles = the same cost of traditional PostHog events as you've always known them - you won't pay more.

Things you should know:

• You can choose when you want to enable a person profile. A common example of this is when a user signs up (and enters their email), it's a good time to enable their person profile.
• Once a person profile is enabled for a user, you'll be billed for both the (cheaper) event price and for the person profile add-on per-event.

---

Things I tried to hit in the above:

• Why you'd use one vs the other
• "Up to 12x less" is a little disingenuous without directly caveating that it's for anonymous users only, and to use the same product you're used to today, there might not be much difference
• Nomenclature change

[joethreepwood]

Thanks all -- appreciate the feedback. Just to clarify: The final version will adhere more closely to James' blog, reference Persons Profiles specifically, have the correct config option, explain a bit more of the why, link to finished docs, etc. These are all things we've been blocked on until now and I've been sharing these rough drafts to get feedback from the specific people I've tagged as we continue working on this. Apologies if this wasn't clear before!

[joethreepwood]

OK, consider this a first final draft.

After chatting with a few people I think we can drop the caveat around not being able to use data you don't have, and I've tried to bring the why out a bit more.

Nomenclature around the config still seems to be changing, but I'll revisit as there'll be at least one more version.

[robbie-c]

Where does that link to?

It doesn't flow as well but you could say "you may want to use identified_only on your marketing site..." as that's the mode I would expect people to use there.

If we wanted to include the min posthog-js version it would be 1.125.0

[joethreepwood]

Where does that link to?

[joethreepwood]

[joethreepwood]

Now that we're coming up on a louder launch, here's some new suggested copy for the email. CC @raquelmsmith for the approval here.

[raquelmsmith]

If you're like us you probably only need profiles for logged in users, for example. For others you can skip prifiles, track them anonymously in the web analytics beta, and save money in the process. Simple.

Replace with (edits in bold):

If you're like us you probably only need profiles for logged-in users, for example. For others you can skip using profiles entirely and track people anonymously in the web analytics beta. For both cases, you'll end up saving money in the process. Simple.

---

...but if you're curious why we're helping you spend less then CEO James Hawkins

Replace with (edits in bold):

...but if you're curious why we're helping you spend less, CEO James Hawkins

(the less then read very weird in my head, I thought it was a typo at first)

[joethreepwood]

Great, finalized version. I'll look at the blog post next and we can send when that's locked in.

[andyvan-ph]

Missing 'the' before "web analytics beta.

[joethreepwood]

I have rethought this from scratch and introduced some much needed sass.

[joethreepwood]

Slight tweak

[corywatilo]

Honestly, it's like we're allergic to cash.

Feels forced, but take it or leave it.

Anonymous events work by skipping the properties we collect on other, identified events

This phrasing feels awkward and doesn't really tell me what "properties" are, or mean to me.

I might be biased, but check out the copy on the pricing page → explain event types modal. I put a lot of effort into trying to distill it into something digestible. Maybe we can match some language?

*Default for unidentified users only, so you save money without much data loss

This even confuses me and I wrote the explanation on this stuff

[joethreepwood]

Good notes. Let's try this:

[raquelmsmith]

The first line should say "session replay" - remove the plural S from replays.

I don't want to say we're launching a new event option called anonymous events. We've always had tracking for anonymous users, and I feel like that's inconsistent. But we have is new pricing for anonymous events.

We should also avoid using the term personally identifiable information as that's a legal term, PII, and we should avoid that when we can.

What we do is we skip creating a person in posthog for these anonymous events, and that means there are no properties stored for the person.

"Personal data" -> person profiles

[joethreepwood]

The first line should say "session replay" - remove the plural S from replays.

✅

We should also avoid using the term personally identifiable information as that's a legal term, PII, and we should avoid that when we can.

Switching for 'individually identifiable', which matches the pricing page. Feels a bit clunkier, but legal reason is a good point.

What we do is we skip creating a person in posthog for these anonymous events, and that means there are no properties stored for the person.

"Personal data" -> person profiles

I've changed this to 'that data' because I don't think it's useful in the announcement to introduce the concept of person profiles specifically and, if person profiles ultimately are a way of storing this data then referring to the data itself is sufficient. I'd quite strongly like to keep this focused on the use-case and price cut as much as possible, referring to the docs for technicals.

I basically want to avoid letting this become: "There are anonymous events and identified events. Identified events have person profiles, which are a way of storing person properties, which are individually identifiable data that includes email or other custom properties. Anonymous events skip the person profiles, so don't have person properties, though they do keep some non-customizable data which isn't individually identifiable, such as device and location. Also, anonymous events are cheaper." 🤣

I don't want to say we're launching a new event option called anonymous events. We've always had tracking for anonymous users, and I feel like that's inconsistent. But we have is new pricing for anonymous events.

Tried to clear this up. I personally feel it's a little less clear now, but happy to defer

[joethreepwood]

OK. It's now the new default, so here's some quick copy.

What we learned last time, partly, was that we'll move faster if we don't try to massage and include all the technical detail in the email. So, here's a version optimized for speed.

[simfish85]

Looks good - not a huge fan of the Oh Crap but maybe it's on brand?

[raquelmsmith]

Looks good! As an aside - this isn't an immediate drop for people, because previously-made person profiles will still have events be "identified" even if the person was never "identified." So it'll be more like a slow slide as previously-seen users are replaced with new users. I don't think we need to call that out but I'm calling it out just in case you want to call that out.

[joethreepwood]

Slight tweak to the language, and also an FYI that we'll send this only to users who match our 'recently engaged' segment (i.e have signed in during the last 4 months) in order to protect our deliverability. I think this classes as a service update, so it'll go to all users regardless of subscription preference.

Everyone seems happy and the copy changes aren't major, so I'm scheduling this in to send on Wednesday, 11th Dec 11AM London time.