Skip to main content
A feature flag turns a feature on or off — or splits visitors across several variants — without shipping new code. You create the flag in tinyanalytics, then read its value in your app with window.tinyanalytics.flag(). Every visitor gets a sticky, consistent assignment: the same person sees the same thing on every visit, and you can dial a rollout from 1% to 100% whenever you’re ready.

Which kind of flag do you need?

Create a flag from the Feature flags page and pick a type. Each answers a different question:

How do I read a flag in my app?

Call the flag by key, and always pass a fallback. The fallback keeps your app behaving sensibly if the flag is unknown or the tracker hasn’t loaded yet. Which method you call depends on the flag type:
flag() returns the assigned value — true / false for a boolean flag, or the variant key for a multivariate one.
Calling flag() also records that the visitor saw the flag — one feature_flag_exposure event per value, per page load. That exposure is what powers experiments, so call flag() at the point the visitor actually experiences the feature, not in a config file that runs on every page. flagPayload() and flags() never record an exposure.

How do I roll a flag out gradually?

Set a rollout percentage from 0 to 100. At 25%, one in four visitors gets the feature — and because assignments are sticky, that same quarter keeps it as you climb to 50%, 75%, and finally 100%. For a multivariate flag, give each variant its own weight. Weights that don’t add up to 100 leave the remainder on the fallback value.

How do I target specific visitors?

Add targeting rules so a flag only applies to visitors who match. Rules read a query parameter or a user trait and compare it with one of these operators: equals · not_equals · contains · starts_with · ends_with · regex Stack rules into condition sets that are checked in order. The first set a visitor matches decides their assignment, and a set with no rules matches everyone. This lets you give plan = enterprise users the new feature outright while rolling it out to 10% of everyone else.

Why does every visitor stay on the same variant?

Assignments are deterministic. tinyanalytics computes each visitor’s bucket from a persistent visitor ID the tracker keeps in the browser, so the same inputs always produce the same result. No assignment is ever stored server-side, and it survives restarts and reloads. Two consequences worth knowing:
  • Each flag buckets independently, so a visitor in the 10% of one flag isn’t automatically in the 10% of another.
  • Stickiness is only as durable as that browser ID. If a visitor clears their site storage, they may re-bucket. Logging in mid-session never flips a variant — identity is used for targeting rules, not for bucketing.

Can a flag apply to a whole account?

Yes. A flag can evaluate per account instead of per person, so every seat in one company shares the same rollout. See group & B2B analytics to set that up.

Frequently asked questions

They most likely cleared their site storage. tinyanalytics buckets each visitor from a persistent visitor ID the tracker keeps in the browser, so stickiness is only as durable as that ID. If the ID is gone, the visitor may re-bucket into a different variant.
No. Logging in mid-session never flips a variant. tinyanalytics uses identity for targeting rules, not for bucketing — bucketing comes from the persistent browser visitor ID.
Yes. window.tinyanalytics.flag() records one feature_flag_exposure event per value, per page load, proving the visitor saw the flag. That exposure is what powers experiments. flagPayload() and flags() never record an exposure.
No. Each flag buckets independently in tinyanalytics, so membership in one flag’s rollout says nothing about another’s.

Experiments

Turn a flag into an A/B test with a goal.

Identify users

Set the traits your targeting rules read.

Group & B2B analytics

Roll a flag out by account, not by person.

Custom events

Measure what visitors do with the feature.