Who Gets a Feature Flag: Targeting, Server Rules and Rings

A visitor's side is decided in a fixed order: targeting first, then rings, then the rollout. A visitor the targeting excludes never reaches the rings. A visitor a ring decides never reaches the rollout. Targeting, server rules and rings all live on the flag's Targeting tab.

Targeting

Targeting is the same Targeting & conditions card experiments use: URL rules, device, cookie, activation and saved targetings. See Experiment Targeting Library and URL Targeting.

What it means differs slightly by kind:

• Editor flag: "Only visitors on pages these rules match can get On. Everyone else sees the page as it is."
• Code flag: "In the browser, the flag is Off on pages these rules do not match. Your server uses the server rules."

On a live flag, changes to targeting take effect when you click Publish rules.

Server rules

A code flag can have up to 20 server rules: attribute rules your server SDK checks against the attributes you pass with each decision. A visitor who does not match every rule gets Off. Changes reach the SDK at once, which in practice means within about 45 seconds. See Attribute Rules and Bucketing on a Customer ID.

Server rules apply only on the server. In the browser, a code flag uses the targeting above.

Rings

A ring is a group that always gets one side, decided before the rollout: your staff, a list of early-access customers, a key account that must not see the change yet. A flag can have up to 10 rings. They are checked in order and the first match wins, so put the most specific ring first.

Each ring sets:

• Serve: On or Off.
• IDs: up to 1,000, each up to 256 characters, one per line. On an editor flag these are visitor IDs. On a code flag they are visitor IDs or customer IDs, matching what the flag buckets on.
• Attribute rules: up to 20. Every rule must match.

A ring with both IDs and rules matches a visitor only when both do.

In the browser, attribute rules match window.PertentoAttributes, which your page sets before the Pertento snippet:

window.PertentoAttributes = { staff: true, plan: 'pro' };

On the server, they match the attributes your code passes to the SDK.

Ring members are not part of the On/Off comparison the guardrail makes.

Bucketing on a customer ID

A code flag can bucket on Customer ID instead of Visitor ID, chosen when the flag is created. The same signed-in customer then gets the same side on every device and browser. Your server passes the customer's ID as id to the SDK, and decides the flag there.

In the browser, a customer ID flag can only be read when your server seeded the page with its decision. Without a seed it reads Off. See Reading a Feature Flag on Your Server.

What stays private, and what does not

The IDs you list in a ring are never published in your website's script. Only an irreversible fingerprint of each goes out, so nobody can read your early-access list from the page source. Rings of customer IDs never reach the browser at all.

Payloads and the values in attribute rules are different. Anyone who opens your site's script can read them. Never put a secret, an unreleased price or anything private in a payload or a rule value.