SitecoreAI Component Personalization, Part 1: Decision Tables and Rule Design

 

A business owner asks for "a different hero banner for visitors from India." Simple enough. Two weeks later the request has grown: India on mobile, India on desktop, US on mobile, and returning visitors anywhere. Then someone notices that Indian mobile visitors are seeing the generic India banner, not the mobile one. Nothing is broken. The rules are just in the wrong order.

Component personalization in SitecoreAI is built for this kind of requirement: change one component while the rest of the page stays the same. This guide covers the design half of the work, step by step: choosing the scope, defining inputs, building and ordering rules, and configuring variants. Part 2 will cover testing, publishing, activation, analytics, and custom-value governance.

Before you begin

Sitecore documents component personalization as a phased rollout. Confirm it's enabled in your environment before you include it in a delivery commitment.

Prerequisites

Confirm each of these before creating a single rule:

1. Environment availability: component personalization is enabled for your organization.
2. Site implementation: your site setup and front-end integration support it.
3. Visitor data: the profile attributes and conditions you plan to target are actually populated.
4. Component design: you know which component changes and which variants each scenario needs.
5. Fallback experience: you've decided what visitors see when no rule matches.
6. Success measure: the business has agreed on a KPI, such as CTA click-through or form starts.

Item 3 causes the most rework. A country rule is only as reliable as the location data behind it. VPNs, proxies, and network routing all affect it, so treat inferred location as a strong hint, not a guarantee.

How it works

Everything revolves around the decision table, which has three parts:

• Inputs: the visitor data used during evaluation. Each input is a column.
• Rules: rows of comparisons that decide whether a visitor matches a scenario.
• Outputs: the component variant mapped to each rule.

The detail developers most often miss is that evaluation stops at the first match. Rule order isn't a visual preference in the editor. It's part of the business logic.

Step 1: Decide between component and page personalization

Before opening Page builder, decide on the scope.

1. Write down exactly what changes for the target visitor.
2. If it's one component (a message, image, CTA, or content block), start with component personalization.
3. If several parts of the page must change together as one coordinated experience, use page personalization instead.

Requirement	Better starting point
Change only the homepage hero for one country	Component
Change a banner CTA for returning visitors	Component
Use a custom calculated value to pick a banner variant	Component
Change hero, navigation emphasis, and product grid together	Page
Deliver one coordinated page experience to a visitor group	Page

Don't pick component personalization just because it feels more flexible. I've seen teams personalize four components independently, then struggle to explain why a visitor saw a India hero next to a US promotion. When parts of a page must agree, use page personalization.

Step 2: Select the component

1. Open the page in Page builder.
2. Select the component, for example a Page Header or promotional banner.
3. In the component context toolbar, select Add personalization rules to component.
   
   
   

   
   

The decision-table dialog opens for that component.

Rules and variants apply to this component instance only. They don't automatically personalize every component of the same type across the site.

Watch out for page versions

Sitecore documents that component personalization is shared across page versions. Edit the rules in one version and the change applies to the others, including the live version.

A draft version or another language is not a safe sandbox. Coordinate rule changes with whoever owns the live experience.

Step 3: Define decision-table inputs

Inputs define what the rules can evaluate. SitecoreAI supports three types.

Profile data uses attributes already stored on the visitor profile, such as country, city, or channel. Use it when the targeting value already exists.

Input:  Country
Rule:   Country equals IN
Output: India campaign banner

The IN value is illustrative. Use the value format your environment's profile data actually supplies. Check a real profile under Optimization > Profiles before you type any values into a rule.

Conditions are true/false evaluations, either out-of-the-box or custom. "Is this a returning visitor?" is a typical example. Use a condition when the logic already exists as something reusable.

Custom values are JavaScript-based inputs that combine attributes, behavior, and calculated logic into one value, such as high, medium, or low intent. Use them only when profile data and conditions can't express the requirement. Part 2 covers them in detail.

