Delectable AI: Household De-Averaging & Graph Intelligence

One Loyalty Card.
Multiple People.

A single Your Grocer Advantage Card serves an entire household — a health-conscious mom, an athlete dad, a toddler. Without de-averaging, the AI treats them as one blurred persona and recommendations fail for everyone.

Our approach uses a BigQuery Property Graph with K-Means clustering to disentangle distinct personas on a shared card, enabling multi-hop graph queries that enforce allergen safety, personalize per-persona, and reason across household relationships.

The Household Averaging Problem

Every grocery retailer has this problem. One loyalty card = one "customer." But that customer is actually 2-5 distinct people with conflicting needs.

Without De-Averaging (Industry Standard)

// Loyalty Card #4821 — "averaged" profile:
propensity_high_protein: 0.55 ← moderate?
propensity_organic: 0.48 ← sort of?
propensity_vegan: 0.12 ← barely?
top_departments: ["Produce","Meat","Baby"]
// This profile describes NO ONE in the household.
// The athlete doesn't see high-protein.
// The health-conscious mom doesn't see organic.
// The baby's needs are drowned out.

Result: Generic recommendations that feel irrelevant to everyone. Low engagement. Low cart conversion.

With De-Averaging (Our Approach)

// Loyalty Card #4821 — de-averaged personas:
Persona A: "Health-Conscious Mom" (45% of trips)
  organic=0.82, low_sodium=0.78, produce-focused
Persona B: "Athlete Dad" (32% of trips)
  high_protein=0.92, bulk buyer, sports nutrition
Persona C: "Parent (Baby)" (18% of trips)
  baby_care=high, allergen-sensitive, organic baby food
// Each persona gets their own recommendations.
// The agent adapts based on WHO is shopping NOW.

Result: "Are you shopping for the family today, or stocking up on your protein favorites?" Personalized per-persona.

💡

Why This Matters for Your Grocer

2.3

Average distinct personas per loyalty card

67%

of cards show multi-persona shopping patterns

3x

higher engagement when recommendations match the active persona

Two-Tier K-Means Persona Clustering

Every shopping trip becomes a feature vector. K-Means clustering (K=8, cosine distance) discovers archetypes. Trips are assigned to personas. Households get a persona composition.

Tier 1: Trip-Level Feature Engineering

Each shopping trip (same MPID + date) is converted into a normalized feature vector capturing the trip's "shape" — not magnitude.

-- household_persona_features.sql
-- Convert each trip into a feature vector:
SELECT
  mpid, trip_date,
  -- Department signals (raw counts per trip):
  baby_kids_items, athlete_wellness_items, foodie_premium_items,
  health_pharmacy_items, fresh_perimeter_items, baking_items,
  center_store_items, household_items, pet_items,
  -- Scale & diversity:
  items_in_trip, department_diversity, trip_total,
  unique_brands, brand_diversity_ratio,
  -- Temporal:
  is_weekend  -- Sat/Sun indicator

Baby/Kids

baby care, formula

Athlete

sports nutrition

Foodie

premium, specialty

Fresh

perimeter produce

Health

pharmacy, wellness

Tier 2: BQML K-Means Clustering

Model Definition
CREATE MODEL household_mission_cluster_model
OPTIONS (
  model_type = 'KMEANS',
  num_clusters = 8,
  standardize_features = TRUE,
  max_iterations = 20,
  distance_type = 'COSINE'
)
-- Features are PERCENTAGES, not counts
-- Ensures trip "shape" similarity
SELECT
  SAFE_DIVIDE(baby_kids, items) AS pct_baby,
  SAFE_DIVIDE(athlete, items) AS pct_athlete,
  SAFE_DIVIDE(foodie, items) AS pct_foodie,
  ...

Why K=8 with Cosine Distance?

Over-clustering (K=8) intentionally produces more clusters than final personas. Centroid analysis then merges similar clusters into labeled archetypes. Cosine distance captures trip "shape" — a 5-item baby run and a 20-item baby stock-up cluster together because the department distribution is similar.

Discovered Archetypes

Household-Level Persona Composition

After clustering every trip, we aggregate per MPID to produce a persona composition with confidence scores.

