Conversion Rate Optimization for Developer Tools

Your website’s job finishes earlier here than the funnel report implies. Somebody reads a page, decides the tool is worth ten minutes, and leaves for a terminal. Everything that decides the account happens after that, and none of it is a page view.

The steps that decide it are not page events

Install. First successful call. First call from an application instead of a curl one-liner. First deploy to something that is not a laptop. First call made by a second person on the same team. That is the moment a trial becomes an account, and it is invisible to every tool that watches a browser.

So instrumentation comes first, and it lives on your side. Events emitted by the API, the CLI and the package, carrying the same identifier the website already sets. The elapsed time between each step is recorded. Until that exists, a testing programme here is polishing the half of the funnel that can be seen and guessing at the half that pays.

Two people are converting and one of them never reads your site

An engineer picks the tool. Somebody with a budget approves it later, sometimes months later, often without opening the quickstart at all. Two funnels, one domain, and they want opposite things from the same page. One wants the install command above the fold and no form. The other wants a page about data handling, a document they can forward to a security reviewer, and a contract.

Serving both from one homepage is how a homepage ends up saying nothing to anybody. The work is splitting the paths early and reporting them apart. That also stops a rise in signups hiding a fall in the pipeline that actually closes.

We reconcile your analytics against your servers before testing anything

This audience is the hardest one in software to measure from inside a browser. How large your particular gap is cannot be guessed, only measured. So we measure it. Server-side request counts against client-side event counts, same pages, same week, and then we look at the ratio together.

If the gap turns out to be wide, every historical test result you hold is suspect. A client-side testing tool is then the wrong instrument for the rest of the programme. If it turns out to be narrow, we carry on and say so. Either way the finding arrives before a decision gets made on the numbers, which is the only time it is worth anything.

A docs site is not a landing page and should not be tested like one

The documentation usually carries the traffic. The people in it have already installed the thing and are looking up an argument name. Pool that with the evaluation pages and you get a conversion rate that describes neither group and that swings whenever your support load swings.

There is a second problem underneath it. Docs are built by a static site generator out of a repository. A third-party testing script then has to be injected into a page whose speed is the reason people tolerate it. That script is slow, this audience blocks it at a rate you have not measured, and the variant you are testing loses on latency alone. Variants belong in the repository behind a flag, which is how the main service runs anyway and is simply mandatory here.

The demo gate question

Putting a form in front of the quickstart is a change we push back on. An engineer evaluating a tool at eleven at night will not fill in a form to find out whether it does the thing. They close the tab and open a competitor’s docs, and that loss never appears in any report you own.

If the business genuinely needs a sales conversation, the gate goes after the first successful call. At the point where the tool has already earned the question. That is testable, and it is one of the few tests on a site like this with enough volume behind it to finish.

When the arithmetic says do not run the test

Tests need conversions, not visitors. A site with heavy documentation traffic and a modest number of signups a month cannot power a test on the signup page. The pageview total will keep suggesting otherwise. We do that arithmetic in front of you before anything gets built. Below the line, the work is fixing defects, watching real installs and reading the support channel, and it gets quoted to you as exactly that.