Difference between product analytics and web analytics

[andyvan-ph]

Summary

Explainer on the difference between these two. We could do this several different ways. This could be in docs or the blog, but I think it should be mostly focused on the difference within PostHog rather than generally.

Headline options

• Product analytics vs web analytics
• What's the difference between product and web analytics?
• How are product and web analytics different?

What (if any) keywords are we targeting?

n/a

Will it need custom art?

• [ ] Yes
• [x] No

Outline (optional)

[ivanagas]

Because there isn't a lot of search traffic, this should probably be a docs page. Some potential points to cover:

• The definitions and basic insights included with each
• How each developed (GA vs Mixpanel/Amplitude?), short history of both
• What type of users uses each (marketers vs product managers), how to pick the right one for you
• What type of decisions they use each to figure out, what scenarios you should rely on each

[andyvan-ph]

• How each developed (GA vs Mixpanel/Amplitude?), short history of both

If it's going to be docs, I feel like we should stick to referencing PostHog specifically, surely? I think this would be a distraction.

@bijanbwb, it's probably worth you sharing an outline of your thinking before getting too deep into the writing. Whatever the structure is, the main takeaways for a reader should be:

• Understanding the different concepts
• Things you can only do in product analytics and vice versa
• When to use web analytics and when to use product analytics

[bijanbwb]

Thanks for the heads up. You're right I should have put together an outline before diving in and writing the content. I'll definitely do that for future posts.

Outline

• Intro
  • Context: PostHog's goal is to help devs build successful products ➡️ successful products require insights derived from real-world usage ➡️ Web Analytics and Product Analytics are two ways to collect insights from this data.
• Audience
  • I was thinking we could write this without assuming the reader has experience working with both web and product analytics.
  • Or that most devs have some idea of how to collect analytics data but not necessarily the questions these numbers can help answer.
• Web Analytics
  • This seems like the better place to start since Web Analytics is more straightforward. Then Product Analytics will come afterward since it's a broader set of features.
  • What are the questions that Web Analytics help to answer? What are the actionable insights?
    • Example: PostHog has 9 different products on the homepage. How would we find out which are most popular. This might be a good place to add a whimsical example of launching a fake new subproduct and answering the questions below.
    • Which pages are most visited (using URL paths)?
      • Time to double down on what's working well.
      • Time to stop working on building that feature no one wants.
    • How many visitors are using mobile, tablet, and desktop?
      • Time to fix that broken mobile experience.
    • Where are the visitors located geographically?
      • Time to add that Portuguese translation.
    • Where is traffic coming from (referrers)?
      • Time to send a thank you card to X.
  • When to use
• Product Analytics
  • Who is it for?
    • Product engineers
    • Product managers
    • Marketing teams: take inspiration from how our marketing team uses PostHog dashboards
  • Background on events, identities, funnels.
  • Use the questions at the bottom of the features section of /product-analytics for examples.
  • Use the customer stories at /product-analytics for benefits.
    • YCombinator: autocapturing events.
    • Hasura: onboarding funnel.
    • Contra: session replays.
  • Use the jobs to be done section from the Product Analytics team page to add higher level use cases.
  • Caveats: Ideal for high-growth startups as opposed to niche, indie projects.
• Outro

Alternative Structure

After sketching out the outline above, I realized there's an alternative structure that might work well too. With the above outline it basically covers Web Analytics and then Product Analytics one after another.

• Intro
• Web Anaytics
• Product Analytics
• Outro

But an alternative structure might be to start with questions or jobs-to-be-done, and then show how to utilize the different features available to come up with solutions.

• Intro
• Question: How do I...? Web Analytics
• Question: How do I...? Product Analytics
• Question: How do I...? Web Analytics
• Question: How do I...? Product Analytics
• Outro

[andyvan-ph]

Thanks for the heads up. You're right I should have put together an outline before diving in and writing the content. I'll definitely do that for future posts.

It's fine. We don't always do this, it's just useful in this case.

• I was thinking we could write this without assuming the reader has experience working with both web and product analytics.
• Or that most devs have some idea of how to collect analytics data but not necessarily the questions these numbers can help answer.

Yeah, 100% this.

Web Analytics

• This seems like the better place to start since Web Analytics is more straightforward. Then Product Analytics will come afterward since it's a broader set of features.
• What are the questions that Web Analytics help to answer? What are the actionable insights?

This makes sense to me. As much as possible, the product analytics section should follow the same structure.

Product Analytics

• Who is it for?

  • Product engineers
  • Product managers
  • Marketing teams: take inspiration from how our marketing team uses PostHog dashboards

I think we should avoid going down the "product analytics / web analytics is for these people". The usage stuff shows people use both. Best to stick to the use cases, like you're planning, than focus too much on the "this is designed for X type of person".

But an alternative structure might be to start with questions or jobs-to-be-done, and then show how to utilize the different features available to come up with solutions.

I think this could work well as a kind of FAQ at the end, but TL;DR your basic outline looks fine to me.