Help

Fixing Your Feed Data with Rules

Feed rules are conditions plus actions that clean and reshape your product feed before it reaches your ads — set or remove fields, exclude products, process images, split variants, group products. Edits stay in a draft until you publish.

Updated October 12, 2026

Rules let you clean up and reshape your incoming product feed before it reaches your ads. A rule is a set of conditions plus one or more actions — for example, when a column contains a certain value, set a field, remove it, or drop the product. Your edits stay in a draft and don't take effect until you Publish.

What a rule is#

A rule has two parts: conditions that decide which products it applies to, and actions that change those products' data. Read a rule as one sentence — when these conditions are true, do these actions. A rule with no conditions runs for every product; the editor shows the caption "Always — no conditions, this runs for every product."

Rules live on a catalog's Rules tab. Open a catalog from your project's Catalogs list, then choose Rules.

The Feed columns rail#

On the left of the Rules tab, the Feed columns rail lists every column in your feed — the same rail the Mapping tab shows, described in full in Mapping your feed fields. Two things make it useful while you write rules:

  • Drag a column into a rule. Drop it on a condition or on a value — a Set field value, for example — and it lands where you drop it.
  • Set a column's type here. Click a column's type badge to make it Text, Number, Date or Boolean. The type decides which comparisons its conditions offer (below). It is the same setting as on the Mapping tab, so changing it in one place changes it in both.

Under your feed's columns, Rule outputs lists the columns your rules write. Click one to open the rule — or the ruleset — that writes it.

Conditions: which products a rule applies to#

Each condition compares one of your feed columns against a value. The comparisons available depend on the column's type:

  • Text columns: contains, doesn't contain, is exactly, is not, is blank, is not blank, matches pattern, doesn't match pattern — each with an ignore-case variant.
  • Number columns add the range comparisons: is less than, is at most, is greater than, is at least, is between. A number you type as the value reads the same in every catalog: a dot or a comma is the decimal separator, so 1,50 becomes 1.5 when you leave the box, and 1.000 becomes 1. Thousands separators and units are not read — type 1000, not 1 000 or 12 kr — and the condition says so under it.
  • Date columns compare with is before, is on or before, is after, is on or after, is between, is exactly and is not. You pick the day in a calendar, and the rule compares whole days, the way your feed's date column holds them. To compare with another column instead of a fixed day, click the { } button next to the date. If a date typed there can't be read as a date, Publish stops and names the rule, instead of the rule silently matching no products.
  • True/false columns use is true or is false.

A date condition can also compare with a day counted from today. Click the clock button next to the date (Compare with N days ago instead) and choose a number of days ago or days from now, or today — published is on or after 60 days ago matches products published today or on any of the 60 days before, which is how you label new products. How often such a rule updates, and the other ways to build it, are in Rules that depend on dates.

You can combine conditions in one level of groups — an ANY OF group matches when any condition inside it is true, an ALL OF group when they all are — and join the top-level items with AND or OR.

A rule can read a column your feed doesn't have right now — an earlier rule may create it, or your shop may have stopped sending it. When Renable has read your whole feed and the column isn't in it, the rule card says so in a quiet line underneath: "Reads list_price, which isn't in the current feed". It's information, not an error — the rule still runs, and that column simply resolves to nothing. See Mapping your feed fields for where your feed's column list comes from.

The actions a rule can take#

A feed rule can do any of eight things to the products its conditions match:

  • Set field — write or overwrite a catalog field's value. The value can be fixed text, another column, or a value you build up step by step (see below).
  • Remove field — clear a field's value.
  • Exclude product — drop the product from this catalog entirely, so it never reaches any channel or ad.
  • Process images — process the matching products' images with settings of your own instead of the catalog's: a Categorize images switch (on for a new rule) and background-removal steps, picked exactly as in the catalog's Image processing section on its Settings tab. The rule replaces both — the catalog's own switch and steps no longer apply to those products. Use it to give your best sellers the premium model, to categorize only part of a catalog (switch on, no steps), or to process images for only some products in a catalog that otherwise just forwards its feed's images. With the switch off every image counts as a Product image, so the rule needs at least one step that applies to Product images, or it can't be saved. If more than one rule does this for the same product, the one lower in the list wins. See Image background removal and classification.
  • Split into variants — turn one feed row into several products, one per size, color, or other variant. This is a feature in its own right — see Splitting variants into products.
  • Group products — collect the products that share a group key, then either add values computed across the whole group to every one of them or keep just one product per group. Also a feature in its own right — see Grouping products.
  • Apply ruleset — run a shared, reusable set of rules you maintain on the Rulesets page and apply to as many catalogs as you like. (Rulesets are sometimes called shared or master rulesets elsewhere.) It works like any other action: a rule that applies a ruleset can carry conditions — the ruleset then runs only for the products that match — and one rule can apply several rulesets, which run in order, beside other actions. See Working with Rulesets.
  • Map product fields — write a value straight to a product field (Title, Price, an attribute…) from inside a rule, so it only happens for the products the rule matches. Your mapping is the default for every product; a rule that maps a field wins for the products it matches — and if more than one rule maps the same field, the one lower in the list wins. When a value it maps into a field like Price or Stock count can't be read as a number for one of the products Renable previews, a warning under the action says so before you import — in the same words the import would use.