Configure the inputs

1. In the decision-table dialog, open the Builder tab.
2. Select Create new table, or clone an existing table as a starting point.
   
   
   
   
   
3. Choose the input type: Profile data, Condition, or Custom value.
   
   
   
   
   
4. Select the attribute, condition, or custom value.
   
   
   
   
   
5. Configure its details where prompted.
6. Select Save.
7. Use Add column to add more inputs.
   
   
   
   
   

Inputs in the same rule are combined with AND. Country = IN and Device type = mobile means the visitor must match both. There's no OR inside a row. If you need OR, that's a separate rule.

Step 4: Create personalization rules

Each row in the table is a rule.

1. In the first row, select Add.
2. For each input column, choose a comparator.
3. Enter the comparison value.
   
   
   
   
   
4. Confirm the comparison.
5. Select Add Rule to create more rows.
6. Save the decision table when the rule set is ready.
   
   
   
   
   

A regional mobile campaign might look like this:

Country	Device type	Result
IN	mobile	India mobile banner
IN	desktop	India desktop banner
US	desktop	US desktop banner

Rule order is priority

Now consider this order:

1. Country = IN AND Device = mobile
2. Country = IN AND Device = desktop
3. Country = US AND Device = desktop

An Indian mobile visitor matches rules 1 and 2. Evaluation runs top to bottom, so rule 1 wins. Swap rules 1 and 2, and every Indian mobile visitor gets the generic Indian banner. That's exactly the bug from the opening of this post.

The rule of thumb: most specific first, broadest last. When I review a decision table, I don't just check that each row is correct. I check every pair of rows for overlap and ask which one a visitor matching both would see.

Step 5: Configure component variants

After saving the decision table, configure the variant for each rule in Page builder.

1. Select the rule you want to configure.
   
   
   
   
   
2. Choose how the variant starts:
• Duplicate original: start from a copy of the original component.
• Hide component: show nothing for this rule.
• Swap component: replace it with another compatible component.
  
  
  
  
  
3. Update the content and design for that variant.
4. Use the preview control to inspect the result.
5. Repeat for each rule.

Don't forget the original component. It's shown whenever no rule matches, which for a regional campaign is most of your traffic. Review it with the same care as the variants.

Step 6: Save and review the draft

1. Save and close the decision table.
2. Review the component's personalization status.
3. Confirm every rule maps to the intended variant.
4. Confirm the original component still works as the fallback.
5. Preview each variant and check content, layout, links, and responsive behavior.

At this point the personalization is a draft. Saving the decision table doesn't make it live for visitors. Part 2 covers publishing and activation.

Common mistakes

Designing rules before checking the data. If the attribute isn't populated, the rule never matches.

Broad rules above specific ones. The broad rule captures visitors first and the specific variant never shows.

Expecting OR within a row. Columns in a row are always AND.

Treating a non-live page version as isolated. Personalization is shared across versions, including live.

Architect's design checklist

Before handing the configuration to testing, confirm:

1. Inputs are based on data that actually exists.
2. Multiple inputs are intentionally combined with AND.
3. Rules are ordered from most specific to broadest.
4. Overlapping rules have been reviewed in pairs.
5. The original component is a valid fallback.
6. Variants preserve accessibility, responsive behavior, and working links.
7. Page-version implications have been discussed with content owners.
8. The business owner agrees on the target audience and KPI.

A valid decision table can still produce the wrong experience. Walk through visitors who match several rules and visitors who match none.

Summary

Component personalization lets you vary one component without touching the rest of the page, and it's built on three things: inputs, ordered rules, and variants. Most of the important decisions happen before activation. Pick the right scope, confirm the data exists, order overlapping rules deliberately, and give the original component the same attention as the variants.

In Part 2, we'll take this configuration through testing, publishing, activation, analytics, and the operational controls that keep it maintainable.

References

Component personalization