Harmonizing the PostHog I/O story in docs and product marketing: CDP, Data Warehouse, Data pipelines, sources, destinations, oh my

[daniloc]

We're shipping our org chart, and it's left the PostHog I/O story a little muddled. It's fixable.

This issue captures the current gripes and provides a forum for further discussion. Pending any strong demands, I'll be taking a pass at refining this story in docs, at minimum.

State of play

@timgl:

I originally moved away from CDP to data pipelines because CDP is a term that people who have used a CDP before know, but that most of our customers probably wouldn’t 11:12 data pipelines is more prescriptive 11:12 but CDP is the term in the industry, so more applicable for SEO articles

Yours truly:

Okay so the hierarchy is:

1. The feature is data pipelines, and we refer to it accordingly
2. Conceptually, this provides the benefit of a customer data platform, and if you already know what that means, we will reassure you that data pipelines will give it to you
3. Invoke “customer data platform” in ancillary content for SEO purposes

This yielded a PR which, among other tasks, renamed the product marketing label from "CDP" to "Data pipelines."

Later, @annikaschmid notes:

No idea which one is the right channel for this, so posting it here. We have two new “data in” sources, Chargebee and Revenuecat. Currently, those are not very discoverable on the website, outside of the changelog. I think we should add both to our current “sources and destinations” library on the CDP page, and somewhere in the docs we should also explain how the revenuecat integration works, even if we don’t manage it. People can use it to send data into PostHog, after all. We don’t have a “data in” page in Data Pipelines, so maybe in the “Sources” area of data warehouse? :thinking_face:

@corywatilo observes we do not have an API to auto-populate sources as they come online, unlike destinations:

this should live in CDP as sources. we’re getting the destinations via the api automatically, but there’s no API for sources yet so we have to manually add those. will try to get to this in the next few days.

@oliverb123:

I feel like distinguishing between “push” sources that users configure somewhere else (like revenuecat) and “pull” sources that users configure in posthog is important (i’d call “push” sources something like “3rd party integrations” or something?)

Proposing docs harmonization:

I guess my vague understanding of “where can i get data from and send it to” is, from a customer perspective, we have: In:

• 3rd party integrations they configure elsewhere and we mostly don’t maintain
• migration scripts, which we support, I guess?
• data warehouse sources, that they configure in posthog and we sell as data warehouse
• SDKs Out:
• batch exports, which they configure and we sell as part of data_pipelines but data warehouse (really tomás) maintains
• realtime destinations, which they configure and we sell as part of data pipelines, and CDP maintains
• I think even just a docs page laying that set of things out explicitly would be a good first step. (edited)

@andyvan-ph:

Right now, any CDP destinations that are created get added to that CDP page automatically, but data warehouse sources don’t We also have a bunch of destinations that aren’t documented atm, some are old, some are very recent. Generally, the story we’re telling here is kind of confusing. We have our own internal borders between products and teams, but users don’t / shouldn’t have to care about this. They just want to know if they can get their data in or out.

And later, @bijanbwb on product marketing "integrations":

I wonder if it might be a good idea for us to create an integrations page. Or possibly something that just links to /docs/frameworks or /cdp? I tried Googling "posthog integrations" expecting that there are probably a lot of people wondering "Does this work with WordPress/Stripe/Slack/etc?" and the first few results point to our /apps page, a customer.io page, and our /services page.

What comes next

Olly's plan of attack makes plenty of sense to me: give an overview page with an exhaustive discussion of all PostHog I/O options.

Additionally, we should add a sources section in the data pipelines docs. Right now it has only destinations. I'll experiment on both of these angles this week.

Finally, @bijanbwb's point about "integrations" from an SEO perspective is astute. We should make sure we're in a position to capture people using that language as well.

What else? Chime in below and perhaps team marketing will make your (I/O) dreams come true.

[daniloc]

Additional vision on CDP enhancements from @oliverb123:

https://github.com/PostHog/posthog/issues/25566

[andyvan-ph]

Ollie's issue adds some useful context, but I'm still a bit unclear about exactly what we're doing next?

Can we break this down into specific tasks and maybe add a bit more meat on what where want to end up?

Atm, I'm a bit worried we'll do a bunch of work and then someone will chime in with a totally different take!

[daniloc]

@andyvan-ph oh as my Monday Brain comes online I remember that in consultation with @ivanagas, that decomposition happened as several drafts:

https://github.com/orgs/PostHog/projects/107/views/1?filterQuery=cdp+love

[andyvan-ph]

ah, cool, ok. Ok, in that case, I'd suggest creating a new mega-issue and just breaking all this down by to dos. a bit like we have here for web analytics stuff: https://github.com/PostHog/posthog.com/issues/9500

then we can close this issue down and just focus on shipping the low hanging fruit

[daniloc]

by your command!

https://github.com/PostHog/posthog.com/issues/9878