- What should the leads table actually store?
- The address in lowercase with a unique index on it, the timestamp, and the provenance: which page, which campaign parameters, which referrer, which variant if you are testing. Add a column for the consent you obtained and the exact wording that was shown when you obtained it. Anything you collect and never use is a liability rather than an asset, so decide what question each column answers before you add it to the form.
- How do I stop spam without putting a captcha in front of people?
- Three cheap layers get most of the way. A hidden field that humans never fill and bots usually do; a check that the form was not submitted within a second of loading; and a rate limit in the worker keyed on the source address. Reject silently rather than explaining what tripped, and log the rejections so you can tell an attack from a broken form. Save the interactive challenge for the day the cheap layers stop holding.
- Should submissions go to my database or to my email tool?
- Both, in that order. Write the row first, respond to the visitor, then forward to the marketing platform. If the forward fails -- an expired key, a provider outage, a rate limit -- you still have the lead and can replay it. Doing it the other way round means an outage is indistinguishable from nobody signing up, and you find out days later when the campaign report looks strange.
- Do I need double opt-in on a waitlist?
- It depends on where your audience lives and what you plan to send them, so treat it as a decision rather than a default. What matters technically is that consent is a stored fact: the timestamp, the wording displayed, the checkbox state, and the confirmation event if you use one. Deliverability improves as a side effect, because a list of confirmed addresses bounces less, and bounce rate is what governs whether your later emails arrive at all.
- How do I keep campaign parameters attached to a signup?
- Capture them on first arrival and hold them, because the visitor who converts is often not on the page they landed on. Read the campaign parameters and referrer at entry, keep them in storage for the session, and attach them to the submission as hidden fields. Without that, every signup that involved a click to a second page attributes to your own domain, and the channel that actually worked looks like it did nothing.
- Will a generated landing page rank in search?
- It can, with a caveat worth stating plainly. The page is a client-rendered single-page application: the title, description, and canonical link are set, but the copy is assembled by JavaScript rather than served as complete HTML. Search engines do render pages, though not instantly, and there is no automatic sitemap. For paid traffic, social, or a link in a newsletter this is irrelevant. If the entire plan is organic search, budget for pre-rendering.
- Can I run an A/B test on the page?
- You can build the split -- two variants, an assignment stored so a returning visitor sees the same one, and the variant recorded on each submission. Whether you should is arithmetic: at a hundred visitors a week, a small difference in conversion needs months before it separates from noise, and calling it early is worse than not testing. Test large changes on real traffic, and change small things on judgement.
- What makes a landing page slow, and does it matter here?
- It matters most on a phone over mobile data, which is where a lot of paid traffic arrives. The usual culprits are full-resolution images scaled down in the browser, a font that blocks the first paint, and an animation library imported for one effect. Pages serve from the Cloudflare edge, so distance is not your problem; payload is. Check what the hero image weighs before you check anything else.
- How should form validation and errors be handled?
- Validate in the browser for speed and on the server for truth, and never let the second one be optional. Return errors keyed to the field so the interface can show them where they happened rather than as one message at the top. Preserve what the visitor typed on a failed submission -- clearing a form because an address was mistyped is a self-inflicted conversion loss, and it happens most on the small screens where retyping is worst.
- What should happen after someone signs up?
- Something that confirms it worked and sets an expectation: what they will receive, and roughly when. Whether that is an inline state or a separate route matters mainly for measurement -- a distinct confirmation route is trivially trackable, an inline swap needs an explicit event. Pick one and instrument it, because the conversion you report is whatever you decided to count, and a page with no confirmation event has no honest number.