Set up once. Watch your data grow.

Everything you need to install the tracking script, map your developer journey, and start seeing real adoption data.

Step 1

Install the tracking script

Every Built for Devs account comes with a unique tracking script. Paste it into the <head> of every property developers touch—your marketing site, your docs, your product app. If any of those live in separate codebases or subdomains, the script needs to go in each one. The more of the journey you cover, the more complete your data will be.

It loads asynchronously and won’t affect page performance. Once installed, it automatically tracks developer sessions—page views, time on page, and navigation patterns—without any additional configuration.

Your script tag


                                <script src="https://cdn.builtfor.dev/bfd.js" data-api-key="YOUR_API_KEY" defer></script>

Retrieve your actual script tag with your API key already filled in from your settings page.

Tracking across multiple domains

Your primary domain is verified automatically when the first tracking event fires from it. If developers also visit separate properties—a docs site on a different domain, a subdomain like docs.yourproduct.com, or a staging environment you want to include—you need to register those domains in Settings.

Go to Settings → Tracking Script → Additional Domains and add each domain you want to track. Events from unregistered domains are accepted but not attributed to your account—add every domain where your script is installed.

Get your script →

Step 2

Verify your script is working

After installing the script, visit your site in a browser, then return to your Built for Devs dashboard. The “Last seen” indicator on your project will update within a few minutes of the first event firing. You can also check Settings → Tracking Script → Domain Verification to confirm your domain shows as verified.

If the indicator isn’t updating after 5 minutes, check these common causes:

The script tag is not inside the <head> element, or it was placed after a blocking script that errors
A Content Security Policy (CSP) header is blocking the script from loading—you’ll need to add cdn.builtfor.dev to your script-src allowlist
A browser extension is blocking third-party scripts—test in a clean browser profile or incognito mode
The domain where you installed the script hasn’t been added to Settings → Additional Domains—add it so events from that domain are attributed to your account

Step 3

Filter out internal traffic

Your team visits your own product constantly—testing features, reviewing docs, debugging issues. Without filtering, that activity contaminates your developer funnel data and skews your TTV measurements. Set up exclusions before your data starts accumulating.

IP Exclusions

Go to Settings → IP Exclusions and add your office IP address or CIDR range (e.g. 192.168.1.0/24). Any traffic originating from an excluded IP is flagged as internal and excluded from funnel metrics. If your team works remotely, each team member can add their home IP, or you can exclude by email domain instead.

Email Domain Exclusions

Go to Settings → Email Domain Exclusions and add your company’s email domain (e.g. yourcompany.com). When a developer authenticates with an email matching an excluded domain, their sessions are flagged as internal and excluded from your metrics. This catches team members regardless of what IP they’re on.

Configure exclusions →

Step 4

Define your Time to Value

Time to Value (TTV) is the moment a developer goes from curious to having gotten real value from your product. In the dashboard, it’s measured as the time from a developer’s first session to the TTV event you define.

How to identify your TTV moment

Ask yourself: what’s the first moment a developer has done the thing your product actually does—not signed up, not viewed the dashboard, but genuinely used it? That’s your TTV. It’s the “aha” moment where the value becomes undeniable. For a monitoring tool, it might be the first alert firing. For an API product, it might be the first successful call returning real data. For a deployment tool, it might be the first successful deploy.

If you’re unsure, ask your team: “What’s the one thing a developer does where we know they’re going to stick around?” That’s your TTV event.

Two ways to define it

Go to Settings → TTV Definition and choose one of:

URL pattern—if reaching value lands the developer on a specific page. Enter the URL or pattern (e.g. /quickstart/complete or /dashboard/first-project). The tracking script detects the page visit automatically—no code changes needed.
Custom milestone event—if reaching value happens in the product itself rather than on a specific page. Fire a milestone from your frontend when the moment occurs, then enter that event name in Settings.

Firing a milestone event

Call BFD.milestone() in your frontend JavaScript at the moment the developer reaches value. The tracking script must already be installed on that page.

Example


                                // Fire this when the developer reaches value

                                BFD.milestone('first_api_call_success');

Use a name that’s specific to the moment—then enter that exact name in Settings → TTV Definition. From that point on, any developer who fires that milestone will have their TTV recorded.

Set your TTV →

Step 5

Map your developer journey

Built for Devs tracks developers through five stages: Discover, Evaluate, Learn, Build, Scale. Journey mapping tells the system which URLs and events on your site correspond to each stage.

After installing the script, the platform auto-detects likely journey stages based on your URL structure. Go to Settings → Journey Mapping to review the suggestions, confirm the ones that are right, and adjust any that need changes.

The more accurately your journey is mapped, the more precise your TTV measurements and funnel drop-off data will be. If a stage isn’t mapped, time spent there won’t be attributed correctly.

Configure journey →

Step 6

Get human evaluation sessions

The tracking data shows you where developers drop off. Human evaluations show you why. Once your script is installed and your TTV is defined, you have enough context to make evaluation findings actionable.

How to get started

Go to the Evaluations section in your dashboard and purchase the number of sessions you want. During checkout, you’ll specify your ICP—the type of developer you want evaluated against. Be specific: the tighter your ICP, the more useful the findings.

What to expect

Once your purchase is complete:

We match developers from the network to your ICP and invite them to run a session
Each developer works through your product the way any new developer would—following your docs and onboarding naturally, with the goal of reaching working implementation—while recording their screen and audio
Each session is reviewed, and approved sessions are immediately available for you to watch in your dashboard
Once all sessions are approved, your findings report is automatically generated for the project

Your findings report

The findings report synthesizes all sessions into a single project-level view. It includes an executive summary, a scorecard, critical issues, quick wins, what developers loved, and specific recommendations tied to your developer journey stages. Read it alongside your funnel data—the combination tells you both where developers are dropping off and exactly why.

Purchase evaluations →

Your data

Understanding the dashboard

Adoption Score

An AI-generated score (0–100) assessing your developer-facing presence across five dimensions: Discoverability, Clarity, Onboarding Friction, Build Confidence, and Trust. Scores are classified as Exceptional (85–100), Good (70–84), Needs Work (55–69), or Poor (below 55).

TTV funnel

Shows the average time developers spend in each stage of your journey—Discover through Scale—and where they’re dropping off before reaching your TTV event. Identifies the highest-leverage stages to improve.

Recommendations

AI-generated, specific improvement suggestions based on your funnel data, Adoption Score, and evaluation findings. Surfaced when patterns indicate a clear opportunity for improvement.

Sessions

Individual developer session recordings and timeline views. See how real developers move through your product—which pages they visit, how long they stay, and where they exit.

Evaluations

Human evaluation sessions, their status, findings reports, and full session recordings. Each completed evaluation links to a structured findings report with timestamped observations and recommendations.