Behavioral Analytics — Frequency, Association and Lift per Segment

"What does this customer buy?" and "what do they buy disproportionately?" are different questions — the first is counting, the second is association. Aito v2 answers both with the same query shape: open a field's values as candidates with get, then rank by $f (frequency under the evidence) or $lift (how much the evidence raises each value's probability over its base rate).

What does this user actually buy?

impressions link browsing contexts to products, with a purchase outcome. Count-ranked, per user:

{
  "from": "impressions",
  "where": { "context.user": "0", "purchase": true },
  "get": "product",
  "orderBy": "$f",
  "select": ["name", "$f"],
  "limit": 3
}

{ "hits": [
  { "$f": 7, "name": "Chiquita banana" },
  { "$f": 7, "name": "Ilta Sanomat weekend news" },
  { "$f": 5, "name": "Cucumber Finland" } ] }

Note the select: on a get over a link, the target row's columns are selectable — each candidate product resolves its own name. Different user, different profile (user larry buys ham sausage and rye bread — the data says so, not a persona).

What is characteristic, not just frequent?

Everyone buys bananas. $lift ranks by how much this user's purchases deviate from the population — the signal you want for personalization and segment description:

{
  "from": "impressions",
  "where": { "context.user": "larry", "purchase": true },
  "get": "product",
  "orderBy": "$lift",
  "select": ["name", "$f", "$lift"],
  "limit": 5
}

$f and $lift give different orderings on purpose: frequency is demand, lift is affinity.

Slice by any evidence

The where is ordinary evidence — swap the user for a weekday, a search query, a device, a region:

{
  "from": "impressions",
  "where": { "context.weekday": "Saturday", "purchase": true },
  "get": "product",
  "orderBy": "$f",
  "select": ["name", "$f"],
  "limit": 10
}

Aggregates work per candidate too — e.g. a per-product conversion rate via { "$mean": { "$context": "purchase" } } in the select (see the Query Reference).

Why Aito for this

One query, both statistics. No pipeline that counts and a second one that computes baselines — $f and $lift come from the same pass.
Cross-table by links. context.user traverses the impression → context → user chain declared in the schema; no join spelling.
Explorable. Every ranking is a plain query — change the where, re-run, compare. It's analytics at API latency, not a nightly job.

← All v2 use cases