When a Process images rule can't run. Rarely, a Process images rule saved in an old draft has no Categorize images choice, and Renable can't run it. Rather than guess, the catalog stops importing until the rule is fixed: you'll see a Feed import failing error that names the rule (and its ruleset, if it comes from one). Nothing is added or removed while it stands, but prices and stock stop updating. Open the rule, set the switch, and publish the catalog — or the ruleset, if the rule lives there — and the next import runs normally.

The "Otherwise…" branch#

Every rule has an "Otherwise…" setting that decides what happens to the products its conditions don't match. Its simplest form is "Otherwise, do nothing" — the rule only ever acts on products that match. Open the "Otherwise…" branch instead to add a second set of actions for the products that didn't match, so one rule can handle both cases at once — set a field one way for matching products and another way for the rest. Otherwise-actions can be any action a rule can take: Set field, Remove field, Exclude product, Process images, Group products, Split into variants, Map product fields, and Apply ruleset.

Putting Group products in the "Otherwise…" branch groups the products the conditions don't match, which is how you handle a group key that's blank on some products — see Grouping products. Likewise, putting Split into variants there splits only the products the conditions don't match — "if it's a simple product keep it as-is, otherwise split it into variants" is one rule. Map product fields in the "Otherwise…" branch writes the field for the products the conditions don't match, so "map the title one way for these products, and another way for the rest" is one rule instead of two with mirrored conditions. And putting Apply ruleset there runs that ruleset for the products the conditions don't match, so "apply one ruleset to the matching products and another to the rest" is one rule too.

Rules run in order#

Rules run in the order they appear on the Rules tab, top to bottom, and each rule sees the result of the ones above it. If one rule sets a field and a later rule reads or overwrites the same field, the later rule works from the already-changed value — not the original feed value. Arrange your rules so any rule that depends on another's output comes after it.

When more than one thing writes the same product field#

A product field can be written from more than one place: your catalog's Mapping, a Map product fields action in a rule, and any rule that arrives from a Ruleset the catalog applies. The order is the one above — rules run top to bottom, then the mapping fills in whatever is still empty — so the last rule to write a field wins, and your mapping covers the products no rule claimed.

Each row of a Map product fields action carries a menu for changing that on a single field:

  • Always set — write the value regardless of what came before, replacing it. For a field that holds one value (like Title or Price) this is what a rule normally does, so it's the default there.
  • Only if not already set — write it only when nothing earlier produced a value for that field. This is how you write a fallback rule: if nothing has set the title yet, set it from this column.
  • Add to the list — add your value to what's already there instead of replacing it. Offered only for fields that hold several values (additional images, reasons to buy, product attributes) — and for those, adding is what a rule normally does, so it's the default.

A value that comes back empty never counts as written: it doesn't overwrite an earlier value, and it doesn't stop a later rule — or your mapping — from filling the field.

The same three choices appear per field on the Mapping tab, where a single-value field instead defaults to Only if not already set — your mapping fills in what no rule claimed. See Mapping your feed to catalog fields.

Cleaning up values step by step#

When a rule sets a field, you don't have to write the final value by hand — you can build it up with "+ Add step". Each step transforms the running value: trim whitespace, replace text, change case, strip HTML, format a number, format a date, map one set of values onto another, split a value into a list or build text around it, among others. Steps run in sequence, so you can, for example, strip HTML from a description and then trim the leftover whitespace. The same value editor appears anywhere you set a field, and every step is explained in Steps: changing a value before it is used. A Product picker at the top of the editor shows each step's result for a real product — pick another product from the sample, or type a product ID, a name or any other value in your feed's columns to search your whole feed for one. You can also type a sample value of your own to check the steps against different data. When a step can't produce a value for that product, its row shows No value with the reason and what to do about it — for example "Shift date gives a date, and Math needs a number. Put Math before Shift date, or use Date difference to count the days." The field's fallbacks are used for that product. In a catalog, the next import also lists the rule under the import's warnings with the same sentence. A Map each step works differently: when its steps give one item of a list no value, that item is simply left out and the step keeps the rest, so nothing falls back and no warning is raised — the step's row in the value editor says how many items were left out and why, for example 1 of 3 items was left out: "abc" isn't a number.