-- persona_assignment.sql: Label clusters via centroid analysis
CASE
  WHEN baby_signal > 0.15 THEN 'Parent & Family'
  WHEN athlete_signal > 0.15 THEN 'Athlete & Wellness'
  WHEN foodie_signal > 0.15 THEN 'Foodie & Premium'
  WHEN health_signal > 0.15 THEN 'Health & Pharmacy'
  WHEN baking_signal > 0.15 THEN 'Baker & Home Cook'
  WHEN pet_signal > 0.15 THEN 'Pet Parent'
  WHEN fresh_signal > 0.40 THEN 'Fresh Food Focus'
  WHEN trip_size > 0.70 AND weekend > 0.60 THEN 'Weekend Stock-Up'
  WHEN trip_size < 0.30 THEN 'Quick Run'
END
-- Then aggregate per household:
primary_persona: "Parent & Family" (45% of trips, confidence 0.82)
secondary_persona: "Athlete & Wellness" (32%, confidence 0.71)
tertiary_persona: "Health & Pharmacy" (18%, confidence 0.55)
persona_diversity_score: 0.55 ← multi-persona household

BigQuery Property Graph Schema

8 node types, 10+ edge types, queryable via openCypher. The graph encodes relationships that no flat table or LLM can reason over efficiently.

Entity-Relationship Graph

👤 User belongs_to → 🏠 Household ← belongs_to 👤 User

👤 User has_propensity → 💚 Propensity has_allergy → ⚠ Allergen ← contains_allergen 📦 Product

🍴 Recipe contains → 🥦 Ingredient maps_to → 📦 Product belongs_to → 📁 Category

Node Types (8)

User— loyalty_id, mpid, household_id

Household— member_count, personas

Propensity— low_sodium, high_protein, etc.

Allergen— peanut, shellfish, dairy, etc.

Product— SKU, price, nutrition

Recipe— 2.1M recipes with embeddings

Ingredient— 223K normalized ingredients

Category— department hierarchy

Key Edge Types

belongs_to — User → Household (enables household traversal)

has_propensity — User → Propensity (strength: 0-1)

has_allergy — User → Allergen (safety-critical)

purchased — User → Product (count, timestamp)

contains_allergen — Product → Allergen (from Food Intel)

contains — Recipe → Ingredient

maps_to — Ingredient → Product (semantic bridge)

co_purchased — Product → Product (affinity, lift)

Property Graph DDL (BigQuery)

CREATE OR REPLACE PROPERTY GRAPH giant_eagle_knowledge_graph
NODE TABLES (
  graph_nodes_users       KEY(user_node_id)      LABEL User,
  graph_nodes_households   KEY(household_node_id)  LABEL Household,
  graph_nodes_propensities KEY(propensity_node_id) LABEL Propensity,
  graph_nodes_allergens    KEY(allergen_node_id)   LABEL Allergen,
  graph_nodes_products     KEY(product_node_id)    LABEL Product,
  graph_nodes_recipes      KEY(recipe_node_id)     LABEL Recipe,
  graph_nodes_ingredients  KEY(ingredient_node_id) LABEL Ingredient,
  graph_nodes_categories   KEY(category_node_id)   LABEL Category
)
EDGE TABLES (
  graph_edges_user_household    SOURCE REFERENCES Users    DEST REFERENCES Households   LABEL belongs_to,
  graph_edges_user_propensity   SOURCE REFERENCES Users    DEST REFERENCES Propensities LABEL has_propensity,
  graph_edges_user_allergy      SOURCE REFERENCES Users    DEST REFERENCES Allergens    LABEL has_allergy,
  graph_edges_user_purchase     SOURCE REFERENCES Users    DEST REFERENCES Products     LABEL purchased,
  graph_edges_product_allergen  SOURCE REFERENCES Products DEST REFERENCES Allergens    LABEL contains_allergen,
  graph_edges_recipe_ingredient SOURCE REFERENCES Recipes  DEST REFERENCES Ingredients  LABEL contains,
  graph_edges_ingredient_product SOURCE REFERENCES Ingredients DEST REFERENCES Products LABEL maps_to
);

Multi-Hop Graph Queries

