Rule Engine

Rule-Based Control
for Web Output

Define what should happen, where, and when — without changing your backend. Everything in NinjaWeb5 is built on a single model: a rule.

Core Concept

Everything Is a Rule

Every transformation, personalization, and control action in NinjaWeb5 follows the same four-part model. You don't write code — you describe behavior. The engine does the rest.

WHEN
↓ triggers on
Trigger
When does the rule activate? On every HTML response, on a specific request type, or on a defined event in the delivery flow.
WHERE
↓ conditions match
Conditions
Where does it apply? Match on URL, path, geo, device type, headers, query parameters, or any variable in the request context.
DO
↓ action executes
Action
What should happen? Modify HTML, inject content, remove elements, bind dataset values, block scripts, or rewrite metadata.
WHY
↓ order & logic
Priority & Logic
How is execution controlled? Set priority, define conflict groups, and manage execution order when multiple rules apply to the same response.
Rule Anatomy

Four Parts. One Rule.

WHEN

Trigger

The event that activates the rule. Defines the moment in the request-response lifecycle when the rule is evaluated.

Trigger types
  • On HTML response received
  • On incoming request
  • On URL pattern match
  • On specific event in flow
WHERE

Conditions

The context in which the rule applies. Conditions filter which requests and responses actually trigger the action.

Match on
  • URL path or pattern
  • Request headers
  • Geo — country or region
  • Device type — mobile / desktop
  • Query parameters or variables
DO

Action

The transformation applied to the HTML response. Each rule defines exactly one or more actions that execute on the matched content.

Actions
  • Modify or replace HTML element
  • Inject content or block
  • Remove element or attribute
  • Bind dataset variable
  • Rewrite metadata or title
WHY

Priority & Logic

Execution control. Defines how this rule interacts with others — which runs first, which overrides, and how conflicts are resolved.

Control options
  • Priority score — 1 to 1000
  • Conflict groups — mutual exclusion
  • Execution order — sequential or parallel
  • Stop-on-match logic
Example

What a Rule Looks Like

Each rule is a structured declaration — not a script. You define behavior in plain terms. Ninja executes it at the edge, for every matching request, in real time.

Rule: inject-promo-banner
Active
WHEN
trigger html_response · fires on every HTML page response
WHERE
url contains "/product" AND geo = GB
DO
inject_before ( selector: "body > main" , content: "promo-banner-uk.html" )
WHY
priority 100 · group banners · stop-on-match: true
Execution

How Rules Execute

Step 01
Request arrives

A request reaches the edge. Ninja evaluates the request context — URL, geo, device, headers.

Step 02
Rules matched

All rules with matching conditions are identified. Priority is evaluated. Conflict groups are resolved.

Step 03
Actions applied

Matched rules execute their actions in order — HTML is modified, content injected, metadata rewritten.

Step 04
Output delivered

The transformed response reaches the browser. Rules are invisible to users — only the output changes.

Scope

Types of Rules

The same rule model applies across every domain. One engine, four categories — everything flows through the same WHEN → WHERE → DO → WHY structure.

🏷️
SEO Rules

Rewrite title tags, inject schema markup, modify meta descriptions, and manage canonical URLs — in real time, per page.

SEO Layer →
🛡️
Security Rules

Block third-party scripts, enforce content policies, detect risky markup, and filter response headers before they reach the browser.

Security Layer →
🎨
UI Rules

Inject banners, change CTAs, modify layout, and personalize the user interface for any segment — without touching source code.

UI Layer →
🧪
Experiment Rules

Define A/B variants, assign traffic splits, and run experiments on any element of the page — launched instantly, paused the same way.

A/B Layer →
Rule Builder

Built for Humans,
Not Just Developers

Rules are defined through a structured visual interface. No IDE, no terminal, no deploy pipeline. Product managers, growth teams, and marketers can build and activate rules — without writing a single line of code.

  • Visual field-based rule builder
  • Structured dropdowns — no free-form syntax
  • Preview output before activating
  • Activate or pause with one click
Rule Editor
Preview
History
WHEN
html_response — fires on HTML pages
trigger
WHERE
URL contains  "/pricing"  ·  geo = GB
conditions
DO
inject_before  →  "body > main"  ←  promo-uk.html
action
WHY
priority: 100  ·  group: banners  ·  stop-on-match
logic
Use Cases

What You Can Control with Rules

01
Change SEO metadata

Rewrite title tags, inject schema markup, modify Open Graph tags — per URL, per segment, or dynamically from a dataset. No CMS access needed.

02
Block or control scripts

Prevent third-party scripts from loading, reorder script execution, or enforce a content security policy — at the edge, before the browser parses the page.

03
Personalize content

Show segment-specific CTAs, geo-local pricing, and audience-matched messaging. Bind dataset values to variables and deliver them in real time.

04
Run experiments

Define A/B variants as rules. Set traffic split logic. Launch the experiment instantly — no staging, no deploy, no developer required.

05
Modify UI on the fly

Inject a promo banner, replace a hero image, hide a section, or change a button label — with a single rule, active within seconds of being saved.

06
Validate before production

Run any rule as a dry-run. Preview the output against a real page before activating. Confirm the result — then ship with confidence.

You don't write code.
You describe behavior —
and the edge executes it.
Why Rules

Traditional Logic vs Rule Engine

DimensionTraditional ApproachNinjaWeb5 Rule Engine
How behavior is defined Hardcoded logic in backend or frontend Declarative rules — WHEN, WHERE, DO, WHY
Who makes changes Developers — every change needs a code edit Anyone — product, growth, marketing
Time to activate Deploy cycle — staging, review, release Seconds — activate in the dashboard
Rollback Another deployment or hotfix required Pause or disable the rule instantly
Scalability Each new condition adds code complexity Add a rule — logic scales without code debt
Visibility Logic scattered across codebase All rules in one place — searchable, auditable
Why It Matters

Why Rules Matter

Faster control

Define a rule, activate it, and the change is live. No sprint, no release, no waiting.

🧩
Flexible logic

Combine conditions, chain actions, and compose complex behavior from simple building blocks.

📐
Scalable system

Add rules without adding code debt. The engine handles scale — you handle strategy.

🛡️
Safer changes

Every rule can be paused in one click. Preview before activating. Zero risk to your origin.

Start Building Rules

Define behavior declaratively. Control output at the edge.
No code, no backend, no deployment.