I don't think the solution to dropping conversion rate is to just add more CTAs, especially in a sensitive place like docs. The use case for docs is for technical visitors to understand how something works. This demographic is extremely sensitive to marketing tactics, and I strongly believe that if someone reading tech docs wants to sign up, they'll find a way. (You could compare this with how we have black CTAs. Typical marketing best practices would say to not use black for CTAs, but I'm less concerned with it because we run a B2B product with largely technical people - we're not optimizing for the "drunk" user in a B2C product where we'd definitely optimize everything we can for conversion.) I understand this ideology may be atypical - I just see so many other ways we can optimize for long-term goodwill with user and potential users.

We earn more goodwill by keeping docs focused and not trying to optimize for conversion within them.

On the topic of the "Was this page useful?" buttons... while I don't believe the count is actively monitored, collecting the data is useful as, when someone has some time to optimize docs (which we might do with an upcoming hire), they can use this data to surface the more problematic pages and solve them. (Agreed that Squeak! can help with this though, once fully implemented.) That said, do we have enough data already? Maybe.

Thanks Cory. I actually strongly agree with you on all of this, which is why the idea was solve this via the footer and not by affecting the content or structure -- I feel this is suitably out of the way and that a footer CTA like this isn't going to be so marketing-y as to deter anyone.

Another solution I've considered is taking the docs content off the product pages. That would mean the technical users who (as you say) want to understand how something works can still find content aimed at them in the usual place, while the (potentially non-technical) users who are in an earlier stage of the buying process aren't funnelled towards technical content that's not written for them. I'm less keen on that solution as it's taking content away from technical users and decreasing the value those pages offer.

Would like to hear other thoughts, but definitely happy for this to be an idea we don't pursue if we feel docs are better as they are.

My take is that Joe's solution is very far from 'optimizing for conversion' - it genuinely gives users a useful next step without having to do annoying navigation and backtracking to get started.

Here are a couple of examples from companies who are at least considered to be extremely successful devtools. GitLab have a pretty unobtrusive footer with genuinely useful information, while Twilio keep the nav bar persistent so you're always one click away from getting started. Both examples to me are very far from BS marketing conversion optimization.

• I think this would be too low down in the page to make a meaningful difference. Once your factor in additional page depth created by Squeak, it's unlikely most users will scroll this far down to interact with it. Sadly we don't do scroll depth tracking, or "genuine" heatmapping to see how often they do. Maybe we dig up interaction on the current buttons to guage visibility?

• I'd be strongly in favour of something like the Twilio persistent nav bar. I think this would solve the deadending / make it easier for people to get back into "the funnel".

• I'd be strongly in favour of something like the Twilio persistent nav bar. I think this would solve the deadending / make it easier for people to get back into "the funnel".

Yeah, we mentioned this in Sprint and definitely works for me too -- but I defer to Cory there as the Docs already has one persistent nav and I'm not sure if we can/would want to double stack it.

it genuinely gives users a useful next step without having to do annoying navigation and backtracking to get started.

The next step for much of our docs (probably most by page) is usually not "get started" for an existing user. It's probably "go back to the product to make this feature work better / try out this plugin / something very specific".

I think the best solution to removing dead ends would be creating customized CTAs (or just links inside the doc) to send them to app-specific urls like https://app.posthog.com/insights/new or https://app.posthog.com/project/plugins, etc.

These URLs are not the same for self-hosted users so we'd need to do something clever to detect this and then not show these.

There are specific pages where a CTA of get started may make sense, but they're limited in numbers.

The next step for much of our docs (probably most by page) is usually not "get started" for an existing user. It's probably "go back to the product to make this feature work better / try out this plugin / something very specific".

I agree with this, definitely - but I think the conflict comes because we generally push potential users to the docs too, for example via the product pages.

I think the best solution to removing dead ends would be creating customized CTAs (or just links inside the doc) to send them to app-specific urls like https://app.posthog.com/insights/new or https://app.posthog.com/project/plugins, etc.

These URLs are not the same for self-hosted users so we'd need to do something clever to detect this and then not show these.

Funnily enough this is something I was discussing with Paul in Iceland as a potential hackathon project, so that we could leverage it for plugins/apps. Now that you've reminded me I'll put a feature request in, as that's definitely going to be the best solution. The CTA could be something like 'Try this out', directing existing/logged-in users to the relevant area of the product and encouraging potential users to sign-up.