CDP polish

[oliverb123]

The shiny new CDP is fully released, and in customers hands, but we have a lot of things we should and could do to polish it, some of which is fairly low hanging fruit, and some of which is more engineering effort. This issue is me jotting down everything I can think of, and others should feel free to add to it.

Low hanging fruit:

• We should probably get rid of the last section on this page - we've had some bad feedback about it during a customer interview (it basically looks complicated, and makes posthogs CDP look complicated and bad), and it's a setup we really don't recommend people adopt, so documenting it is maybe more trouble than it's worth
• This page has problems
  • I don't think the feature preview notice on it is accurate anymore? If it is, we should take this out of feature preview.
  • We should have screenshots here! It's all so theoretical, and seeing some of this UI requires users to activate an addon they might be unwilling to turn on before knowing it's worthwhile (even for users where their bill is 0, activating add-ons is a friction point)
    • I'd actually like users to be able to play with this ui, up to and including modifying testing a function, without activating data-pipelines, but that's a heavier lift.
  • We should probably have an overview "how to create a realtime destinations" page that goes step by step and is more of a story and less of a data dump, with the final section being "how to modify the code" that then branches off to hog docs etc.
  • We should mention the filtering stuff - users maybe take it for granted, and maybe don't, but it doesn't hurt to mention
  • We need to update the limitations - currently we say we only allow 2 fetch calls, but we allow 5.
• This page also has problems
  • The notice box warns against confusing hog and hogql, only for us to immediately describe them as syntax-compatible. As a dev, that's confusing to me.
  • That same "Quickstart" section is almost exclusively about the limitations of hog imposed by this compatibility, and is the topline of the page - we should be giving a code example and brief explanation first (something like grabbing the webhook template, annotate it with comments, and then walk through whats happening below). The first real thing (that isn't fluff) we say about hog to most users is how weird and constrained by SQL-like syntax it is!!!! Crazy!!!
  • From that section, we immediately go into a syntax explanation - again, still no full-destination example! What will my hog code look like!
  • The "why hog" section should be a separate page entirely, it's shoved at the bottom (after a giant list of the STL functions, with no actual docs for each function!!). Sure, we link to it at the top, but it deserves its own page (or a blog post, really, so long as we can reliably link to it).
  • That giant list of STL functions should have real docs! We just point at the python __init__, which is really not good enough.
  • As a dev reading these docs, I'm confused. Does hog have real types? What are they? Why can toUUID take any and always successfully return a UUID? Is UUID a special hog type, like String or Tuple? These are questions the docs should preempt
• This page should be much "sexier", the screenshot is meh and the "25+" is massively underselling a totally programmable destinations system

More expensive, pie in the sky stuff:

• I want my hog functions to be version controlled, and I want to be able to diff two versions.
• I want to see how long my function takes on average (and p99) to run, how long the fetch calls it makes take, and how often they fail (even if the overall call succeeds, I want to know about retries). I also want to know how much data they send and receive. All this broken down by hog function and, preferably, endpoint (or at least domain).
• In the posthog destinations UI, I want to be able to hover over the input variable and see a list of it's properties, if known (I know for events this varies, but for any variable where it doesn't, I want to see on hover). Also, what is with this autocomplete suggestion?

• I want to be able to use a github copilot style LLM to help me write my hog code, which means it needs to know all about hogs funky syntax, 1-indexing and STL, and also know about the shape of the events I'm getting in as inputs (push all this into prompt context before generating a result suggestion? idk)
• I want to be able to write hog code locally, feed it an event (that I grab from posthog in some easy way, in the shape CDP is given events), and watch it run.
  • I want a language server my IDE can use to give me syntax highlighting for that hog code.
  • I want to be able to step debug my hog code

[corywatilo]

I'll let @ivanagas assist with docs content updates here.

This page should be much "sexier", the screenshot is meh and the "25+" is massively underselling a totally programmable destinations system

Feel free to share content you'd like to see there. @joethreepwood is planning to do some work on content which I'll then add to the product page when it's ready.

Also FYI, the destinations are pulled in from the API, but the sources are currently hard-coded as there doesn't appear to be an endpoint for them yet. If we want to add transformations here, let us know if we should do the same as sources or if there will be an API for transformations anytime soon.

Other things

• Rename the "Data pipelines" nav (in app) to "CDP" to match
• Chore: Change /pipeline/ path in product to /cdp
• New icon (probably a plug) - @corywatilo
• Add a "New..." button on the CDP overview page

And, in trying to set up a Slack message in the CDP UI last month, I ran into some UX things that I had sent Ben (that I'm assuming haven't been addressed). Not sure if they're still valid but will leave em here:

(I can try to repro above and give steps if useful.)