Personalisation
Fóir decides which version of your content a request gets before it answers. A website, a native app and an agent ask the same question and get the same content, with nothing left to resolve in the client.
Try it on a live record
This panel reads a real record from the Fóir API: the home page hero of a running brand. Change the visitor and the same query comes back with different content.
The site only says what kind of product is in the cart. Fóir works out where the visitor is, what they have bought and what they have spent on the server, so nobody can move to Paris or become a VIP by editing a request. On this page you set them yourself, to see each case.
Sent by your site
Worked out by Fóir on the server
What came back
The server makes the choice
A read tells Fóir what it knows about the request: the device, the locale, and any dimension of your own, such as the kind of product in the cart, or which market the visitor is shopping in. Fóir adds the rest itself: where the request came from, whether the user is signed in, and which segments they belong to.
It picks the variant whose rules match and returns the record with that variant's values already in place. Your code reads the same fields whichever version comes back.
What a visitor cannot claim
Location, sign-in status, segment membership and profile data are never taken from the caller. Fóir places the request itself and works the rest out from the user's token, whatever the request claims.
A segment's rule can read a profile field that the client is not allowed to see, so a value you keep private can still decide what a customer is shown.
An audience is defined once
Who a variant is for is an entry in the variant catalogue: a named set of rules with a priority. Rules can combine dimensions and segments with AND and OR.
Any number of records can point at one entry. Edit the entry and every variant that uses it is retargeted.
A page, a field or a paragraph
A variant can replace a whole record, with its own drafts and version history. It can also override a single field, or one entry inside a prose field or a list, and leave the rest alone.
Editors write each version in the same editor and preview the draft as the audience it is for.
Example: the Paris marathon
A running brand wants its home page to lead with the marathon, but only for people who are in Paris and have bought running shoes from it before.
Neither fact comes from the site. Fóir places each request, so a rule can ask for visitors within 30 km of Paris. A segment reads the signed-in customer's profile: the categories they have bought include running shoes.
One catalogue entry combines the two, and a variant of the home page with the marathon headline and image points at it. Nothing in the front end changes.
What that read returns
The read is the one every visitor's page already makes, sent with the customer's token. A customer in Paris who has bought running shoes gets the marathon page, and _variant in the response names the variant that was served.
A visitor in Lyon, or anyone signed out, gets the default page. The segment is evaluated on every request, so there is no list of runners to keep in sync.
Example: VIP by total spend
A VIP audience is one segment: a rule on the customer's profile that their total spend is above a threshold you choose.
Point a catalogue entry at it and any record can carry a VIP version, whether that is a banner, a price list or a whole landing page. A customer sees it on the first read after they cross the line.
Preview, caching and a trace
The editor resolves a draft for the locale and the audience you pick, so what you approve is what ships. A response that contains a resolved variant is marked private, so a shared cache does not store it.
A debugging switch on a read reports which variants were considered and why one was served, to a key that holds the debug scope.
Read the detail
Variants, Audiences and segments and Resolved on read each cover one part in depth, and the targeting guide has the rule syntax.