What should you measure once your app is live?

Your app works, takes payments (chapter 5) and lives on your own domain (chapter 6). Before you tell anyone about it in chapter 8, set up measurement. A launch day can’t be measured afterwards: if the script isn’t on the page when the post goes out, the visits it sent are gone.

This chapter is for both paths. The setup differs in one step, and each path gets its own instructions below.

The minimum, and nothing more

Most analytics tools can show you dozens of reports. For a first app you need four answers:

1. Where visitors come from. By source (a site, a newsletter, a search engine), not only a total.
2. Who signs up. How many clicked your signup button, and which people they were.
3. Who pays. Which of those people became paying customers.
4. Which of your posts worked. Two posts on the same site look the same unless the links are tagged.

Everything else can wait until you have enough people to compare. What to track first explains why these come first; this chapter is about setting them up.

Step 1: Tag every link you share

A tag is a few parameters added to the end of a link. The three to always use are utm_source, utm_medium and utm_campaign (Google’s guide to campaign URLs says the same). For example:

https://yourapp.com/?utm_source=reddit&utm_medium=social&utm_campaign=launch
https://yourapp.com/?utm_source=newsletter&utm_medium=email&utm_campaign=launch

Three habits save you trouble later:

• Write values in lowercase. Google’s guide notes that values are case sensitive, so reddit and Reddit show up as two different sources (Google Analytics Help).
• Keep a list of every tagged link and where you posted it: a spreadsheet with the date, the place and the link is enough.
• Tag only links you share, never the links between your own pages, or a visit that arrived from a post will look like it started on your site.

UTM parameters covers each tag and when to use utm_content as well.

Step 2: Add analytics to every page

Choose an analytics tool that reads UTM tags, can count a button click as a goal, and can link a visitor to a signed-up user. Many can; check before you pick one. Some AI builders already count visits, but not all of them read tags or follow a visitor to a signup.

On the AI-builder path (Lovable, Bolt, v0, Replit, Base44): each builder has its own place for a script and its own publish step. Follow the page for yours under AI builders. Each one says what the builder already measures, gives a prompt to paste, and lists the exact publish step.

On the coding-agent path: the script goes in the layout that every page shares, once, so it loads on every page including the ones you add later. Ask your agent rather than guessing the file:

Add this analytics script tag to the <head> of the layout that every page
of this site uses, exactly as given, once. Don't load it twice and don't
add any other tracking. Tell me which file you changed.

<paste your script tag here>

Then deploy, the same way as in chapter 6.

Step 3: Count signups, and know who signed up

A signup has two parts, and you need both.

• The click, as a goal. Mark your main signup button so the click counts. Most tools do this with an attribute on the button or a line of code; ask the builder or your agent to add it to the main signup button only.
• The person. Right after a signup succeeds, call your analytics tool’s identify function with the user’s id and email. That links this person to the visit, and the source, that brought them. The details, including the version that runs on your server, are in how to connect a signup to its first visit.

Also save the first visit’s source on the user record in your own database (the D1 table from chapter 4, or your builder’s). Your database keeps it even when a browser clears its cookies.

Step 4: Connect payments to people

When your app creates a customer in Stripe (chapter 5), put your own user id in the customer’s metadata, under a key you keep the same every time, such as user_id. Stripe’s docs give this as the example use of metadata: storing the user id from your own system on a Customer object (Stripe metadata). With the user id on the customer, a payment can be matched to the person, and through them to their first visit, even if they pay with a different email.

If a tool needs to read your Stripe account to do that matching, give it a restricted key rather than your secret key. A restricted key carries only the permissions you give it (Stripe API keys), so a key with read access alone lets a reporting tool read without being able to charge anyone.

Step 5: Test it with one tagged visit

Don’t trust the setup until you’ve seen it work:

1. Open a private browser window, so you arrive as a new visitor.
2. Visit your live site with a test tag, for example https://yourapp.com/?utm_source=test&utm_campaign=setup.
3. Click through two pages, then sign up with a test email.
4. Open your analytics. You should see the visit with source test, the goal on the signup button, and the test user linked to that visit.

If nothing shows up, check these first:

• The script isn’t on the live site. View the page source of the published site, not the preview, and look for the tag. On the AI-builder path, the change often isn’t live until you publish again.
• Your domain isn’t listed. Some tools only count visits from the domains you’ve added. Add both your builder’s address and your own domain.
• You tested through a VPN. Some tools leave out visits from data centres, which is where many VPNs run. Turn it off and try again.

Once the test works, delete the test user or note its email, so it doesn’t count as a real signup.

With Nordva Launch

Launch covers steps 2 to 5 with one script tag and a Stripe connection. Insights shows the tag with your site id filled in, and you list your domains on the same card. It reads UTM tags and ?ref= on the first page, and counts a click on any element with data-nordva-goal="signup" as the goal signup (the shorter data-nordva-signup does the same). After a signup, nordva('identify', { user_id, email }) links that person to their first visit. The setup card says “Your first visit is here.” when your test visit arrives, usually within a minute. Launch leaves out known bots and visits from data-centre networks, so a VPN test may not show.

Connect Stripe from Insights with a restricted key: Launch reads it with GET requests only, and disconnecting deletes every synced row. When you connect, you can name the metadata key that holds your user id (for example user_id), the key you set in step 4. Launch then matches a payment to a first visit in this order: nordva_visitor_id in the customer’s or subscription’s metadata, the user id you sent with identify() found under that key, the email you sent with identify(), and last the email on your waitlist. Every plan can connect Stripe; on Free it reads 30 days of history and syncs every six hours, and paying customers are grouped by referring site and by country. Grouping them by UTM campaign or source needs Builder. Free includes 10,000 analytics events a month, with no time limit and no card.

If your builder’s own analytics already answers where visitors come from and you don’t take payments yet, you don’t need a second tool. Add one when you need to know which post brought the people who paid.

With measurement in place, you’re ready to tell people: chapter 8, launch it.