The graph enables reasoning that requires traversing 2–4 relationships in a single query. No flat table, keyword search, or standalone LLM can do this — each hop crosses an entity boundary that would require a separate JOIN or API call in a relational system.

💡

What Is a "Hop"?

Each hop traverses one edge in the property graph — moving from one entity to a related entity. A 3-hop query crosses 3 relationships, connecting entities that have no direct link. This is how the system reasons across household boundaries, allergen chains, and recipe-to-product mappings simultaneously.

2 hops

"Who else shops on this card?"

User → Household → Other Members

3 hops

"What's unsafe for this household?"

User → Household → Member → Allergen

4 hops

"Build a safe, personalized cart from a recipe"

Recipe → Ingredient → Product → Allergen check

Why Can't a Flat Table Do This?

SQL / Flat Table Approach

-- "Is this product safe for this household?"
-- Requires 4 separate queries:
Q1: SELECT household_id FROM users WHERE loyalty_id = '4821'
Q2: SELECT user_id FROM users WHERE household_id = ?
Q3: SELECT allergen FROM allergies WHERE user_id IN (?)
Q4: SELECT * FROM products WHERE allergen NOT IN (?)
-- 4 round trips. ~200ms total.
-- Logic spread across application code.
-- No standard way to add recipe→ingredient→product chain.

Each new relationship requires a new query and new application logic. Complexity grows exponentially with depth.

Graph Query Approach

-- Same question, one traversal:
GRAPH_TABLE(giant_eagle_knowledge_graph
  MATCH
    (u:User {loyalty_id: '4821'})
    -[:belongs_to]->(h:Household)
    <-[:belongs_to]-(member:User)
    -[:has_allergy]->(a:Allergen)
    <-[:contains_allergen]-(p:Product)
  COLUMNS(a.name, member.name, p.sku)
)
-- 1 query. ~15ms. Declarative pattern.
-- Adding recipe→ingredient is one more MATCH clause.

Relationships are first-class. Adding depth costs one line, not a new query. Pattern matching is declarative and optimizable.

~15ms

3-hop allergen traversal

8

Node types in graph

10+

Edge types

1

Query per traversal

How Personas Feed the Agent

The agent calls query_household_personas and adapts its entire behavior — search queries, ranking weights, meal plan constraints — to the active persona.

Interactive: Same Query, Different Persona

Select a persona to see how the agent adapts for the same household on Loyalty Card #4821.

Select a persona above

Agent Orchestration Flow

// ═══ PERSONA-AWARE AGENT LOOP ═══
1. PREFETCH: get_user_profile(mpid)
   → household_personas: [{primary: "Parent & Family", pct: 45%},
      {secondary: "Athlete & Wellness", pct: 32%}]
   → persona_diversity_score: 0.55 (multi-persona)
2. PERSONA DETECTION (heuristic):
   IF query contains protein/workout/bulk → Athlete persona
   IF query contains baby/toddler/formula → Parent persona
   IF query contains organic/healthy/low-sodium → Health-Conscious
   IF diversity_score > 0.4 AND ambiguous → ASK USER
3. ADAPT RANKING CONTEXT:
   propensity_overrides = persona-specific propensities
   dietary_filters = persona-specific restrictions
   → All 11 ranking stages use persona context
4. GRAPH SAFETY CHECK:
   query_household_graph(loyalty_id)
   → IF any household member has allergen
   → Apply allergen exclusion to ALL meal plans
   → Even if active persona has no allergy
   → "Your household has a tree nut allergy on file"

🏠

Household-Aware Safety: Why the Graph Matters

User A (the athlete dad) asks for a high-protein meal plan. User B (the toddler) has a peanut allergy. Without the graph, the agent has no way to know about User B's allergy when serving User A.

Without Graph (Flat Profile)

Dad asks for protein. Agent recommends peanut butter protein smoothie. Toddler is allergic. No way to cross-reference household members.

With Graph (Household Traversal)

Dad asks for protein. Graph traverses: Dad → belongs_to → Household → belongs_to → Toddler → has_allergy → Peanut. Agent excludes peanut products from ALL recommendations.

One Loyalty Card.Multiple People.