A column your feed repeats for a product — several image links, several highlights — holds several values, and a step that works on text works on every one of them: a Replace step on four image links replaces in all four. Where only one value fits (a field like Title or Price, a group key, the value a condition compares against), the first value is used and Renable warns you on the catalog's Activity tab, naming the rule and how many rows of your feed hold several values there; add a First, Last, Nth or Join step to choose. The lists section of that article has the details.

The date steps — Format date, Date difference and Shift date — are explained in Working with dates; a catalog has no Today's date, so to pick out products by how recent a date is, compare it with days ago in a condition (see Rules that depend on dates).

To convert many source values into correct ones in bulk — say, mapping your own category names onto the categories an ad network expects — pair the Map values step with a mapping table. See Mapping tables.

Formatting numbers#

A number is written exactly as it is unless a Format number step says otherwise — the rule is explained in Languages and localization. A feed value keeps the text your feed wrote, and a number a step or a group works out is written plainly, like 4490.5. So a rule that sets a text column to {{price}} kr writes the price exactly as your feed wrote it — 4490.5 kr for a feed that says 4490.5 — not a formatted price.

Add a Format number step (under Numbers in "+ Add step") to choose how the number is written:

  • Round to decimals — how many decimals to keep. Left empty (As is), the number keeps its own decimals.
  • Decimal separator and Thousands separator — each starts on the separators of the catalog's language, and the menu says which, for example Catalog language (sv-SE: 4 490,50). Pick one to override it for this step.

With Round to decimals set to 2 and both separators on the catalog's language, a Set field that writes {{price}} into a column price_text writes 4 490,00 on a Swedish catalog, and a later rule that writes {{price_text}} kr gives 4 490,00 kr.

Three things to know:

  • Format number turns the number into text, so put it last. Anything that calculates — Math, or a condition comparing numbers — has to come before it. After Format number, a Math step has to read the text back and usually can't, and a condition compares the text, not the number.
  • Your Price field is always stored as a number. It never keeps separators or trailing zeros, and a channel formats it again for its destination, so a price mapping doesn't need a Format number step — leave it out: a price written with separators can be misread when it's read back.
  • Whole-number fields take digits only. A stock count or multipack quantity written as 1 234 or 5.00 doesn't import and shows a warning — use Math rather than Format number in front of those.
  • Math can use another column. A Math step's box takes a number you type or a column you pick, so you can add, subtract, multiply or divide by a column of the same product instead of a fixed number. If that column is empty for a product, the result is empty too.
  • A number you type reads the same in every catalog. Type it with a dot or a comma as the decimal separator; thousands separators and units are not read, so 1.000 is one, and 1 000 or 12 kr isn't a number and isn't saved. This holds whatever the catalog's language is, so a shared ruleset calculates the same everywhere.

Your changes aren't live until you Publish#

This is the one thing that trips people up. Everything you change on the Rules tab — and everywhere else in the catalog workspace — is saved to a draft. Nothing reprocesses, and no channel or ad sees your changes, until you Publish.

That has an important consequence for imports: "Import now" uses your last published configuration, not your draft. The "Import now" button sits in the health strip at the top of the catalog page. If you have unpublished changes and click it, Renable warns you — "Importing now uses your last published configuration — your current edits won't be applied until you publish" — and offers three choices:

  • Cancel — don't import.
  • Import anyway — import using the last published rules; your draft edits are ignored.
  • Publish & import — publish your draft first, then import with the new rules applied.

So when you've been editing rules and want to see them take effect, choose Publish & import (or publish, then import). If you only want to refresh your data without applying draft edits, Import anyway is fine.

To throw away draft edits and go back to what's live, use Revert — your current draft changes are saved to history first, then reset to match the published configuration.

Checking a rule did what you expected#

Two things confirm your rules behave:

  • Each rule shows how many products it matched on the last import. A rule that never matches any product is called out with a "never matched" warning worth checking.
  • Trace (on the Rules tab toolbar) opens Trace a product, which walks a single product through every rule in order, showing which rules applied and how each field changed, ending in the final catalog output. See Feed runs and warnings.

Or ask Aimée#

You don't have to build rules by hand. Describe what you want in plain language — "exclude everything that's out of stock," or "give every product whose title contains 'refurbished' a custom label" — and Aimée can set up the conditions and actions for you, then publish once you approve.

Where to go next#