How a page is decided.

What gets decided

How it works

Every content decision is made on the server. The browser runs only the consent notice, the beacon, your deferred tags and the live channel. A newly approved rule or piece of targeted content reaches visitors as the platform's servers and cached pages refresh.

Audiences, evaluated

• The grammar. A rule joins its conditions with "all of", plus one level of "any of" and "none of" groups. The operators are at least, more than, at most, less than and equals, with "includes" and "contains" for lists and pages. A missing fact never satisfies its condition.
• What a rule can read as the page is decided. The request's own country, region and city, and the visitor's visit count, plus up to 32 stored facts about the visitor. Only the facts needed by the rules that active targeted content or an active experiment names are read, by name in one keyed read, fresh on every request, and only with personalization consent and a visitor id.
• A campaign's tag, recorded on arrival. The tag a visitor arrived with is recorded as their landing page is served, and every page they open after it can be shaped for that campaign.
• Fail-safe. If the stored facts cannot be read, they read as no facts: those conditions simply do not hold, the page is never broken, and no learned membership is lost.
• Learned audiences. Membership comes from the affinity engine, and each page recomputes it against that audience's own join point.
• A campaign's audience. "Came from this campaign" holds anyone for whom one of its ways in is true: a first arrival tagged with the campaign's key, from any channel (the tag way in reads the visitor's first touch, which is written once); a view of one of its pages since the campaign began; or any condition added on the campaign's page.

Arrangement

• An arrangement moves only Praxis's own sections, among their own positions, and a pinned section keeps its place.
• Sections left unlisted follow in template order, and the header and footer never move. It applies as the page loads, never as a reshuffle of a page already open.

Slot rules

• Each piece starts from its ranking score, and each rule that is switched on changes it in a way you can read on the record: a multiplier for the stage of the buying journey; a freshness bonus that halves over its half-life; a penalty for pieces this shopper has already seen, counted from that shopper's own ring of recent decisions; a ceiling on pieces that share one value of an interest; and merchandising multipliers, clamped together, by default to between half and twice a piece's score.
• Settings live on three rungs, the site, an audience and a slot, and the more specific rung wins field by field.

The five rules and their numbers

Live slots

• The ticket. A page gets a live ticket only when it has a live slot, and the visitor has allowed personalization and has a visitor id. The visitor must already be in the offer's audience, unless joining it triggers the offer. The offer is shown only if the visitor is in its audience when it is sent. The ticket is sealed and must be used within 120 seconds. The page cannot read the visitor id inside it.
• The channel. A WebSocket held by the visitor's own Durable Object on Cloudflare, which rests between messages. The server sends, and the page listens.
• The triggers. Any event type, such as an add to cart, checked against the offer's audience at that moment; or "membership enter", the moment the visitor joins a learned audience.
• What can change. The approved text in the "Live offer" section and its call to action, and whether it shows. A push changes only a slot the open page carries.
• Expiry and erasure. Expiry belongs to the server: an alarm in the visitor's Durable Object withdraws the offer. Every push is signed, delivered once and logged as an exposure. Erasing a visitor closes their live channel.

The decision log

• For visitors who allow personalization and have a visitor id, every decision is recorded as "targeted", "holdback", "deduped" or "default", with an id, the arm, the authority that made it, the versions in force, the drivers that explain it, and the runner-up.
• "Why this?" shows it to your Admins, who can see why any visitor saw what they saw, and "Decide it again" asks whether it would decide the same today.

When there is no consent

• Without personalization consent, every slot serves its default, recommendations fall back to the order you chose, no live ticket is issued, and the affinity engine learns nothing. A visitor in the holdout's default arm also gets every slot's default and the fallback order for recommendations.

Failing safe

• Every step catches its own errors and serves the page without personalization.
• If the affinity engine's store cannot be reached, visitors simply see less personalization; the page itself is never affected.

Machines

• Every version of a page shares one canonical address, and a crawler arriving from an opt-in region sees the default page. Crawlers are decided by the same rules as every other visitor.