EN
Ihor Nikolenko- Why a Website Is a Chain of Human Decisions
- Sales Blocks: What They Actually Are
- Cookie Consent: Why "Accept All" Doesn't Cut It Anymore
- Server-Side Conversions: So Your Ads See Your Real Sales
- A Regular Website vs. a Website on NEO: The Difference in One Table
- What Changes for the Owner from Day One
- The Short Version
- Frequently Asked Questions
The site is built. It looks great, has animations, the designer is proud of it. Then the ads go live — and silence. The Google Ads dashboard shows clicks, analytics shows visitors, but there are no leads, or half as many as actually came in, because nobody counted half the form submissions. The owner concludes "the ads aren't working," when really it's the site that isn't working: it was built like a storefront window, with no path to a purchase inside it.
I've been seeing this since 2008, in different costumes. The technology changes, but the mistake stays the same: the site gets designed starting from a picture, when it should start from the decision a person has to make. New rules of the game have piled on top of that too — cookie consent requirements, ad blockers that eat conversion data, and AI-based assistants that read sites instead of people. A generic website-builder template doesn't account for any of that, and the gaps get patched after launch, once the money is already spent.
I built NEO as an answer to that mistake: a platform where the site is a sales-focused chain of blocks from the start, and cookie consent and server-side conversion tracking are built in on day one, with no bolting things on after launch. This article covers why each of these three things matters to you specifically, and what changes when they're there from day one.
Why a Website Is a Chain of Human Decisions
A person arrives at a website standing on a particular rung of awareness. They might only sense they have a problem, might know solutions exist, might already be comparing you to someone else, or might be ready to pay. Ben Hunt described this as a ladder, and his central point is simple: a page works when it meets the person on their rung and moves them up exactly one. Not three — one.
That implies a design requirement: every screen on the page should either prove an advantage, remove a doubt, or move the person forward. A screen that does none of the three is dead weight, no matter how beautiful it is. In this logic, design isn't the goal — it's a way to make the decision easy.
When a site is built on a generic builder, the designer gets a blank canvas and fills it by taste. When a site is built from blocks, each with a purpose in the chain, the canvas is already structured: first the promise, then the facts, then removing fears, then the terms, then the next step. It's harder to get it wrong.
Sales Blocks: What They Actually Are
NEO has several dozen block types, and each one answers one question a person has at a specific rung. Here's how that looks in practice, without the names used in the admin panel:
- The first screen answers "where did I land, and is this for me" within three seconds: the outcome, the condition, who it's for, one button.
- A facts-and-benefits block answers "why should I trust you" — with numbers, documents, and timeframes, not adjectives.
- A "without us / with us" comparison closes off fears. On the left, what actually happens when someone handles it themselves; on the right, what you do. No third parties, no scare tactics.
- Process steps answer "what happens after I click the button." Uncertainty is the biggest thing holding people back, and a simple list with dates and who's responsible removes it.
- Terms and documents — for people who've almost decided and want to see payment terms, guarantees, the contract.
- Questions and answers — a place for every objection that didn't fit above, and it also makes the page more legible to search and to assistants.
- An offer with a timer or limit — for when there's a real deadline: an enrollment window, a batch, a promotion. Real, because people spot a fake countdown and leave.
- The form and the "thank you" page — not the end, but the next rung: what happens next, when to expect a reply, what to check out in the meantime.
One rule I apply on every page: one block type appears once. Two facts blocks in a row are really just one blurry block. The specifics get sorted into different types — terms go into terms, steps go into steps, fears go into the comparison. That's what makes a page read like a conversation.
And one more thing: the blocks are multilingual by birth. The same chain can be shown in Ukrainian, English, German, or Polish, with correct URLs and links between the language versions — that matters if you sell abroad, and it's painful to bolt on after the fact.
Cookie Consent: Why "Accept All" Doesn't Cut It Anymore
Plenty of people treat the cookie banner as a formality — you put it up so nobody bothers you about it. But behind it stand two real things: the law and your data.
The law is GDPR for visitors from Europe, and similar requirements elsewhere: analytics and advertising cookies can only be set after consent, declining has to be as easy as accepting, and you need to be able to prove that consent was given. A banner with only an "Accept" button doesn't legally protect anyone.
The data side is Google's Consent Mode v2. It's a mechanism that feeds your tags a signal: did the person allow analytics and advertising, or not? Without a correctly configured consent mode, Google limits personalized ads and measurement for audiences in the European Economic Area. In other words, a banner without Consent Mode means your ad budget is partly flying blind.
In NEO, the banner, the consent mode, the consent log, and the page where a person can change their decision are one built-in system. Analytics and pixels only fire after permission is given, every consent is logged, and when a "show me what I agreed to" request comes in, there's something to show. This is the part of the job nobody likes doing by hand, which is exactly why it's almost always done badly.
Server-Side Conversions: So Your Ads See Your Real Sales
A classic pixel lives in the visitor's browser. And that's exactly its weakness: ad blockers won't let it fire, browsers cap the lifespan of its cookie, a person without consent has turned it off, and a slow site doesn't finish loading it before the click. The result is that your ad account sees only part of the conversions and optimizes on incomplete data. You pay for clicks while the algorithm learns from half the reality.
Server-side tracking solves this differently: the site sends the lead event to advertising systems straight from its own server — to Google Analytics 4 via the Measurement Protocol, to Meta via the Conversions API, to Google Ads as enhanced conversions, and to TikTok, LinkedIn, and Microsoft through their own server-side interfaces. The browser pixel can stay in place as a backup, and both channels send the same event ID so the event doesn't get counted twice.
In practice, that means: your ad algorithms get more complete data and find similar people more effectively; you see the true cost per lead; the data from the form the person already gave you enriches the event in ways a browser pixel simply can't. And all of it operates within the consent that was actually given — server-side tracking doesn't get around the law, it gets around technical losses.
In NEO, this whole loop is a built-in module: traffic parameters are preserved from the first visit through to the lead, events go straight to advertising servers, and the admin panel includes a check for whether a test event actually reached each platform. The indicator shows fact, not intent — that's the principle I use to verify every system I build.
A Regular Website vs. a Website on NEO: The Difference in One Table
| What | A website builder or template | A website on NEO |
|---|---|---|
| Page structure | A blank canvas, assembled by taste | A chain of blocks matched to the awareness ladder |
| Cookie consent | A checkbox banner or a plugin with no log | Consent Mode v2, a consent log, a page to change your decision |
| Conversion tracking | Browser pixels | Server plus browser with deduplication |
| Languages | Manual page duplication | One structure, multiple languages, correct links between versions |
| Search and assistants | Whatever the template gives you | Sitemap, structured data, a file for language models |
| Form spam | A captcha, or nothing | Domain checks, honeypots, rules in the admin panel |
| "My data" requests | Handled manually by email | A dedicated page and request-handling process |
This doesn't mean you can't do good work on a website builder. You can — by bolting on every row of this table separately, with plugins and by hand, and then maintaining it after every update. The only question is whether that's the job you actually want.
What Changes for the Owner from Day One
The biggest difference isn't technical, it's managerial. When the structure is defined by blocks, you fill in the site instead of designing it from scratch every time. A brief, some copy, some images, and the page comes together following clear logic; rearranging a block or adding a language is an admin-panel task, not a new brief for a studio. That's exactly why I build a basic NEO site in a week — from brief to ad launch, with consent and server-side conversions already configured. You can see how that works on the "NEO Website in a Week" page.
The second difference isn't felt on launch day — it's felt once the ads go live: the ad platforms see the leads, you see where they came from, and budget decisions get made on real numbers. What exactly is built into the platform and how it's licensed is on the NEO platform page.
The Short Version
- A website is a chain of human decisions; every block either proves an advantage, removes a doubt, or moves the person forward.
- Sales blocks impose a structure where it's harder to go wrong: promise → facts → fears → terms → next step.
- One block type appears once per page; specifics get sorted into their own separate blocks.
- A cookie banner without Consent Mode v2 and a consent log doesn't provide legal protection and leaves your ads without data.
- Browser pixels lose part of your conversions; server-side tracking with deduplication gives your ads the full picture back.
- Multilingual support, structured data, anti-spam, and data-request handling should be part of the platform's core, not plugins.
- When the foundation is built in, the owner fills in the site instead of redesigning it for every change.
Frequently Asked Questions
Can an existing website be migrated to NEO?
Yes, and it's usually more of a rethink than a copy-paste: the copy and images move over, while the page structure gets rebuilt around the block chain. This step is often exactly where it becomes clear why the old site wasn't selling.
Do I need a developer to work with the blocks?
No. Blocks are assembled in the admin panel from fields: heading, text, image, button. A developer is only needed for non-standard integrations.
Are server-side conversions a way around cookie consent?
No. Events are only sent within the permission the person actually gave. The server addresses technical losses — blockers, browser limits — not legal ones.
Can NEO be used across multiple websites?
Licensing terms are described on the platform page, along with what's included in support and updates.
