Skip to content

Shared FAQ

No. A segment is a test, evaluated again on every request each time something names it. EdgeKit stores no member list for it and no count, so there is nothing to export.

Can I gate access on a segment that reads a value my page sends?

Section titled “Can I gate access on a segment that reads a value my page sends?”

You can, but anyone can set that value. A value your page sends in context is unverified, so the segment’s trust floor is unverified, and a rule that opens your content on it is a way around your own access rules. Staging warns about every context read and does not refuse it.

Why can’t a canvas entry use my segment?

Section titled “Why can’t a canvas entry use my segment?”

The segment reads a meter or an experiment arm, directly or through another segment. An entry decides who a canvas is for, and a meter count or an arm is a consequence of that decision. Staging refuses the feature, not the segment. Name the segment in a rule inside the canvas instead.

At decide time the test answers an error on every request, never a match. The segment’s screen flags a segment that names itself, but staging does not refuse it, and nothing flags a loop through other segments. In a rule inside the entered canvas, the error answers the canvas’s error outcome when no other rule holds.

When does a change to a segment take effect?

Section titled “When does a change to a segment take effect?”

At the next deploy, for every rule that names it. The segment’s Used by section lists the features and segments that name it.

No. Coverage reads content facts only. Segments, experiments, meters and user facts are for rules in a feature’s canvases.

Does a user see the same arm on every visit?

Section titled “Does a user see the same arm on every visit?”

Yes, as long as the experiment does not change. The arm comes from a hash of the experiment’s salt, its name and the unit’s id, so the same unit lands in the same bucket on every request. Changing the salt or the name re-rolls every unit, and changing a weight or the order of the arms moves every unit whose bucket now falls in another arm’s range.

Does the arm follow a user to another device?

Section titled “Does the arm follow a user to another device?”

Only in a per-user experiment, and only once they sign in. A per-device experiment assigns the browser: another browser, a phone or cleared cookies can get another arm.

  • A unit outside the experiment’s targeting.
  • In a per-user experiment, a request with nobody signed in.
  • In a per-device experiment, a request with no device cookie, such as a device’s first request before EdgeKit Analytics set its cookie.

For a unit with no arm, “they are in” any arm does not hold and “they are not in” every arm holds.

Is off-target the same as the control arm?

Section titled “Is off-target the same as the control arm?”

No. An off-target unit is in no arm. A rule that tests “not in variant” also matches off-target units, so test “in control” when you mean the control group.

When a rule that read one of the experiment’s arms is the rule that wins, so its outcome is the one your site got. An arm read by a rule that lost is not an exposure, and a feature with the operational purpose never exposes anyone.

EdgeKit does not compute them. Each decide API response lists the request’s exposures in exposures, one per experiment, with experiment and arm. Send each one as an experiment_exposure event and analyse those events beside your others. The browser and server clients do not return exposures from decide. See Exposures.

Can I change the split while an experiment runs?

Section titled “Can I change the split while an experiment runs?”

Yes, at the next deploy, but it moves units. A changed weight or arm order moves the bucket ranges, and a changed salt re-rolls everyone. Treat the results from before and after a change as two experiments.

No. Every change is a draft edit that reaches your sites at the next deploy. To stop one, change the rules that test its arms, then leave it out or delete it, and deploy. Staging fails while a rule still names an experiment that is deleted or left out.

Can my own experimentation platform assign the arms?

Section titled “Can my own experimentation platform assign the arms?”

No. Decide assigns arms with EdgeKit’s own hash, and only for experiments authored in EdgeKit. To analyse an experiment in another platform, send the exposures from decide responses to it.

Do two experiments with the same salt split users the same way?

Section titled “Do two experiments with the same salt split users the same way?”

No. The experiment’s name is part of the hash, and no two experiments share a name, so each one splits units independently.

Not on the Facts screen, which is read-only. Your organization adds facts by declaring them elsewhere: the claims your identity provider sends become external.*, your streaming inputs become streaming.* and your profile fields become profile.*. A value only your page knows can be sent in context, unverified.

No. paid means the user holds at least one live grant. A comped, gifted or group grant counts the same as a purchase. A signed-in user with no live grant is registered.

Why does request.geo show the wrong country?

Section titled “Why does request.geo show the wrong country?”

request.geo is the country of the connection that reaches EdgeKit. When your own server forwards the request, it is that server’s country, which may not be the user’s.

It depends on the namespace. A streaming.* or profile.* fact with no value is a miss: the rule that reads it does not hold, and nothing errors. An external.* claim missing from the credential, or a missing credential, reads as absent. A namespace with no value for the request at all, such as bot.* on a site with no bot verdict, is an error, and the canvas answers its error outcome when no rule holds.

Can I trust a value my page sends in context?

Section titled “Can I trust a value my page sends in context?”

Only for decisions where a wrong value costs you nothing. Anyone who can load the page can change it. For a value a user must not be able to change, rely on a fact EdgeKit computes, or send the value from your server, where the user cannot reach it. EdgeKit treats a context value as unverified either way.

Why is a decision I expect missing from Observability?

Section titled “Why is a decision I expect missing from Observability?”

Check, in order:

  • the range: the default is the last 24 hours;
  • the filters: each one narrows the rows;
  • the row limit: the table shows the newest 200 rows, and the footer says when there are more;
  • the delay: rows reach the screen within a minute or two of the request;
  • the request itself: a request refused before any decision is a Refused row, not a decision.

Why does the User column show email addresses?

Section titled “Why does the User column show email addresses?”

For a request from your server, the column shows the user id your server sent, whatever that value is. If your server sends email addresses as user ids, everyone who can open the screen sees them.

Who can see the decide log, and is reading it recorded?

Section titled “Who can see the decide log, and is reading it recorded?”

Every built-in role can: Owner, Admin, Developer, Editor and Member. A custom role needs the Observability permission. Every read, including each Refresh, writes a row to your organization’s audit log naming who read it.

Up to 30 days. The longest range is 30d, and nothing older can be read from the screen.

The request asked for a feature name that your deployed document does not hold: misspelled, left out of the last deploy, removed, or not running on that site. Decide reports the name in unknown and answers the other features.

No. It reads the log when it opens and when you change a filter or the range. Select Refresh to read it again.