Conversion teardown

What to track on a pre-launch waitlist page

A teardown of AEONNN's early-access page: how it is built, and what I would measure on a page like it before sending launch traffic to it.

Why does a waitlist page need its own measurement plan?

A waitlist page gets one real test: launch week. Traffic arrives in a burst from a few places, most visitors come once, and a week later it's quiet again. Whatever you didn't measure that week, you can't measure afterwards.

Default analytics don't help much here. A waitlist page has no product to use, no pricing page and usually no thank-you URL. The one action you care about, someone leaving an email, happens inside the page. Pageviews tell you how many people came, not who asked for access, where they came from or what they read first.

AEONNN's page is a good one to work through: carefully built, clearly pre-launch, and fresh from its launch week. AEONNN launched on ProductsFarm, a weekly launch board, in the week of November 2 to 8, 2026, and finished #2 Product of the Week with 88 upvotes. Below is what I would measure on a page like it. I don't know AEONNN's numbers and won't guess them.

How is AEONNN's early-access page built?

AEONNN calls itself an AI-powered longevity-intelligence platform, with the tagline "Where longevity becomes intelligence." It turns scattered goals, routines, supplements and self-reported signals into one personal view over time, and wearable and lab data can add to that profile. It isn't open yet: the page collects requests for Private Early Access and a Founding Membership, with no prices shown.

Here is the structure, top to bottom:

• A short intro. On the first load of a visit, a short logo animation plays, with a Skip button.
• The hero. The headline, "Biology is not episodic. It is continuous.", one paragraph on the product, and the email form under "Be among the first AEONNNians".
• The argument. Five labeled sections: The signal beneath the noise, The realization, From information to continuity, A different philosophy of optimization, and Why continuity matters.
• The product. What AEONNN is, with three cards: Pillar Matrix (ten connected pillars), Stack Builder (personal supplement guidance) and Insight Protocol (why items matter and how they are prioritized).
• The payoff. The value compounds, then "Every continuum has a beginning." and the same form a second time.
• After the form. The request is confirmed in place, with an optional question: where do you see yourself beginning, Origin or Evolution?
• The footer. A plain statement that AEONNN is informational and non-prescriptive and does not diagnose, treat, cure or prevent disease.

It does several things well. The form sits at the top and the bottom, so a visitor the headline convinced doesn't have to scroll, and one the argument convinced doesn't have to scroll back. The follow-up question comes after the request, so it costs no signups and still tells the team something about intent. And the voice holds from the first line to the last, which is hard on a page this long.

Why does a long narrative page need scroll tracking?

My position: the longer the page, the more scroll tracking matters. On a short page, people sign up or leave, and a conversion rate tells you most of what you need. A page that makes its case over seven labeled sections asks for a reading commitment, so the useful question is where readers stop.

If most visitors never reach What AEONNN is, the Pillar Matrix, Stack Builder and Insight Protocol are invisible to them. That might be fine. It might also mean the product rarely gets its turn. Only a section-by-section count tells you which.

The two forms give you a second reading. Hero requests come from people the promise convinced. Closing requests come from people the whole argument convinced. If the closing form does real work, the narrative earns its length. If nearly every request comes from the hero, I would test a shorter version.

I would mostly ignore bounce rate here. On a one-page site, reading everything and leaving is a normal visit.

What would I measure on each part of the page?

This is the plan I would set up before launch week. It reads best with the page open in another tab: aeonnn.com.

Two things are missing from that table on purpose: email addresses, and anything a person might say about their health. An event should record which form was used, not who used it. AEONNN publishes a Consumer Health Data Privacy Notice right under its form, and your analytics should be just as careful.

How do you track a form that never leaves the page?

AEONNN's form confirms in place, like most waitlist forms. With no /thank-you page, a setup that only counts pageviews never sees a single request. You need an event that fires when the request succeeds, not on click, or every mistyped email counts as a signup.

In AnalyzeUser that is one line in the form's success handler, and one in its error handler:

// After the request is saved, not on click
window.analyzeUser.track("early_access_requested", { form: "hero" });

// When it fails
window.analyzeUser.track("early_access_failed", { form: "hero", reason: "invalid_email" });

Buttons and sections need no JavaScript. A click on an element with data-au-event records that event, and a scroll goal records an event the first time a section comes into view:

<button data-au-event="tier_selected" data-au-prop-tier="origin">Origin</button>

<section data-au-scroll="read_what_aeonnn_is" data-au-scroll-threshold="0.3">
  ...
</section>

One catch: by default a scroll goal fires when half the section is in view, and a section more than two screens tall can never be half in view. Long sections on a phone hit that easily, so use a lower threshold for them or put the attribute on the heading. The event docs cover the rest.

Once the first real request is recorded, pick early_access_requested as the Main goal in Project settings. It gets its own cell beside your headline numbers, with its conversion rate.

Where did the launch-week signups come from?

Launch traffic comes from several places at once: a launch board, a newsletter, a post on X, a community thread. Each needs its own label, or the requests blur into one number.

Some launch boards do part of this for you. ProductsFarm adds utm_source=productsfarm and utm_campaign=launch to every link to a product's website, so those visits keep their label even when the referrer is dropped. Tag everything you post yourself the same way. AnalyzeUser lists tagged visits by source, medium and campaign in its Campaigns panel, and the free UTM builder makes the links.

Then build one funnel: a visit to the home page, the What AEONNN is scroll goal, then early_access_requested. Its By source tab shows how many visitors from each source started and how many finished. A source that sends many visitors and few requests looks very different from one that sends a few and converts most of them, and a visitor count alone hides that.

During the week, add a chart note on launch day ("Launched on ProductsFarm") so the spike explains itself later, and turn on the Traffic spikes and Tracking stopped alerts, by email or in Slack or Discord, so a broken deploy doesn't quietly cost you a day of data.

Afterwards, watch the AI channel. AnalyzeUser counts visits from ChatGPT, Perplexity, Claude and Gemini as their own channel, so you will notice if people start finding the product by asking an assistant.

What should you do with the numbers after launch week?

• Compare the two forms. If the closing form brings in a real share of requests, keep the length. If it brings almost none, test a version that reaches What AEONNN is sooner.
• Find the steepest drop between scroll goals. Tighten or move that section, not the whole page.
• Count the follow-up answers. The share of people who pick Origin or Evolution at all is a fair read on how engaged the list is.
• Keep each request's source in your own list. Save the visit's utm_source with the email, so when the Founding Membership opens you know which channel each member came from.
• Connect payments when memberships go on sale. AnalyzeUser reads Stripe, Dodo Payments, Lemon Squeezy and Razorpay and puts each sale next to the source of the visit that led to it. Tag the invite emails too, so those clicks aren't counted as direct. More in the revenue attribution guide.

AEONNN's page already does the hard part: it says something specific in its own voice and asks for one thing, twice. The plan above just makes sure that when launch traffic arrives, you learn which part of the page did the work.

Try AnalyzeUser free for 7 days

Paste one script tag, add an event to your waitlist form, and see which launch source sends requests, not just visitors.

Frequently asked questions