What happens when you flip a project from setup to live, and why nothing is stored before that.

Every project starts in setup status. The last step of onboarding is a button that moves it to live. That switch is the single most important thing to understand about how LaunchPulse handles your data.

Nothing is stored until you go live

While a project is in setup status, events are never stored. The collector accepts them, routes them to the debug stream so you can watch them arrive in the test view, and then drops them. No pageviews, no conversions, nothing lands in your reports.

Data collection begins the moment you press Go Live.

This is decided server-side, by project status. A client-side debug flag cannot change it in either direction — you can’t sneak real data in before going live, and you can’t accidentally discard data after. The status is the authority.

The reason is simple: while you’re wiring up the tracker you’ll fire test events, reload the page thirty times, and probably send your conversion event with junk data. None of that belongs in your numbers. Setup mode gives you a real, live feedback loop with no cost to your data.

Before you press it

Go Live is the end of step 6, the “Test your signal” view. Use it. Open your site in another tab and walk through the actual journey. The checklist should light up green:

Pageview — confirms the tracker is installed and initializing.
Your conversion event — confirms your app is sending the event name you configured.
Your first-value event — confirms the aha moment is instrumented.

Watch for the two warnings the test view raises:

Warning	What it means	Fix
First value arrived before conversion	The order is inverted — usually the two events are mapped backwards	Swap the event names in your config, or fix which one your app sends where
First-value event has no `user_id`	`identify()` wasn’t called before the event fired	Call `identify()` at login or signup, before the first-value event

If you configured “just watch traffic for now,” a green pageview is all you need.

What can block Go Live

Sometimes the button is replaced by a blocker. There are three:

You need an active subscription. The blocker links to subscribe.
Confirm your email first. Check your inbox for the confirmation link.
Arc is still provisioning — shown as “setting up analytics.” Your project’s storage is being created. This resolves on its own; wait and refresh.

Clear the blocker and the button comes back.

After you go live

Events start being stored immediately. Your Pulse dashboard begins filling in, ordered by the three layers: traffic, conversion, activation. See What is LaunchPulse for the model.

You don’t need to change the snippet. It’s the same key, the same code — only the server-side status changed.

Local development stays out of your data

After going live, the tracker automatically enables debug mode on local hosts. Events from these hosts go to the debug stream instead of your stored data:

localhost
0.0.0.0
*.local
127.*
10.*
192.168.*
172.16.* through 172.31.*

So your own npm run dev sessions won’t pollute your numbers. This is automatic — you don’t configure it.

Staging is the trap

A public staging domain is indistinguishable from production. staging.yoursite.com isn’t a local host, so the tracker has no way to know it isn’t real. Traffic from it counts as real traffic.

If you have a public staging or preview environment, opt in explicitly:

LaunchPulse.init('lp_pub_yourkey', { debug: process.env.NODE_ENV !== 'production' });

Anything with debug: true goes to the debug stream and is never stored. Adjust the condition to whatever your build actually sets — the point is that only your real production build should run without debug.

Note the asymmetry: debug: true can keep data out, but it can never bring data in while a project is in setup status. Project status wins.

What’s next

Installation — per-platform snippets.
Quickstart — the full onboarding path.

Going live