We had @Shane Roach on Live with Intelligems 💎 last week and I keep thinking about one thing he said: "60-80% of your homepage traffic is new visitors. But most brands have one homepage built for everyone, which means it's really built for no one." Shane's take: you need two experiences. One for new visitors. One for returning ones. New visitors need to be sold. Hero product up front. Brand story. Reasons to buy. Multiple add-to-cart entry points. Returning visitors already know who you are. They don't need the brand story again. They need a fast path to a PDP or collection page. Shane spent years in physical retail before ecommerce. Nordstrom's suiting department, specifically. While the tailor was measuring a customer in a $1,000 suit, he'd go grab shirts and ties, show them how six combinations work, stack the add-ons before the credit card came out. That's merchandising. That's also exactly what a well-designed homepage should do. My pushbask was: "it's hard enough to maintain one homepage." Shane's response: the new-visitor version is set-it-and-forget-it. Revisit seasonally when imagery or hero products change. It's not a live maintenance burden. The other insight worth flagging: you can't control all the traffic entry points to your homepage. Paid? Sure, send them to a landing page. But organic traffic, social shares, a friend dropping your URL via text all of them land on the homepage. That's why the homepage itself has to do this job. The execution: - Build the new-visitor experience - Run it as an A/B test targeted to new visitors only - If it lifts, turn it into a personalization - Revisit seasonally Full stream linked below. Shane covers this plus a speed run on what Intelligems is shipping right now. What's your homepage strategy for new vs returning? Curious if anyone here has tested this split and what you found.

Attached is what a rigorous CRO workflow looked like at my old agency a few years back. Every step had a dedicated human. Research, ideation, technical feasibility, documentation, design, coding, QA. If anyone was slow or busy, the whole thing stalled. And this is assuming the team actually had time to go through all of it — sometimes you had to cut corners just to keep the program moving. Last week @Victor Paytuvi and I went live to talk about how much this has changed. Full replay here if you missed it: How AI is Reshaping Ecomm Optimization Workflows — Live with Intelligems A few things that came up: - Automated test reporting was both of our first real AI use case (~2023). The mechanical part of writing up results doesn't need a human. That time goes back to strategy. - Prototyping with AI closed the communication gap between CRO strategists and designers. Days of back-and-forth became hours. - AI-coded variants are no longer science fiction. One practitioner at Jones Road is running his entire program solo today. We also talked about what won't change: the contextual judgment that comes from knowing a brand deeply, its customers, its history, what's keeping the founder up at night. That's still on us. Curious where this community is at. What's the first step in that process you stopped doing manually?

It blows my mind how many companies run experimentation without a naming convention. Not an imperfect one. None. Tests called "homepage revamp" or "Q2 pricing," somewhere in a spreadsheet or just inside Intelligems, with no structure, no ID, no way to find them six months later without scrolling through 40 rows trying to remember what was actually being tested. And I think it's a hard way to scale an experimentation program. The fix is simple: give every test a unique ID and a structured name before you do anything else. The ID part is what I'm most emphatic about. Something as simple as #1, #2, #3. Or more structured: EXP-23. Looks bureaucratic. Feels unnecessary on your first few tests. But here's what I noticed when I was on the agency side: stakeholders started referencing the IDs in their own conversations. Instead of "that price test from March," they'd say "test 47." That moment, when a client uses a test ID unprompted in a meeting, that's when you know the program has actually landed. They're thinking in experiments now, not in one-off projects. It just makes everyone's lives easier. Stakeholder updates, Slack threads, QA handoffs, everything gets cleaner when there's a shared shorthand. And when you need to iterate on a test, same hypothesis, new variant, you just add a suffix: Ex47a, Ex47b. No confusion, no "wait, which version of that test are we talking about?" Beyond the ID, a naming structure worth trying: 'Ex[#] | Surface | Short Name | Date' Example: 'Ex47 | PDP | Anchor Price Removal | May 2026' The best part: this is trivial to auto-generate with a formula in whatever tool you're using, Notion, Airtable, Google Sheets. One formula column that builds the name from your existing fields. You fill in the surface and a short description, the ID increments automatically, and the full experiment name writes itself. One line. You know what number it is, where it ran, and what changed. A year from now you can look back across your test library and actually see patterns, which surfaces you've tested most, which hypotheses keep winning, where you've put a lot of effort with not much to show for it.

My take: the concern is valid, but "therefore stop testing" is the wrong conclusion. The criticism has a legitimate core. The testing industry has been slow to reckon with acquisition costs. If your test "wins" on conversion rate but the winning experience makes your CAC worse, you might have won nothing — that's a real blind spot. But every single change you introduce might affect your CACs; stopping to measure their impact is not a solution. What's actually going on in most cases: paid media and on-site testing run on completely different clocks. Meta sees a 5% CAC shift and someone acts that day. A valid on-site test usually needs weeks of traffic. They're measuring different things in different places, and when paid wobbles during a test window, it's easy to blame the test. But there's something many people miss: if your numbers hurt a little while the test runs, but you walk away knowing something you'll use for the next 6, 12, 18 months... that's not a loss. That's the cost of learning something real. A temporary CAC spike that teaches you the right price point is a bargain. What I'm curious to hear from you: - Have you seen any true correlation between running tests and CAC spikes? What did you do about it? - Has this changed how you structure your program at all? - How are you handling this conversation with stakeholders? Our gut says the CAC impact is probably overstated... but that's not always how it reads in the room. How do you navigate that?