← Plugin catalog
Data & Analytics
Advan Research REI
Advan Research v1.0.0
Publisher description
From the marketplace listing
Turn foot traffic and demographic data into actionable real estate insights. Analyze property performance, compare locations and competitors, understand trade areas and customer profiles, evaluate tenant opportunities, and identify strong sites for retail brands. Built for brokers, landlords, and site selectors who want data-backed answers for leasing, acquisition, renewal, and location decisions.
Language: English · Automatically detected from descriptions.
Files & skills
File archives
Plugin package10 files · 34.9 KBBrowse files →
Skill instructions
advan-rei-design-system12.3 KB
---
name: advan-rei-design-system
description: >
The authoritative design token reference for all Advan REI visual output —
color palette, typography, spacing, border radius, widget structure, and
component patterns. Read this skill before writing any HTML, CSS, or chart
code for Reina. The rei-data-visualization skill references this skill as a
prerequisite. Do not invent colors, font sizes, or layout patterns that
aren't defined here — always derive from these tokens, which are extracted
directly from the Advan REI design library.
---
# Advan REI Design System
This document defines every design token and structural pattern used in the
REI platform. All visual output Reina produces — charts, tables, widgets,
HTML artifacts — must conform to these specifications. All tokens are
extracted from the official Advan REI design library HTML.
---
## Foundation: Dark Theme
The REI interface is a dark navy application. Every visual artifact must use
this palette as its base — never white or light backgrounds.
| Token | Hex | Use |
|-------|-----|-----|
| `--bg-deepest` | `#0E1847` | Page / app background (outermost) |
| `--bg-deep` | `#101B4D` | Deep layer behind widgets, export drawers |
| `--bg-widget` | `#162465` | Widget body, data table cells |
| `--bg-section-hd` | `#1B2B7A` | Section heading rows within widgets |
| `--bg-table-hd` | `#26326E` | Table header rows |
| `--bg-subtle` | `#28325F` | Row dividers, subtle borders |
---
## Color Tokens
### Brand Blues (UI Structure)
| Token | Hex | Use |
|-------|-----|-----|
| `--blue-primary` | `#0061F3` | Interactive elements, modal nav, CTA buttons |
| `--blue-dark` | `#0F53C7` | Hover state for blue-primary |
| `--blue-light` | `#3F8CFD` | Highlighted button states |
| `--blue-lighter` | `#428AF5` | Secondary highlights |
| `--blue-ghost` | `#DBECFF` | Very subtle tint backgrounds |
### Extended Blues (Demographics / Panels)
| Token | Hex | Use |
|-------|-----|-----|
| `--bg-panel` | `#0B41AB` | Panel backgrounds |
| `--bg-panel-hd` | `#0E3894` | Panel header areas |
| `--bg-panel-deep` | `#112369` | Deep panel layers |
| `--bg-demo-cat` | `#1A2B7B` | Demographics category header rows |
| `--bg-demo-row` | `#131E58` | Demographics odd rows |
| `--bg-demo-alt` | `#132C61` | Demographics even rows (alternating) |
### Modal / Settings Shell
| Token | Hex | Use |
|-------|-----|-----|
| `--modal-nav` | `#0061F3` | Left nav column + right action column |
| `--modal-body` | `#0256D4` | Center content area |
| `--modal-btn` | `#3180F6` | Apply / Save / Reset buttons |
---
## Property Colors
Each property in a multi-property comparison is assigned one color track.
Always assign in order: P1 → cyan, P2 → violet, P3 → green, P4 → pink.
Never swap these assignments — cyan always means the first/primary property.
### Property 1 — Cyan
| Shade | Token | Hex |
|-------|-------|-----|
| Primary | `--cyan-primary` | `#17AAB3` |
| Dark | `--cyan-dark` | `#12888F` |
| Bright | `--cyan-bright` | `#00EEFA` |
| Muted | `--cyan-muted` | `#509EAA` |
| Bar / accent | `--cyan-bar` | `#46E2EF` |
| S1 (lightest) | `--cyan-s1` | `#A5F7FC` |
| S2 | `--cyan-s2` | `#39DBE3` |
| S3 | `--cyan-s3` | `#07A5AD` |
| S4 (darkest) | `--cyan-s4` | `#0B4D6D` |
Widget header background: `--cyan-primary` (`#17AAB3`), white text.
Value box background: `#17AAB3`.
### Property 2 — Violet
| Shade | Token | Hex |
|-------|-------|-----|
| Primary | `--violet-primary` | `#713DC5` |
| Dark | `--violet-dark` | `#4E2A89` |
| Bright | `--violet-bright` | `#AB7DF6` |
| Muted | `--violet-muted` | `#8240EA` |
| Bar / accent | `--violet-bar` | `#CAA8FF` |
| S1 | `--violet-s1` | `#D7C0FD` |
| S2 | `--violet-s2` | `#AB8AE1` |
| S3 | `--violet-s3` | `#8055C4` |
| S4 | `--violet-s4` | `#541FA8` |
### Property 3 — Green
| Shade | Token | Hex |
|-------|-------|-----|
| Primary | `--green-primary` | `#17B36A` |
| Dark | `--green-dark` | `#107D4A` |
| Bright | `--green-bright` | `#44E298` |
| Muted | `--green-muted` | `#15A15F` |
| S1 | `--green-s1` | `#B6F0D8` |
| S2 | `--green-s2` | `#7DC5A5` |
| S3 | `--green-s3` | `#459A73` |
| S4 | `--green-s4` | `#0C6F40` |
### Property 4 — Pink
| Shade | Token | Hex |
|-------|-------|-----|
| Primary | `--pink-primary` | `#DB2988` |
| Dark | `--pink-dark` | `#991D5F` |
| Bright | `--pink-bright` | `#E669AC` |
| Muted | `--pink-muted` | `#C5257A` |
| S1 | `--pink-s1` | `#FDC5E3` |
| S2 | `--pink-s2` | `#DC88B5` |
| S3 | `--pink-s3` | `#BB4B86` |
| S4 | `--pink-s4` | `#9A0E58` |
---
## Status Colors
Use for performance indicators, YoY change arrows, and rank badges only.
Never use these for property identity.
| Token | Hex | Use |
|-------|-----|-----|
| `--status-positive` | `#76B723` | Positive YoY, strong rank, green rank bar |
| `--status-negative` | `#FF151F` | Negative YoY, weak rank, red rank bar |
| `--status-neutral` | `#999999` | Flat / no change, neutral indicators |
| `--status-disabled` | `#707070` | Disabled or unavailable state |
| `--red-badge` | `#FE141E` | Alert badges |
---
## Neutrals
| Token | Hex | Use |
|-------|-----|-----|
| `--white` | `#FFFFFF` | Primary text on dark backgrounds |
| `--gray-light` | `#E4E4E4` | Secondary text, metric labels, address lines |
---
## Typography
**Font family:** `'Rubik', 'Google Sans Text', 'Roboto', sans-serif`
Import from Google Fonts: `Rubik:wght@300;400;500;600`
### Type Scale
| Token | Size | Common use |
|-------|------|------------|
| `--text-xs` | `8.75px` | Tertiary labels, badges, footnotes |
| `--text-sm` | `10.5px` | Addresses, supporting detail, pill buttons |
| `--text-base` | `12.25px` | Standard body, table cells, form fields |
| `--text-md` | `14px` | Default UI text, modal content, nav items |
| `--text-lg` | `15.75px` | Widget titles, section headings |
| `--text-xl` | `19.6px` | Section titles |
| `--text-2xl` | `22px` | Page-level headings |
### Font Weights
| Token | Value | Use |
|-------|-------|-----|
| `--fw-light` | `300` | Inactive nav items, secondary labels |
| `--fw-regular` | `400` | Body text, table cell values |
| `--fw-medium` | `500` | Active nav items, widget titles, button labels, property names |
---
## Spacing
| Token | Size |
|-------|------|
| `--gap-xs` | `4px` |
| `--gap-sm` | `8px` |
| `--gap-md` | `12px` |
| `--gap-lg` | `16px` |
| `--gap-xl` | `24px` |
| `--gap-2xl` | `32px` |
---
## Border Radius
| Token | Size | Use |
|-------|------|-----|
| `--r-none` | `0px` | Flush edges |
| `--r-xs` | `2px` | Micro elements, value boxes |
| `--r-sm` | `3.5px` | Buttons, pill segments, small chips |
| `--r-md` | `7px` | Cards, widgets, modals, table header corners |
| `--r-lg` | `17.5px` | Larger rounded panels |
| `--r-pill` | `26.25px` | Full pill shapes |
| `--r-full` | `50%` | Circles (logo marks, avatars) |
---
## Widget Structure
Every data widget follows this shell pattern:
```
┌─────────────────────────────────────────┐
│ WIDGET HEADER (property color bg) │ ← colored per property P1–P4
│ Property name · metric · date range │ font-size: 12–14px, fw-medium
├─────────────────────────────────────────┤
│ │
│ WIDGET BODY (bg: #162465) │ ← --bg-widget
│ Chart, table, or metric content │
│ │
├─────────────────────────────────────────┤
│ LEGEND BAR (optional, multi-property) │ ← --bg-widget, muted property colors
│ ● P1 Name ● P2 Name │
└─────────────────────────────────────────┘
```
- **Outer border-radius:** `--r-md` (7px) on all corners
- **Header padding:** `12px 16px`
- **Body padding:** `12–16px`
- **Header background:** primary property color (`--cyan-primary` for P1). For multi-property or no-owner widgets, use `--bg-table-hd` (`#26326E`).
---
## Component Patterns
### Value Boxes
Small inline colored rectangles in data tables that tie a metric value to
its property color.
```css
background: var(--cyan-primary); /* or violet / green / pink per property */
color: #FFFFFF;
border-radius: var(--r-xs); /* 2px */
padding: 2px 6px;
font-size: var(--text-sm); /* 10.5px */
font-weight: var(--fw-medium); /* 500 */
display: inline-block;
```
Use value boxes when a table column belongs to a specific property. Omit them
for single-property tables — use plain white text instead.
### Rank Badges
Left vertical bar (3px wide, full cell height) + rank text "X of Y".
```css
/* Positive / strong performer */
border-left: 3px solid var(--status-positive); /* #76B723 */
/* Negative / weak performer */
border-left: 3px solid var(--status-negative); /* #FF151F */
```
Always format rank as `"X of Y"` — include the total count, never just the rank number.
### Change Indicators (YoY)
Shown alongside metric values in ranking tables.
- Positive: `▲ +8.3%` in `--status-positive` (`#76B723`)
- Negative: `▼ −4.1%` in `--status-negative` (`#FF151F`)
- Flat: `— ` in `--status-neutral` (`#999999`)
### Rank Cards
Standalone rank callouts (e.g., in a summary section):
```css
background: rgba(255, 255, 255, 0.05); /* glass effect */
border-radius: var(--r-md); /* 7px */
padding: var(--gap-md); /* 12px */
```
Value displayed large (14–16px, fw-medium), "X of Y" in smaller text below,
colored rank bar at bottom using the status color conventions.
### Pill / Segmented Buttons
```css
font-size: var(--text-sm); /* 10.5px */
height: 26px;
padding: 0 8.75px;
border: 0.833px solid rgba(255, 255, 255, 0.15);
border-radius: 0;
background: transparent;
color: white;
font-family: var(--font-primary);
/* Active state */
background: rgba(255, 255, 255, 0.15);
border-color: rgba(255, 255, 255, 0.15);
```
First item in group: `border-radius: 3.5px 0 0 3.5px`
Last item in group: `border-radius: 0 3.5px 3.5px 0`
### Property Cell (Ranking Table Row)
Each row in a ranking table identifies the property with:
- Circular logo icon (50% border-radius)
- Property name: 12px, fw-medium (500), white
- Address: 10.5px, fw-light (300), `--gray-light`
- Square footage: 8.75px, neutral gray
---
## CSS Starter Block for HTML Artifacts
Include this in every `<head>` before any other styles:
```html
<link href="https://fonts.googleapis.com/css2?family=Rubik:wght@300;400;500;600&display=swap" rel="stylesheet" />
```
Declare these tokens on `:root`:
```css
:root {
--font-primary: 'Rubik', 'Google Sans Text', 'Roboto', sans-serif;
/* Backgrounds */
--bg-deepest: #0E1847;
--bg-deep: #101B4D;
--bg-widget: #162465;
--bg-section-hd: #1B2B7A;
--bg-table-hd: #26326E;
--bg-subtle: #28325F;
--bg-demo-cat: #1A2B7B;
--bg-demo-row: #131E58;
--bg-demo-alt: #132C61;
/* Blues */
--blue-primary: #0061F3;
--blue-dark: #0F53C7;
--modal-nav: #0061F3;
--modal-body: #0256D4;
--modal-btn: #3180F6;
/* Property colors */
--cyan-primary: #17AAB3;
--cyan-bar: #46E2EF;
--cyan-muted: #509EAA;
--violet-primary: #713DC5;
--violet-bar: #CAA8FF;
--green-primary: #17B36A;
--pink-primary: #DB2988;
/* Status */
--status-positive: #76B723;
--status-negative: #FF151F;
--status-neutral: #999999;
--status-disabled: #707070;
/* Neutrals */
--white: #FFFFFF;
--gray-light: #E4E4E4;
/* Typography */
--text-xs: 8.75px;
--text-sm: 10.5px;
--text-base: 12.25px;
--text-md: 14px;
--text-lg: 15.75px;
--text-xl: 19.6px;
--fw-light: 300;
--fw-regular: 400;
--fw-medium: 500;
/* Spacing */
--gap-xs: 4px;
--gap-sm: 8px;
--gap-md: 12px;
--gap-lg: 16px;
--gap-xl: 24px;
--gap-2xl: 32px;
/* Radius */
--r-xs: 2px;
--r-sm: 3.5px;
--r-md: 7px;
--r-lg: 17.5px;
--r-pill: 26.25px;
--r-full: 50%;
}
body {
font-family: var(--font-primary);
background: var(--bg-deepest);
color: var(--white);
font-size: var(--text-md);
line-height: 1.5;
}
```
Chart libraries (Chart.js, etc.) may be loaded from `https://cdnjs.cloudflare.com`.
Chart canvas backgrounds must match `--bg-widget` or `--bg-deepest` — never white.
foot-traffic-analysis7.17 KB
--- name: foot-traffic-analysis description: > Step-by-step workflow for analyzing foot traffic at a single retail property using Advan REI MCP data. Use this skill whenever Reina is asked about a property's traffic performance, visit trends, dwell time, visit frequency, or general location performance. Trigger on phrases like "how is [property] performing", "show me traffic for [location]", "what's the foot traffic at [address]", "how have visits trended", "is this center busy", "pull the traffic data for", or any request that centers on understanding a specific property's visitor activity — even if the user doesn't say "foot traffic" explicitly. When in doubt, use this skill before answering. --- # Foot Traffic Analysis Workflow A single-property traffic analysis has four stages: resolve the property, pull core metrics, benchmark against the market, and synthesize. The stages build on each other — don't skip ahead or collapse them into one big query. --- ## Stage 1: Resolve the Property Properties in the REI platform are identified by three fields: **ALI** (the primary unique identifier), **location name**, and **company name**. If the user has referenced any of these — or if they've been established earlier in the conversation — use them directly and proceed to Stage 2. If the property is ambiguous — a partial name, an address, or a loose description like "the Target on Route 9" — use `search` to find it. Present the top results concisely and ask the user to confirm before pulling data. Don't guess and proceed; a misidentified property produces confidently wrong analysis. Once confirmed, carry the ALI, location name, and company name forward. You'll reuse them across every tool call in this workflow. --- ## Stage 2: Pull Core Metrics Call these three tools in order. Each one adds a layer to the story. **Date range:** Use whatever date range the user has selected in the UI, or whatever period they've specified in their question. Only ask about the date range if it's genuinely ambiguous from context. ### 2a. Traffic Summary — the volume story Call `traffic-summary` with the resolved property identifiers. Key outputs to capture: - Total visit count for the period - Month-over-month and year-over-year trend - Any notable spikes or drops ### 2b. Dwell Time — the engagement story Call `dwell-time` for the same property and date range. Dwell time tells you whether visitors are spending meaningful time or just passing through. A high-traffic property with low dwell time often signals convenience-oriented shopping or a pass-through layout; higher dwell suggests destination behavior or a strong tenant mix. ### 2c. Visit Frequency — the loyalty story Call `visit-frequency` for the same property and date range. Visit frequency distinguishes properties that draw the same loyal customers repeatedly from those that rely on a constant stream of new visitors. A grocery-anchored center will typically show higher frequency than a fashion or home goods property — keep that in mind when interpreting the result. --- ## Stage 3: Benchmark Against the Market A traffic number without context is just a number. Call `ranking` to place the property within its submarket or category using the same date range. The ranking result gives you where this property sits relative to peers and whether it's gaining or losing ground. Weight this step based on what the user actually asked — if they want to know if the property is strong, lead with rank; if they're just asking how busy it is, one sentence is enough. --- ## Stage 4: Synthesize and Present ### Search for real-world context Before writing the narrative, do a targeted web search for anything that could explain or color what the data is showing. You're looking for things like: recent anchor tenant changes or closures, new competition that opened nearby, local economic conditions, a major employer moving in or out, weather events or regional disruptions, renovation or construction activity, or any news that a real estate professional would find relevant when reading these numbers. You don't need to find something every time — if a search turns up nothing useful, move on. But when you do find something that connects, weave it into the narrative naturally rather than citing it as a footnote. The goal is to help the user understand *why* the traffic looks the way it does, not just *what* it looks like. Search examples that tend to be productive: - "[Property name] [city] anchor tenant" - "[Retail chain] closures [year]" if a relevant tenant is in the news - "[City/submarket] retail market [year]" for broader context - "[Shopping center name] renovation OR redevelopment" ### Lead with the headline Open with one sentence that answers the user's actual question. Don't make them read a table to find the takeaway. > "Riverside Commons drew roughly 1.2M visits over the period, up 8% > year-over-year, putting it in the top quartile of grocery-anchored centers > in the submarket — a trend that tracks with the Whole Foods renovation that > completed last spring." ### Core metrics table Always include a table. It's the reference point the user will return to. | Metric | Value | vs. Prior Year | |--------|-------|----------------| | Total visits | X | +/- Y% | | Avg. monthly visits | X | +/- Y% | | Median dwell time | X min | +/- Y% | | Visit frequency (avg. visits/visitor) | X | +/- Y% | | Submarket rank | #X of Y | ↑/↓ Z positions | Populate only the rows where you have data. If a metric wasn't returned, omit the row rather than leaving it blank. ### Trend narrative Two to three sentences on what's driving the numbers. Look for: - Whether growth is consistent or concentrated in specific months - Any divergence between metrics (visits up but dwell down — could signal a tenant change or anchoring issue) - Seasonal or external factors, especially anything surfaced from the web search Be specific when the data supports it. If the data and context together tell a clear story, tell it directly. ### Cite data vintage End with the data vintage. Example: > *Data covers [date range], via Advan's mobile device panel.* --- ## Handling Gaps and Anomalies **No data returned:** Say so plainly and offer a path forward. Don't speculate about why. > "I'm not finding traffic data for that property — it may not be in our > coverage area. Want me to check a nearby comparable, or should I flag this > for the support team?" **Partial data:** Lead with what's available, be explicit about what's missing. Don't bury the gap. **Anomalous results:** If a number looks implausible — a 400% traffic spike, a dwell time under 2 minutes for a grocery store — flag it before presenting it. The web search may turn up an explanation; if it does, note it. If it doesn't, say so and recommend verifying. > "These numbers look unusually high relative to the submarket. I didn't find > an obvious external explanation — I'd verify before relying on them. Want > me to pull a peer comparison?" --- ## Follow-Ups If there's a natural next step given what you found, mention it. This should feel like something a colleague would say at the end of a conversation, not a menu of options. Sometimes there's nothing to add — that's fine too.
rei-data-visualization12.4 KB
--- name: rei-data-visualization description: > Guidance for visualizing Advan REI data as charts, graphs, and maps within Reina's responses. Use this skill whenever Reina is about to produce any chart, graph, or visual representation of REI data — traffic trends, demographic breakdowns, rankings, visit patterns by hour or day, or trade area maps. Also use when the user explicitly asks to "chart", "graph", "visualize", "show me a chart of", or "map" any REI data. Always read this skill before writing visualization code or choosing a chart type for REI data. --- # REI Data Visualization This skill governs how Reina visualizes data from REI queries. It covers when to visualize, what format to produce, how to style output, and which chart type fits each data type. --- ## Step 1: Read the Design System Before writing any visualization code, read the `advan-rei-design-system` skill. It defines the color palette, typography, dark theme, component patterns, and spacing that all REI visualizations must follow. This skill adds chart-specific guidance on top of that foundation — it does not replace it. --- ## Step 2: Decide Whether to Visualize Not everything warrants a chart. Use this as a guide: **Visualize when:** - Showing a trend over time (traffic by month, YoY comparison) - Comparing a property or tenant across multiple peers simultaneously - Displaying a distribution (demographics by income band, visits by hour) - The pattern or shape of the data is the point — not just a single number - The user explicitly asks for a chart or visualization **Use a table instead when:** - Exact values matter more than the pattern (a benchmarking summary, a ranked list of properties with specific metrics) - There are fewer than four data points — a chart adds visual overhead for little gain - The user is likely to copy figures into another document or report **Use prose instead when:** - The finding can be stated in one clear sentence - There is only one data point or metric being communicated - A chart would slow the user down, not help them When in doubt, lead with the answer in prose and offer to chart it. --- ## Step 3: Choose the Output Format **HTML artifact (interactive):** Use when the user is exploring data in a conversation, the chart benefits from hover states or tooltips showing exact values, or the output is a standalone deliverable they'll reference during the session. **Static image (SVG or PNG):** Use when the user asks to export, wants to include the chart in a report or presentation, or the context is clearly a one-time view rather than an interactive reference. When the request is ambiguous, default to HTML. If the user later wants to export, offer the static version. --- ## Step 4: Chart Type by Data Type ### Traffic Trend Lines **Use:** Line chart with time on the x-axis and visit count on the y-axis. - Plot monthly data points as the default granularity. Offer weekly if the user wants a more granular view or is analyzing a short date range. - If showing YoY, use two lines (current period vs. prior period) in distinct colors from the design system palette. - Mark notable events directly on the chart when they're known — anchor closures, renovations, seasonal peaks — as labeled vertical reference lines. - Always show the data range in the chart subtitle, not just the title. - Don't start the y-axis at zero if the variation is small relative to the absolute level — truncate to show the trend clearly, but label the axis origin so the user knows. ### Demographic Breakdowns **Use:** Horizontal bar chart for ranked categories (income bands, age cohorts, lifestyle segments). Donut or pie chart only for simple two- or three-part compositions (e.g., a dominant segment vs. all others) — never for more than five slices. - Order bars by value descending unless the categories have a natural order (age cohorts, income bands) — in those cases preserve the natural order. - For income and age, show the full distribution rather than just the top segment. The shape of the distribution matters. - For lifestyle/psychographic segments, label each bar with the segment name and its share percentage. Don't abbreviate segment names — users need to read them. - When comparing the subject property's demographics to a retailer footprint or market benchmark, use a grouped bar chart with two bars per category (subject vs. benchmark) in the design system's primary comparison colors. ### Rankings and Peer Comparisons **Use:** Horizontal bar chart with properties or tenants on the y-axis and the metric on the x-axis. Horizontal orientation makes property names readable without rotation. - Highlight the subject property in the design system's accent color. All other bars use the secondary palette. - Sort by metric value descending unless rank order itself is the point, in which case sort by rank. - If showing multiple metrics for the same set of properties (visits + dwell + frequency), use a small multiples layout — one chart per metric — rather than trying to combine everything into one cluttered view. - Label the subject property bar explicitly even if it's obvious from position. ### Visit Patterns by Hour and Day **Use:** Heatmap as the default when showing both hour and day simultaneously. Use a bar chart when showing only one dimension (hour of day only, or day of week only). - For heatmaps: days of week on the y-axis (Monday top to Sunday bottom), hours on the x-axis (midnight to midnight). Use the design system's sequential color scale — light for low traffic, saturated for peak. - For single-dimension bar charts: show all hours or all days, don't truncate to only the peak window. - When comparing a subject site to a retailer footprint, overlay or side-by-side the two heatmaps. Label clearly which is which. - Always note the time zone the data reflects. ### Trade Area Maps Trade area maps showing visitor origin geography are best rendered natively in the REI platform's map view, which has the geographic rendering infrastructure Reina does not replicate. When a user asks for a trade area map: 1. Direct them to the trade area map view in REI for the full interactive rendering. 2. If a visual summary is needed in the conversation, produce a simplified schematic — a center point with annotated concentric rings labeled with the percentage of visitors captured at each radius or drive time band. This is not a map, but it communicates the catchment structure clearly without requiring geographic rendering. 3. If the user explicitly wants a rendered map artifact, use a lightweight mapping library (e.g., Leaflet.js via CDN) in an HTML artifact. Plot the property location and shade the trade area polygon if coordinate data is available. Use the design system's color palette for the shading. --- ## Step 5: Standardized Table Patterns REI uses three distinct table types, each with precise visual specifications. Match the table type to the data being presented. --- ### Data / Metrics Table Use for: foot traffic summaries, dwell time, visit frequency, retailer footprint comparisons, site selection scorecards — any tabular output where rows are metrics and columns are properties or geographies. **Structure:** - Header row: background `#26326E`, font-size 13px, font-weight regular (not bold), white text - Data rows: background `#162465`, border-bottom `1px solid #28325F`, font-size 12.5px - First column (metric label): `var(--gray-light)` text color, lighter font weight — this is the label column, not a data column - Value columns: each property's value is presented inside a colored value box (see below) - Corner cells: header row first cell gets border-radius top-left 7px; last cell gets top-right 7px **Value boxes:** When a table compares multiple properties, each property's values appear inside small inline colored boxes rather than as plain text. The color identifies which property: - P1 (cyan): background `#17AAB3` - P2 (violet): background `#713DC5` - P3 (green): background `#17B36A` - P4 (pink): background `#DB2988` For single-property tables (one location, no comparison), omit value boxes — show plain white text values. **Legend bar (when comparing multiple properties):** Below the table, a legend strip maps each property's color to its name. Legend label background uses the widget blue (`#162465`); each legend cell uses a muted version of the property color. **When to use:** Foot traffic summaries, dwell/frequency metrics, retailer footprint comparisons, site selection scorecards, co-tenancy health checks. --- ### Ranking Table Use for: benchmarking results, performer lists, any table where rows are properties and the primary data point is a rank or ranked metric. **Structure:** - Header row: background `#26326E`, border `1px solid #2D3A78`, row height 32px - Data rows: background `#162465` - Each row's rank badge has a left vertical color bar (3px wide): green `#76B723` for strong performers, red `#FF151F` for weak performers - Rank is expressed as "X of Y" (e.g., "3 of 47") — always show the total count - Property cell contains: logo circle icon + property name (font-weight 500, 12px) + address (gray-light, 10px) + square footage (neutral gray, 9px) **Change indicators (YoY):** When showing year-over-year change alongside rank: - Positive: green dot + upward arrow + percentage (e.g., `▲ +8.3%`) - Negative: red dot + downward arrow + percentage (e.g., `▼ −4.1%`) - Flat/neutral: gray dot + em dash **Rank cards (summary view):** When a single rank needs to be called out prominently rather than in a table row, use a rank card: `rgba(255,255,255,0.05)` background (glass), the rank value large, "X of Y" in smaller text below, a colored bar beneath the value. **When to use:** Market ranking outputs, competitor benchmarking, performer lists, any output from the `ranking` or `performers-list` endpoints. --- ### Demographics Table Use for: trade area demographic breakdowns across geographies (trade area, 1/3/5 mile rings, drive time bands). **Structure:** - Column headers: background `#26326E`, all-caps label, gray-light for the variable column header, white for geography columns - Category headers (grouping rows like "Summary", "Household Income", "Age"): background `#1A2B7B`, full-width span, white text - Data rows: alternate between `#131E58` and `#132C61` - First column (variable label): left-aligned, gray-light text - Primary geography column (trade area or subject): value text highlighted in property color (e.g., cyan for P1) - Comparison geography columns (1 mi, 3 mi, 5 mi): plain white text values **Column header order:** VARIABLES → TRADE AREA (or primary geography) → 1 MI → 3 MI → 5 MI (or drive time bands, following whatever geographies were selected). **When to use:** Any output from the `demography` or `demography-categories` endpoints. Demographics comparisons in the retailer footprint workflow. Trade area analysis demographic breakdowns. --- ### Choosing the Right Table | Data Type | Table Pattern | |-----------|--------------| | Foot traffic metrics, dwell, frequency, YoY | Data / Metrics Table | | Multi-property comparison (same metric) | Data / Metrics Table with value boxes | | Rankings, benchmarking, performer lists | Ranking Table | | Demographic breakdowns by geography | Demographics Table | | Retailer footprint comparison | Data / Metrics Table | | Void analysis candidate list | Data / Metrics Table (plain, no value boxes) | --- ## Step 6: Universal Chart Standards These apply to every visualization regardless of type: - **Title:** Short and specific — name the property, metric, and date range. "Riverside Commons — Monthly Visits, Jan–Dec 2024" not "Traffic Trend." - **Subtitle or caption:** Data vintage and source. "Advan mobile device panel" and the date range if not in the title. - **Axis labels:** Always labeled, never omitted. Include units (visits, minutes, %). - **Tooltips:** In HTML artifacts, always show exact values on hover — don't make the user estimate from the chart. - **Legend:** Only when there are two or more series. Single-series charts don't need a legend. - **Gridlines:** Light, unobtrusive. Horizontal only unless the chart type genuinely benefits from vertical gridlines. - **Annotations:** Use them. A well-placed label explaining a spike or drop is more useful than leaving the user to wonder. - **No 3D effects, gradients on bars, or decorative elements** that don't carry data meaning. The design system's aesthetic is clean and data-forward.
rei-methodology24.1 KB
--- name: rei-methodology description: > Reference for explaining Advan REI's data methodologies consistently and accurately. Use this skill whenever a user asks how any REI metric is calculated, what a term means, how the underlying data is collected, what the data's limitations are, how accurate the panel is, how trade areas are built, how demographics are attributed, how rankings are scored, or anything about how the data works rather than what it shows. Trigger on phrases like "how is this calculated", "what does [metric] mean", "how do you define a visit", "where does this data come from", "how accurate is this", "what's the methodology", "how are trade areas defined", "how current is the data", "what's the difference between [X] and [Y]", or any question that is fundamentally about the data and method rather than the data and a specific property. Also trigger when a user challenges or questions the validity of a result — methodology context is often the right response before escalating to support. --- # REI Methodology Reference This skill exists to ensure Reina explains Advan's methodologies consistently, accurately, and at the right level of depth for each user. The core principle: answer from this reference first, calibrate depth to the audience, and escalate to support when a question goes beyond what's here. --- ## Calibrating to the Audience Before explaining a methodology, read the user's question for signals about their technical depth. **Non-technical (broker, leasing agent, asset manager):** Lead with a plain- language analogy or one-sentence explanation. Skip the statistical detail unless they ask. The goal is enough understanding to trust and use the data, not to replicate the methodology. **Technical (data scientist, research analyst, GIS professional):** Go deeper. Cover the underlying measurement approach, known limitations, and where to find further documentation. These users will ask follow-up questions and want precise language. **Mixed audience or unknown:** Lead with the plain-language version, then offer to go deeper: *"Want me to walk through the technical details of how that's measured?"* --- ## The Data Foundation: Advan's Mobile Device Panel All REI metrics derive from the same underlying source: a panel of opted-in mobile devices whose location signals are collected, processed, and aggregated to generate insights about physical locations. **Panel composition:** Advan observes over 100 million U.S. devices. After applying strict data quality filters to remove noise and suspect signals, the working panel represents approximately 20% of the U.S. population and is demographically diverse across geography, age, and income. The panel is sourced via SDK partnerships and collects signals through a combination of GPS, Wi-Fi, and SDK-based location data. **Privacy and compliance:** All data is aggregated and anonymized before delivery. No individual device is identifiable in any REI output. Advan complies with applicable opt-in requirements — devices are included only where users have consented to location data collection through the apps on their devices. **Plain-language explanation for non-technical users:** > "Advan's data comes from a large panel of mobile devices whose owners have > opted in to share their location through the apps on their phones. After > filtering out low-quality signals, the panel represents about 1 in 5 U.S. > consumers and is structured to reflect the broader population across > geography and demographics." --- ## Data Quality and Accuracy When users ask how Advan ensures its data is accurate or how it's been tested, this is a selling point — answer it directly and confidently. **Independent signals, not calibrated to a benchmark:** Advan's data produces its own independent signals rather than being calibrated against a single external ground truth source. This means the data reflects what the panel actually observes, without being shaped by or dependent on any one third-party reference. **Internal quality controls:** Several layers of quality processing are applied before data reaches REI: - *Noise and GPS spoofing filtering:* Suspect or anomalous device signals are identified and removed before they enter the working panel. - *Demographic representativeness weighting:* Panel composition is adjusted to reflect the broader population across geography, age, and income. - *Geofence quality review:* Property boundaries are validated before a location is included — locations where a confident boundary can't be established are excluded rather than approximated. - *Automated anomaly detection:* Unusual spikes or drops are flagged for review so they don't surface to users as reliable data without scrutiny. **How the data holds up in the real world:** Two forms of validation play out continuously through client use: - *Company-level alignment:* At the ticker level, Advan's foot traffic signals closely align with comp reports from publicly traded retailers. This is why hedge fund and fundamental investment clients rely heavily on REI data to trade inter-quarter — it's a signal they trust ahead of earnings. - *Location-level alignment:* At the property level, traffic patterns consistently align with known real-world events — store openings and closings, holiday traffic shifts, anchor changes. Clients regularly evaluate Advan data against ground truth sources including physical traffic counters and internal sales data, and report high correlation. **Plain-language response for users who ask:** > "Advan's data goes through several layers of quality filtering — > removing noise and spoofed signals, validating property boundaries, > and weighting the panel to be demographically representative. On the > accuracy side, our foot traffic signals closely track comp reports for > publicly traded retailers, which is why a lot of institutional > investors use this data to trade inter-quarter. At the location level, > our clients routinely test us against physical counters and sales data > and consistently find strong correlation." --- ## Visit Definition **What counts as a visit:** A visit is recorded when an opted-in device is detected within a property's geofence. There is no minimum dwell time applied by default — every device detection that falls within the property boundary counts as a visit. Users who want to filter by dwell threshold can apply a dwell time filter from the header bar in REI. **Why no default dwell threshold:** Employees, delivery drivers, and quick convenience stops are all legitimate components of a property's traffic picture, and some are meaningful trade area indicators. Rather than prescribing a single threshold, REI puts the filter in the user's hands so analysts can define the visit they care about for their specific question. **Property boundary (geofence):** Each property has a defined geofence — a geographic polygon corresponding to its physical footprint. A device must be detected within the geofence to count toward that property's visit tally. **De-duplication within a day:** Each unique device is counted once per property per day, regardless of how many times it was detected at that location during the day. **Workers and frequent visitors:** Employees and vendors are not excluded from visit counts by default, because frequent visitors — including staff — are part of the real foot traffic picture and contribute to trade area intelligence. Users who want to isolate shopper-only traffic can apply frequency and dwell filters from the Global Filters menu in REI's header to filter out devices with patterns consistent with employee behavior. **Plain-language explanation:** > "A visit is counted whenever someone's device is detected within the > property's boundary. We count each device once per day, and we don't > filter out employees by default — they're real traffic and can be > meaningful data points. If you want to focus on pure shopper behavior, > you can apply frequency and dwell filters to narrow it down." --- ## Dwell Time **Definition:** Dwell time measures how long a visiting device was detected within the property geofence during a visit. It's expressed as a median across all visits in the selected period rather than an average, which makes it more robust to outlier sessions. **What it measures:** Dwell time is a behavioral signal — it distinguishes destination shopping (longer dwell, more browsing) from convenience or errand trips (shorter dwell, get in and get out). It's particularly useful when comparing similar properties or evaluating retailer fit for a specific concept. **Applying a dwell filter:** Because there is no default minimum dwell threshold, users working with dwell time for a specific analysis — such as filtering to visits of at least 5 minutes to exclude true pass-throughs — should apply the dwell time filter in the header bar before pulling metrics. This makes the filter explicit and consistent with the user's analytical intent. **Limitations:** Dwell time reflects how long the device signal was present within the geofence, not time actually spent inside the store. A device that lingers in the parking lot contributes to dwell time. In practice, parking lot behavior is a real component of the retail visit experience, so this is generally an acceptable proxy — but it's worth noting when precision matters. **How dwell is displayed:** REI shows dwell time in 15-minute increments (e.g., 0–15 min, 15–30 min, 30–45 min, and so on). When citing a dwell figure, reference the bucket rather than a precise minute value. **Interpreting dwell buckets:** - 0–15 min: quick stop, errand, or parking lot detection - 15–30 min: standard convenience or grocery trip - 30–45 min: typical shopping trip - 45–60 min: extended shopping or casual dining - 60+ min: destination experience (entertainment, sit-down dining, big box) These are general benchmarks — always compare dwell against the property type and against peer properties in the same category rather than treating any single bucket as good or bad in isolation. --- ## Visit Frequency **Definition:** Visit frequency measures how many times the average visitor returns to a property over a defined period. Specifically, it's calculated as the total visits divided by the number of unique devices that visited — giving an average number of trips per unique visitor. **What it measures:** Frequency is a loyalty signal. A property with high frequency is drawing repeat customers; a property with low frequency is more dependent on constantly attracting new visitors. Grocery-anchored centers typically show high frequency (multiple visits per month); fashion, home goods, and entertainment typically show lower frequency. **Interpreting frequency in context:** Always benchmark frequency against the property type. A grocery store with a frequency of 3.5 visits per month is performing normally; a lifestyle center with that same frequency would be exceptional. A mall with a frequency of 1.2 is normal; a convenience store with 1.2 would signal a problem. --- ## Trade Area Construction **Definition:** A trade area in REI is defined by actual visitor origin data, not assumed drive-time rings. It represents the geographic area from which a defined percentage of a property's visitors originate. **How it's built:** Advan identifies the home location of each visiting device using persistent overnight ping clustering over a rolling 3-week window — the area where the device is consistently detected during overnight hours. Those home locations are mapped and aggregated to produce a distribution of visitor origins. The trade area polygon is then drawn to capture a defined threshold of that distribution — typically the closest 70% of visitors by origin distance. **Threshold options:** The 70% threshold is the default and most commonly used. Lower thresholds (50%, 60%) produce a tighter "core" trade area; higher thresholds (80%, 90%) capture a broader catchment including less frequent long-distance visitors. The threshold should be chosen based on the use case — leasing conversations typically use 70–80%; cannibalization analysis may use 50–60% to identify core overlap. **Why this is different from drive-time rings:** Drive-time rings assume uniform behavior — that all customers within X minutes will visit equally. Actual trade areas are almost never symmetric. Highway access, competing properties, natural barriers, and neighborhood boundaries all distort the real catchment in ways that rings can't capture. Trade areas built from visitor origin data reflect where customers actually come from. **Home location attribution caveat:** Home attribution is based on overnight device behavior over a rolling 3-week window. Devices without reliable nighttime data, devices shared across household members, or frequent travelers may be attributed less precisely. At the aggregate trade area level, this uncertainty is minimal — it's most relevant when evaluating individual device-level data, which REI doesn't expose. **Plain-language explanation:** > "Instead of drawing a circle on a map, Advan's trade areas are built > from where visitors actually live. We figure out each visitor's home > by looking at where their device consistently shows up overnight over > a 3-week period, then map that to see the real geographic catchment. > That's why trade areas here are often irregular shapes — they follow > real behavior, not an assumed drive radius." --- ## Demographics **Definition:** Demographic data in REI characterizes the visitor population of a property — not the residents of the surrounding area. This is a critical distinction: REI demographics describe who is actually visiting, not who lives nearby. **Attribution methodology:** Once a visiting device's home location is identified via overnight clustering, Advan attributes demographics to that visitor using block-group level data from Synergos / Popstats. The demographic attributes of the visitor's home block group are applied to that visitor, and these are then aggregated across all visitors to produce a profile of the visiting population. **What this means in practice:** If a property in a working-class neighborhood is primarily visited by people from more affluent zip codes, REI demographics will reflect the more affluent profile — because it's showing who is actually visiting, not who lives nearby. This is why REI demographics often differ meaningfully from simple ring-based lookups and are more directly useful for retail merchandising and leasing decisions. **Lifestyle and psychographic segments:** REI uses Spatial.AI PersonaLive segments. Each PersonaLive segment represents a cluster of households with similar demographic characteristics, purchasing behavior, and lifestyle priorities, assigned at the block group level. Segments are applied to visitors based on their home block group and aggregated to characterize the visiting population's lifestyle profile. When explaining a specific PersonaLive segment to a user, describe it in plain terms — purchasing behavior, lifestyle priorities, retail affinities — rather than referencing the segment name alone. Don't assume the user knows what a segment label means. **Demographic data vintage:** Block-group demographic data from Synergos / Popstats is updated annually. --- ## Rankings and Benchmarking **How properties are ranked:** The peer set depends on what is being ranked: - **Retailers:** A retailer's locations are ranked against their own sister locations by default. Users can also compare against the retailer's broader industry category. - **Shopping centers:** Properties are ranked against other centers in the same GLA (gross leasable area) size tier. **The ranking metric:** The default ranking metric is total visit volume over the selected period. Users can switch to dwell time, visit frequency, visits per square foot, or unique visitors depending on what they're evaluating. **Geography options:** Rankings can be scoped to a geography the user selects. Available options include MSA, county, zip code, or a custom radius around an address. These are built from Census and USPS boundary definitions, or the user can draw a custom area. **Interpreting rank:** Rank is always expressed as "X of Y" — both the rank position and the total count are necessary for context. "3 of 8" and "3 of 340" are very different findings. --- ## Void Analysis Scoring **The void analysis endpoint scores potential tenant candidates against three dimensions:** **Candidate eligibility — location spacing filter:** Before scoring, Advan filters out retailers that already have a location too close to the subject site relative to their own network's typical spacing. Specifically, Advan calculates each retailer's average distance between their existing locations. Any retailer with an existing location closer to the subject site than that average inter-location distance is removed from the candidate set. This filters out brands where a new location would be structurally too close to an existing one — before cannibalization risk is even considered. **Cannibalization risk:** For retailers that pass the spacing filter, cannibalization risk is calculated from the shared customer percentage — what share of the subject site's visitors already visit a nearby location of that same brand. Higher shared customers means more of the potential customer base is already being captured by an existing location, increasing the risk that a new store would pull from existing volume rather than growing the brand's total reach. **Demographic match:** A score reflecting how well the trade area's visitor demographic profile aligns with the candidate's typical customer profile across its existing locations. Higher match means the customers at this property look more like the candidate's core shoppers. **How candidates are ranked:** Candidates that pass the location spacing filter are scored on cannibalization risk and demographic match and ranked relative to each other for the subject site — not against an absolute scale. --- ## Shared Customers and Cross-Shopping **Definition:** Shared customers measures the percentage of a property's visitors who also visited another specified property (or set of properties) within the same time period. It's a measure of cross-shopping behavior — how much the two locations' customer bases overlap. **Calculation:** For a given pair of properties A and B, shared customers = (devices that visited both A and B) / (devices that visited A), expressed as a percentage. The result is directional — shared customers from A to B is not necessarily the same as from B to A. **What it means:** High shared customers between a subject site and a retailer's existing locations indicates the trade area is already being served by that retailer — useful for gauging demand, but also a signal worth watching for cannibalization risk. Low shared customers may indicate an untapped customer pool or a meaningfully different visitor base. **Retailer-level shared customers:** When `shared-customers-retailer` is used, the comparison is against all locations of a brand within a defined radius, rather than a single property. This gives a more complete picture of the brand's penetration in the trade area. --- ## Sales Data and Transaction Intelligence Advan maintains a panel of approximately 100 million debit and credit cards that enables estimation of basket size and both online and offline sales. This data can be used to go beyond foot traffic — connecting visit behavior to spending behavior and revenue estimation. When a user asks about sales data, revenue estimates, basket size, or transaction-level intelligence, let them know this capability exists and route them to the support team for a fuller discussion. > "Advan has a panel of roughly 100 million debit and credit cards that > we use to estimate basket size and online and offline sales. It's a > natural complement to the foot traffic data. Our support team would be > happy to walk you through what's available — want me to send them a > note?" --- ## Data Freshness and Update Cadence **Update schedule:** REI data is refreshed every Wednesday with a 3-day lag. This means data through the end of the prior week is typically available by Wednesday of the following week. **Historical depth:** REI data is available going back to 2017. Data prior to 2017 exists but is considered less reliable due to smaller panel size during that period — flag this if a user is comparing across a very long time horizon that includes pre-2017 data. **Date range recommendations:** - For trend analysis: 12–24 months trailing is the standard window. - For YoY comparison: match periods of equal length and the same calendar months to control for seasonality. - For a current snapshot: the most recent complete month is the standard reference; the current partial week may undercount relative to prior complete periods. **Plain-language explanation for users asking about data recency:** > "REI data updates every Wednesday, typically reflecting activity through > the end of the prior week. So on any given Wednesday, you're looking at > data that's about 3 days old. Historical data goes back to 2017." --- ## Data Coverage and Limitations **Geographic coverage:** Advan's panel covers the U.S. and Canada. Additional international data is available outside the standard REI platform — users interested in international coverage should contact Advan's support team for options. **Property coverage:** There are a few specific reasons a property may not have traffic data in REI: - **Vertical stacking:** REI does not include traffic for POIs that have another POI directly above or below them in the same structure. Because only 10–15% of the mobile panel provides elevation data, Advan cannot reliably distinguish which floor a device is on — so vertically stacked locations are excluded from the standard platform to avoid misattribution. Data for these locations can often be pulled outside of REI; direct users to contact Advan's support team if they need it. - **Outdated satellite imagery:** Geofences are built from satellite imagery. If a location's imagery is outdated or the property boundary cannot be defined with confidence, the location will not have a geofence and therefore will not have traffic data. If a user needs a location that isn't currently available, they have two options: request that Advan add it (support team), or draw their own polygon using the Add Location tool in REI's header bar. > "That location isn't showing traffic data in REI — that usually means > it's either in a multi-story building where elevation data is limited, > or its boundary hasn't been defined yet. You can draw your own polygon > using Add Location in the header, or I can send a request to Advan's > team to get it added." **No default dwell filter — implication for comparisons:** Because REI applies no minimum dwell threshold by default, visit counts include all device detections within a geofence, including very short-duration detections. When comparing a REI visit count to data from another source that applies a minimum dwell filter, the counts may not be directly comparable. Always flag this if a user is cross-referencing REI data against other datasets. **Panel representativeness:** Mobile location data is directional and representative by nature — Advan's panel of approximately 20% of the U.S. population is structured to reflect the broader population across demographics and geographies. As a general principle, the larger the property and the higher the surrounding population density, the closer visit counts tend to track to ground truth. Smaller or lower-traffic locations will be directionally accurate but may have more variability in absolute counts. --- ## Handling Methodology Questions Beyond This Reference If a user asks a technical methodology question not covered here — about a specific algorithm, the exact inputs to a score, proprietary weighting details, or something that requires Advan's internal documentation — don't speculate. > "That's a level of methodological detail I don't have on hand. I can > send this to Advan's support team if you'd like a precise answer — > they'll have the technical documentation." Offer to escalate per the standard support escalation workflow. Don't invent details to fill the gap.
retailer-footprint14.6 KB
--- name: retailer-footprint description: > Workflow for comparing a subject property to a retailer's or category's existing location footprint using Advan REI's retailer footprint endpoint. The endpoint aggregates all of a retailer's or category's locations within a defined radius of the subject site and compares them across foot traffic variables, demographics, shared customers, and demographic match score. Use this skill whenever a user wants to know how a property compares to a retailer's typical location, whether a site fits a retailer's footprint, how similar a candidate site is to where a retailer already succeeds, or wants to evaluate a retailer's presence in a market area. Trigger on phrases like "how does this site compare to [retailer]'s locations", "does this fit [retailer]'s footprint", "retailer footprint", "how does this property benchmark against [retailer]", or any request that involves comparing a site to a specific retailer's or category's existing locations. Also trigger as part of site selection when a specific retailer is named. --- # Retailer Footprint Workflow This skill has two modes depending on whether the user has a subject site: - **Site comparison mode:** A subject site is provided. Compare it against the retailer's or category's nearby locations to assess fit. - **Nationwide profile mode:** No subject site. Summarize the retailer's or category's footprint nationally, with the option to compare across geographies. Determine the mode from context before proceeding. If a subject site has been established earlier in the conversation, default to site comparison mode. If the user is asking about a retailer's footprint generally — "what does [Retailer]'s typical location look like?", "how does [Retailer] perform nationally?", "walk me through [Retailer]'s footprint" — use nationwide profile mode. --- ## Mode A: Site Comparison ### Step 1: Confirm the Inputs Two inputs are required before calling the endpoint. If either is missing, ask — don't proceed with assumptions. **Subject site:** Resolve using ALI, location name, and company name as usual. **Retailer or category:** Who are we comparing against? This could be a specific brand (Trader Joe's, TJ Maxx) or a broader category (grocery, off-price apparel, fitness). If the user named one, use it. If the request is ambiguous — "how does this compare to similar retailers" — ask them to specify before proceeding. **Date range:** Use the UI selection or whatever the user specified. **Distance:** Default is 100 miles. Don't change it yet — Step 2 will determine whether an adjustment is warranted after seeing how many locations the endpoint returns. --- ## Step 2: Call the Endpoint and Assess the Footprint Size Call the retailer footprint endpoint with the subject site, retailer/category, 100-mile radius, and date range. Before interpreting the results, check how many locations were returned. Footprint size directly affects how reliable the aggregate comparison is. ### Too few locations (fewer than 5) A comparison built on fewer than 5 locations is statistically fragile — one unusual store can skew the entire aggregate. Flag this to the user and recommend widening the radius before drawing conclusions. > "The 100-mile radius only captured 3 [Retailer] locations, which may not > give a reliable picture of their typical footprint. I'd suggest widening > to 150 or 200 miles for a more stable comparison — want me to rerun it?" Don't present the comparison results as meaningful if the location count is this low unless the user explicitly wants to proceed anyway. ### Healthy footprint (5–30 locations) This is the reliable range. Proceed to interpretation. ### Large footprint (more than 30 locations) A large footprint isn't necessarily a problem — a national retailer with dense coverage may legitimately have 50+ locations in range. But it's worth flagging that the aggregate is averaging across a wide geography and possibly diverse market types, which can mask variation. Note the count, proceed with the comparison, and proactively offer location-level data so the user can see the distribution if the aggregate picture feels too averaged. > "There are 47 [Retailer] locations within 100 miles — the footprint > comparison reflects a broad average across diverse markets. I can also > pull individual location data if you want to see which specific stores > are most similar to this site." --- ## Step 3: Interpret the Comparison Results The endpoint compares the subject site against the retailer footprint across several dimensions. Here's how to read each one: **Overall demographic match score:** The headline fit signal. A high match means the subject site's visitor profile resembles the retailer's typical customer base. A low score doesn't automatically disqualify the site — it may mean the retailer hasn't tapped this customer type yet — but it warrants explanation. **Foot traffic variables (visits, dwell time, visit frequency, hour/day patterns):** - *Visit volume:* Is the subject site attracting traffic at a level comparable to the retailer's typical locations? Significantly lower volume may indicate the site underperforms as a draw; significantly higher may signal strong opportunity or a different use pattern. - *Dwell time:* A subject site with lower dwell than the retailer's footprint suggests visitors aren't spending the kind of time the retailer's model typically requires. This is a meaningful signal for retailers that depend on browse time (specialty, home goods, apparel). - *Visit frequency:* A site with lower frequency than the retailer's footprint may not generate the repeat customer pattern the retailer depends on — especially relevant for grocery, fitness, and other high-frequency categories. - *Hour and day patterns:* Does the subject site peak at the same times as the retailer's typical locations? A mismatch here — a site that peaks weekday mornings vs. a retailer that depends on weekend afternoon traffic — is a behavioral fit concern even if volume looks fine. **Shared customers:** What percentage of the subject site's visitors also visit the retailer's nearby locations? High shared customers means the retailer is already drawing from this trade area — which could indicate strong demand, or that an existing nearby location may cannibalize a new one. Low shared customers may indicate an untapped customer pool or a genuinely different visitor base. **Reading convergent vs. divergent signals:** - Strong match across demographics, traffic behavior, and shared customers → high-confidence fit. The site looks like the retailer's wheelhouse. - Strong demographic match but divergent traffic behavior → the customer is there, but the site doesn't drive the behavior the retailer's model relies on. Worth flagging as a risk. - Strong traffic behavior match but low demographic match → the location performs similarly, but the customer profile differs. May work depending on the retailer's flexibility, but flag the divergence. - Low shared customers + strong demographic match → the retailer may not have meaningful penetration in this trade area. Could be opportunity, could be an indication the customer here behaves differently than expected. - Low across all dimensions → be direct. The site doesn't profile as a strong fit based on the available data. --- ## Step 4: Offer Location-Level Data (When Warranted) Proactively offer individual location data in these situations: - The footprint is large (30+ locations) and the aggregate may be masking useful variation - The comparison results are mixed or show meaningful divergence on some dimensions — knowing which specific locations are closest to the subject site helps calibrate the finding - The user is trying to identify the most analogous existing location (useful for site visits, case studies, or leasing conversations) - Cannibalization risk is a concern — seeing the individual nearby locations and their traffic profile is more useful than an aggregate When pulling individual location data, surface the locations ranked by similarity to the subject site on the dimensions that matter most for the user's question. --- ## Step 5: Present Results ### Lead with the headline fit assessment One clear sentence on overall fit based on the convergent signals. > "On balance, [Subject Site] profiles as a strong fit for [Retailer] — > the demographic match is high, dwell time and frequency are consistent > with their footprint, and the traffic pattern aligns with their peak > periods." Or if the picture is mixed: > "[Subject Site] matches [Retailer]'s demographic profile well but shows > meaningfully lower visit frequency than their typical locations — worth > considering for a retailer that depends on repeat traffic." ### Comparison summary table Always include these four dimensions — they are the core fit signals: | Dimension | Subject Site | Retailer Footprint Avg | Assessment | |-----------|-------------|----------------------|------------| | Demographic match | X | — | High / Med / Low | | Avg dwell time | X min | X min | At / Above / Below footprint | | Avg visit frequency | X | X | At / Above / Below footprint | | Shared customers | X% | — | High / Moderate / Low | If the data supports it and the user's question warrants it, extend the table with additional dimensions: | Dimension | Subject Site | Retailer Footprint Avg | Assessment | |-----------|-------------|----------------------|------------| | Peak day of week | [Day] | [Day] | Aligned / Divergent | | Peak hour | [Hour] | [Hour] | Aligned / Divergent | | Visits by radius (1/3/5 mi) | X / X / X | X / X / X | At / Above / Below footprint | | Visits by drive time (5/10/15 min) | X / X / X | X / X / X | At / Above / Below footprint | | Distance to nearest footprint location | X mi | — | — | Add the extended rows when visit timing or proximity to existing locations is relevant to the user's question — site selection, cannibalization evaluation, or when the core table shows a divergence that the time/day pattern might explain. Skip them when the core four tell a clear enough story on their own. ### Narrative Two to three sentences connecting the dimensions into a coherent read. Highlight where signals converge and call out any meaningful divergences. Reference the footprint location count so the user knows how robust the comparison is. ### Cite data vintage and footprint parameters > *Comparison based on [date range] using [N] [Retailer] locations within > [X] miles, via Advan's mobile device panel.* --- ## Mode B: Nationwide Profile (No Subject Site) Use this mode when the user wants to understand a retailer's or category's footprint in general — not in comparison to a specific property. ### Step 1: Confirm the Retailer or Category Confirm who the user wants to profile. If a specific brand or category hasn't been named, ask before proceeding. **Date range:** Use the UI selection or whatever the user specified. ### Step 2: Pull and Summarize the Nationwide Footprint Call the endpoint without a subject site to retrieve the nationwide profile. Summarize the retailer's or category's typical location characteristics across the core dimensions: - **Traffic profile:** Average visits, dwell time, and visit frequency across locations. Note the range if there's meaningful variation. - **Peak patterns:** Typical peak day of week and hour — this characterizes the retailer's operational pattern (destination weekend shopper vs. weekday convenience stop, etc.). - **Demographic profile:** The typical customer across the full set of dimensions: median household income, dominant age cohort, primary ethnicity/race composition, educational attainment, population density of the trade area (urban core, suburban, exurban), and standout lifestyle segments that define the retailer's core customer base. - **Visit distribution by radius and drive time:** How far the typical customer travels. This characterizes the retailer as a convenience, neighborhood, or destination concept. - **Location count and geographic spread:** How many locations are in the dataset and whether coverage is national, regional, or concentrated. ### Step 3: Offer Geographic Comparison After presenting the national summary, offer to break it down by geography. This is most useful when the user is evaluating a specific market, comparing regions, or assessing whether the retailer performs differently across market types. > "That's the national picture. Want me to compare how [Retailer] performs > across specific markets or regions — for example, how their Northeast > locations compare to their Sun Belt footprint?" Geographic comparisons to offer based on context: - **Metro vs. metro:** How does [Retailer] perform in [Market A] vs. [Market B]? - **Regional:** How does the Northeast footprint compare to the Southeast, Midwest, or West? - **Urban vs. suburban vs. exurban:** Does the retailer's profile shift meaningfully by market density? - **Custom geography:** If the user specifies a region, state, or set of markets, pull and compare those directly. ### Step 4: Present the National Summary ### Headline One sentence characterizing the retailer's typical location. > "[Retailer] operates primarily as a [destination / neighborhood / > convenience] concept, drawing customers from a [X]-minute drive on average, > with a customer base skewing [demographic summary] and peak traffic on > [day/time]." ### National footprint table | Dimension | Retailer Avg | |-----------|-------------| | Avg monthly visits | X | | Avg dwell time | X min | | Avg visit frequency | X | | Peak day | [Day] | | Peak hour | [Hour] | | Visits within 1/3/5 mi | X% / X% / X% | | Visits within 5/10/15 min drive | X% / X% / X% | | Median household income | $X | | Dominant age cohort | X–Y | | Primary ethnicity / race | [Top 1–2] | | Educational attainment | [e.g., College-educated majority] | | Population density | [Urban / Suburban / Exurban] | | Top lifestyle segments | [Top 2–3] | | Locations in dataset | N | If geographic comparisons were requested, add a column per geography. ### Cite data vintage > *Based on [date range] across [N] [Retailer] locations nationally, via > Advan's mobile device panel.* --- ## Follow-Ups For site comparison mode, the most natural next steps are pulling individual location data (if not already done), running a void analysis to see where this retailer ranks as a candidate for the center, or checking cannibalization risk if shared customers came back high. For nationwide profile mode, a geographic breakdown or a comparison against a specific candidate site are the natural directions. Let the conversation lead.
site-selection12.2 KB
--- name: site-selection description: > Structured workflow for evaluating one or more candidate retail locations using Advan REI foot traffic, trade area, competitive, and cross-shopping data. Use this skill whenever a user is assessing whether a site is a good fit for a retailer or tenant, comparing multiple candidate locations, evaluating market demand at a specific address, or analyzing cannibalization risk from a nearby existing store. Trigger on phrases like "should we open here", "evaluate this site", "compare these locations", "is this market viable", "how does this site stack up", "would this cannibalize our existing store", "what's the co-tenancy like", or any request that frames a location decision. Also trigger when a broker, retailer, or developer asks about a site's potential without using explicit site selection language. --- # Site Selection Workflow Site selection answers a decision question: is this a good location, and for whom? The workflow is data-driven but ends with a directional take — not just a data dump, but a read on what the numbers mean for the decision at hand. The workflow has two modes depending on what the user is evaluating: - **Single site:** Full analysis of one candidate location. - **Multi-site comparison:** Run the same analysis for each site, then synthesize a side-by-side at the end. Both modes follow the same stages. For multi-site, run all stages for each location before moving to synthesis. --- ## Before You Start: Orient the Request Before pulling data, make sure you understand three things. You may already have them from context — if so, proceed. If not, ask one focused question rather than a list. 1. **What location(s) are being evaluated?** An address, a named property, a market area? 2. **Is there a specific retailer or tenant in mind?** This drives the co-tenancy and cannibalization steps. If no retailer is specified, those steps are still useful but framed more generally. 3. **What's the decision?** Opening a new store, evaluating a lease, advising a client, underwriting a development? The answer shapes what you emphasize in the synthesis. --- ## Stage 1: Resolve the Location(s) If the user named a specific existing property, use ALI, location name, and company name as usual. If they provided an address or a general description of a candidate site, use `search` to find the closest matching property or reference location. Confirm before proceeding if there's any ambiguity. For multi-site comparisons, resolve all locations before moving to Stage 2. --- ## Stage 2: Subject Site Performance If the candidate site is an existing property with traffic data (an occupied center, a current tenant location), pull `traffic-summary` for it. This establishes baseline performance at this specific location and gives the user a sense of what the site has historically attracted. If the site is vacant, a raw address, or a new development with no existing traffic history, skip this step and note it. The trade area and competitive context in later stages will carry the location assessment. Use the date range from the UI or as specified by the user. --- ## Stage 3: Trade Area Call `trade-area` using the same parameters established in any current session trade area settings, or default to the closest 70% of visitors if no setting is available and the user hasn't specified otherwise. This tells you who is realistically accessible from this location. Capture: - Approximate size (radius or drive time) - The geographic shape — is it symmetric, or constrained by highways, water, or dense competition on one side? You don't need to run the full demographic deep-dive here unless the user asked for it — that's covered in a standalone trade-area-analysis. For site selection, the key output is the catchment footprint and a top-line demographic read (median HHI, dominant age cohort) to assess fit with the intended tenant. --- ## Stage 4: Competitive Landscape Use `ranking` and/or `performers-list` to identify how competing properties in the area are performing. Then pull `traffic-summary` for the most relevant competitors — typically the 2–3 strongest nearby alternatives that would be drawing from the same trade area. What you're looking for: - Is there a dominant competitor already capturing the majority of foot traffic in this catchment? - Are there underperforming competitors that might signal market weakness — or an opportunity if the right tenant fills the gap? - How does traffic at nearby properties trend? Growing markets tend to lift well-positioned sites; declining markets carry more risk regardless of individual site quality. Flag the competitive intensity plainly. A site surrounded by strong performers in the same category is a much harder entry than one where competition is fragmented or underperforming. --- ## Stage 5: Co-Tenancy and Cross-Shopping Use `shared-customers` or `shared-customers-retailer` to understand what other retailers the visitors in this trade area frequent. If a specific retailer or tenant is in mind, this step answers: are the customers already here aligned with that retailer's typical shopper? Look for strong affinity with anchor tenants or complementary categories that would support the intended use. If no specific retailer is named, use this step to characterize the trade area's retail DNA — what categories and brands dominate customer behavior — and flag whether the site has the co-tenancy to support the type of use the user is evaluating. **Co-tenant health check:** For the most significant co-tenants at or near the candidate site, pull `traffic-summary` and `ranking` to assess whether they are strong performers. A site with declining or underperforming anchors is a materially different proposition than one with healthy, growing co-tenants. Look for: - YoY traffic trend for key co-tenants — growing, flat, or declining? - Ranking within their submarket or category — are they top performers or laggards? - Any co-tenant weakness that could signal a future anchor departure or reduced draw Flag co-tenant risk directly if the data shows it. A retailer opening next to a struggling anchor takes on indirect risk that isn't visible in the site's own trade area data. --- ## Stage 6: Cannibalization Check (Conditional) Run this step only if both of the following are true: - A specific retailer or brand is identified as the potential tenant. - That retailer has one or more existing locations within a plausible draw distance from the candidate site (typically within the trade area or overlapping trade area). If both conditions are met: 1. Pull `traffic-summary` for the existing nearby location(s) of the same brand. 2. Pull `trade-area` for the existing location(s) and compare the geographic overlap with the candidate site's trade area. 3. Estimate the degree of overlap: do the two trade areas share significant geography? If the candidate site's trade area is largely contained within the existing location's trade area, cannibalization risk is high. If there's limited overlap — the sites serve distinct neighborhoods or the candidate site extends reach into a new population — risk is lower. Present the cannibalization finding clearly and without burying it. If the overlap is significant, the user needs to know before making a decision. > "The candidate site's trade area overlaps substantially with the existing > [Brand] at [Location] — roughly [X]% of the potential customer base is > already being served. That doesn't rule out this site, but it means the > incremental opportunity is smaller than the raw trade area would suggest." If the conditions aren't met, skip this step entirely — don't raise cannibalization as a concern if there's no nearby same-brand location to evaluate against. --- ## Stage 7: Comparable Benchmarking Use `ranking` to benchmark the candidate site — or the most comparable existing property at or near it — against similar properties in the market. This establishes whether this location is performing at, above, or below what you'd expect for the submarket. For a multi-site comparison, this is where you start to see which site sits in the stronger performing market and which has the better trajectory. --- ## Stage 8: Retailer Footprint Fit (Conditional) Run this stage only if a specific retailer is named. Skip it if the analysis is general or the tenant is unspecified. Invoke the **retailer footprint skill** in site comparison mode, using the candidate site as the subject property and the named retailer as the comparison target. That skill handles all data pulls and interpretation — don't re-implement the logic here. For a multi-site comparison, run the retailer footprint skill for each candidate site and carry the fit assessment (strong / moderate / weak) into the Stage 9 synthesis. This stage frequently produces the clearest differentiation between sites: which one's behavioral and demographic profile most closely matches where the retailer already succeeds. --- ## Stage 9: Synthesize and Present ### Search for real-world context Do a targeted web search before writing the synthesis. Useful angles for site selection: - Recent retail openings, closings, or announced deals in the submarket - Development pipeline — new supply coming that could affect the competitive picture - Local economic conditions, employment base, population growth - Any news specific to the retailer being evaluated (expansion plans, category performance, brand momentum) - Infrastructure changes — new transit, road projects, or access changes that could affect the catchment Weave in what's relevant. Skip what isn't. ### Lead with the directional take Don't open with a table. Open with a clear read on what the data says about this site. > "Based on the data, [Location] looks like a credible opportunity for > [Retailer/Use]. The trade area is well-populated and the competitive set is > fragmented — no dominant player is locking up this catchment. The main > risk is [X]." Or if the picture is mixed: > "[Location] has a strong trade area but faces meaningful competitive > pressure from [Competitor], which is already capturing a large share of > foot traffic in the immediate catchment." Be direct. The user is making or informing a decision — they need a clear signal, not just a list of considerations. ### Summary table | Factor | Finding | |--------|---------| | Subject site traffic | [X visits / period, +/-Y% YoY — or N/A if vacant] | | Trade area size | ~X miles / Y-min drive (Z% threshold) | | Trade area HHI | $X median | | Competitive intensity | [Low / Moderate / High] — [brief note] | | Top cross-shopping affinity | [Brand/category] | | Cannibalization risk | [Low / Moderate / High — or N/A] | | Submarket rank | #X of Y comparable properties | | Retailer footprint fit | [Strong / Moderate / Weak — or N/A] | For multi-site comparisons, run this table with one column per site so the user can compare directly. ### Supporting narrative Two to four sentences covering what the numbers mean together. Highlight convergent signals (multiple data points pointing the same direction) and flag any divergence (e.g., strong trade area demographics but high competitive saturation). If external context from the web search adds something meaningful, work it in here. ### Cite data vintage > *Analysis based on [date range], via Advan's mobile device panel.* --- ## Handling Gaps **No traffic data for the candidate site:** Common for vacant or new locations. Note it, skip Stage 2, and let the trade area and competitive data carry the assessment. **No nearby same-brand locations for cannibalization:** Skip Stage 6 without comment — don't raise it as a concern when there's nothing to evaluate. **Partial competitive data:** Present what's available, note what's missing, don't fill gaps with speculation. --- ## Follow-Ups Let the conversation lead. The most natural next steps from a site selection analysis are usually a full demographic breakdown of the trade area, a void analysis to identify which tenant categories would fit the customer base, or a deeper competitive pull on a specific competitor that came up in the data. Mention one if it's obviously relevant — otherwise let the user direct.
trade-area-analysis7.1 KB
--- name: trade-area-analysis description: > Workflow for defining and analyzing the trade area of a retail property using Advan REI mobile visitor origin data. Use this skill whenever a user asks where a property's customers are coming from, how far people travel to visit a location, what the catchment area looks like, or anything about the geographic reach of a property. Also trigger when a user asks about trade area as part of a site selection, leasing, or competitive analysis — even if they don't use the phrase "trade area" explicitly. Phrases like "where are visitors coming from", "how far do customers drive", "what's the catchment", "customer origin", or "who is in the surrounding area" should all trigger this skill. Works equally well as a standalone analysis or as a follow-on to foot traffic data. --- # Trade Area Analysis Workflow The trade area analysis answers a different question than foot traffic: not how many people visit, but *where they come from*. The output is geographic — a picture of the real catchment area built from actual visitor origin data, not assumed drive-time rings. The workflow has four stages: resolve the property, pull the trade area and characterize its size, layer in a demographic snapshot, and synthesize with real-world context. --- ## Stage 1: Resolve the Property Same as foot traffic. If the user has already provided or confirmed an ALI, location name, and company name — or if these were established earlier in the conversation — carry them forward and proceed. If the property is ambiguous, use `search` to find it, present the top results, and confirm before pulling data. --- ## Stage 2: Pull the Trade Area Call `trade-area` with the resolved property identifiers. **Parameters:** Determine the threshold in this order: 1. **User specified it in the conversation** (e.g., "show me the 50% trade area", "use the 80% catchment") → use that, regardless of app settings. 2. **User is in the REI app and hasn't specified** → use whatever threshold they have configured in their trade area settings. 3. **No app, no specification** → default to the closest 70% of visitors. **Date range:** Use the period the user has selected in the UI, or whatever they've specified. Only ask if it's genuinely unclear. ### Characterize the size The trade area is defined by where visitors actually originate, not by an artificial ring — but users need a tangible sense of scale. From the returned data, derive and report the approximate size in one of these terms, whichever is most natural given the geography: - **Radius:** "The trade area extends roughly X miles from the property" - **Drive time:** "Most visitors are within a Y-minute drive" - **Both:** Use both when the shape is notably asymmetric or the market warrants it (e.g., a coastal or highway-adjacent location where drive time and radius diverge meaningfully) If the trade area is unusually compact or unusually large relative to what you'd expect for the property type, flag it — it may reflect a dense urban setting, strong competition nearby, or a destination-oriented tenant mix. --- ## Stage 3: Demographic Snapshot Call `demography` for the trade area using the same property and date range. By default, surface a concise top-line snapshot — enough to characterize who's in the catchment without overwhelming the response. Focus on the signals most relevant to a real estate or retail professional: - Median household income (and whether it skews upper/lower relative to the metro) - Dominant age cohort(s) - One or two standout lifestyle or psychographic segments if they're meaningfully concentrated End the snapshot with a natural offer to go deeper: > "Want me to break this down further by income band, age distribution, or > lifestyle segment?" Don't pull `demography-categories` unless the user asks for the full breakdown — it's there for drill-down, not the default view. --- ## Stage 4: Synthesize and Present ### Search for real-world context Before writing the narrative, do a targeted web search to find anything that helps explain or enrich what the data is showing about the catchment. Useful angles include: - Economic character of the trade area (affluent suburb, dense urban core, working-class exurb, etc.) - Major employers or demand generators within the catchment - Population growth or demographic shifts in the area - Infrastructure or access factors that shape the catchment (highways, transit, topographic barriers) - Competitive landscape — are there strong competitors drawing from the same geography? As with foot traffic: if the search turns up something that connects, weave it in. If it doesn't, move on. The goal is context that helps the user interpret the trade area, not filler. ### Lead with the headline One sentence that captures the essential story — size, character, and anything notable. > "Riverside Commons draws the bulk of its visitors from a roughly 4-mile > radius, a trade area anchored by the upper-middle-income neighborhoods of > Maplewood and Crestview, with a median household income around $95K." ### Trade area summary After the headline, a short structured summary: | | | |---|---| | Trade area threshold | 70% of visitors (or whatever was used) | | Approximate size | X miles / Y-minute drive | | Median HHI | $X | | Dominant age cohort | X–Y | | Key lifestyle segments | [top 1–2] | Keep this tight. The table is a reference, not the analysis. ### Narrative Two to three sentences connecting the geographic and demographic picture to something actionable. What does this trade area mean for the property? Think about: - Whether the catchment is concentrated or dispersed (and what that implies for co-tenancy or marketing reach) - Whether the demographic profile aligns with the current tenant mix — or suggests an opportunity - Any geographic constraint or advantage worth flagging (a highway that extends reach to the east, a river that cuts it off to the west) - Anything from the web search that adds color ### Cite data vintage > *Trade area and demographics based on [date range], via Advan's mobile > device panel. Trade area defined as the closest [X]% of visitors by origin > (per [user's REI app settings / default threshold].)* --- ## Handling Gaps and Anomalies **No trade area data returned:** Say so plainly and offer to escalate or check a comparable. **Unusually small or large catchment:** Flag it and offer a hypothesis if one is obvious from context (dense competition, destination anchor, barrier geography). Don't just report it as a fact without comment. **Demographic data sparse or incomplete:** Present what's available, note the gap, don't fill it with estimates. --- ## Follow-Ups If there's a natural next direction given what the data showed, mention it. The most common ones that arise organically from trade area work are cross-shopping (who else in the catchment are these visitors going to?), void analysis (what tenant categories are underrepresented given this demographic profile?), and competitive context (how does this catchment compare to a neighboring center?). But let the conversation lead — don't recite options.
void-analysis7.21 KB
--- name: void-analysis description: > Workflow for identifying tenant candidates that would fit a vacancy or underrepresented category at a retail center, using Advan REI's void analysis endpoint enriched with traffic health and expansion signal data. Use this skill whenever a user asks what tenants would work at a center, what's missing from a property's tenant mix, who should fill a vacancy, what categories are underrepresented, or whether a specific retailer type would be a good fit. Trigger on phrases like "what tenants would work here", "who should fill this space", "what's missing from this center", "void analysis", "tenant candidates", "what categories make sense here", or any request about filling a vacancy or improving a center's tenant mix. --- # Void Analysis Workflow The void analysis endpoint does the core analytical work — it returns tenant candidates ranked by dynamic distance, cannibalization risk, and demographic match. This skill's job is to gather the right parameters before calling it, filter out candidates that don't belong in a retail center context, enrich the top results with real-world health and expansion data, and present the output in a way that's actually useful for a leasing decision. --- ## Step 1: Gather Parameters Before calling the endpoint, confirm two things. If either is missing from the conversation, ask — these directly affect the quality of the results. **Vacancy size:** What is the approximate square footage of the space? This is the most important filter. A 1,200 sq ft inline space and a 45,000 sq ft anchor box should return completely different candidate sets. If the user hasn't specified, ask before proceeding. **Category preferences or exclusions (optional):** Has the user indicated they're looking for a specific category (food & beverage, fitness, soft goods) or want to exclude something? If so, note it — you'll apply it when filtering results. If no preference is stated, proceed with the full results and apply the standard retail center filter described in Step 3. Also confirm the property using ALI, location name, and company name as usual. --- ## Step 2: Call the Void Analysis Endpoint Call `void-analysis-api` with the resolved property identifiers and vacancy size parameter. Use the date range from the UI or as specified by the user. The endpoint returns a ranked list of tenant candidates scored on: - **Dynamic distance** — how far the candidate's typical locations are from this trade area's profile - **Cannibalization risk** — likelihood of pulling from an existing nearby location of the same brand - **Demographic match** — how well the trade area's visitor profile aligns with the candidate's typical customer base --- ## Step 3: Filter for Retail Center Appropriateness The endpoint returns candidates across a broad range of categories. Before presenting results, remove any candidates that don't belong in a traditional retail center context. Categories to omit by default: - Auto dealers, car washes, and auto service - Hotels and lodging - Hospitals, urgent care, and large medical facilities (small-format urgent care or dental that fits inline retail is fine) - Gas stations and fuel retailers - Industrial, warehouse, or self-storage uses - Large-format government or civic uses Use judgment for edge cases. A drive-through-only concept with no inline presence, for example, may not fit a traditional center even if it scores well on demographics. If the user has specified a category preference, apply that filter here too — prioritize their stated criteria over the default list. --- ## Step 4: Filter by Vacancy Size From the filtered results, narrow to candidates whose average store footprint is compatible with the vacancy. A reasonable match range is ±30% of the vacancy size unless the user specifies otherwise. Flag if the vacancy size is unusual — a very large anchor box or a very small kiosk-scale space may return a thin candidate set, and it's worth noting that upfront rather than presenting a short list without explanation. --- ## Step 5: Present Results ### Lead with a brief framing One or two sentences on what the analysis surfaced — is the candidate pool strong, thin, concentrated in a particular category? > "The void analysis surfaces eight strong candidates for the 4,200 sq ft > space, with the clearest opportunities in specialty food, health & wellness, > and value apparel — all categories underrepresented in this trade area > relative to the visitor demographic profile." ### Candidate table | Rank | Tenant | Category | Avg Store Size | Demographic Match | Cannibalization Risk | |------|--------|----------|---------------|-------------------|----------------------| | 1 | | | X sq ft | High/Med/Low | High/Med/Low | Present the top 25 from the filtered, size-matched list, or fewer if the list is shorter. Don't pad the table with weak candidates just to fill rows. After the table, offer to expand to the full unfiltered list if the user wants to see everything the endpoint returned before category and size filtering was applied. ### Brief narrative Two to three sentences on the standout candidates and any patterns worth flagging — a category cluster that keeps appearing, a size mismatch that limits the field, or a category that keeps appearing near the top of the rankings. ### Cite data vintage > *Void analysis based on [date range], via Advan's mobile device panel.* --- ## Handling Thin Results If filtering by category and size leaves fewer than three candidates, say so and offer options: widen the size range, broaden the category filter, or look at what the full unfiltered list shows. Don't present a weak list as if it's comprehensive. --- ## Follow-Ups After presenting the candidate table, offer to enrich the top candidates with two additional signals. This is the natural next step for any candidate the user wants to pursue seriously — don't do it by default, since it requires multiple additional data pulls and web searches. > "Want me to dig deeper on the top candidates? I can pull traffic health > and expansion signals for each one — that'll tell you which are actively > growing and whether any have announced a leasing pause or contraction." When the user confirms, enrich up to 5 candidates: **Traffic health:** Pull `traffic-summary` and `ranking` for each candidate's existing nearby locations. Note each candidate's trajectory — growing, stable, or declining — alongside their void score. **Expansion signals:** Do a targeted web search for each candidate: "[Retailer name] expansion [year]" or "[Retailer name] new locations" or "[Retailer name] leasing activity". Flag any candidate that has announced closures or a leasing pause — a strong analytical score doesn't matter if they're not actively opening stores. Present the enriched results by adding Trajectory and Expansion Signal columns to the original table for the enriched rows, then update the narrative. If a specific candidate looks strong and the user wants to go deeper beyond enrichment, the natural next steps are pulling that retailer's full traffic profile, checking their trade area overlap with the subject property, or running a co-tenancy check to see how well they'd complement the existing tenant mix. Let the conversation lead.
Package details
Publisher declarations from the archived package. These are separate from our research and the live service's terms.
- Package author
- Advan Research
Package observed Oct 2, 2026.
Technical details
- First seen
- Oct 1, 2026 · 18:00 UTC
- Last seen
- Oct 2, 2026 · 06:00 UTC
- Collection status
- Collected
plugin_asdk_app_6aa8203d5a04819195420ba31e115000
Download plugin data (JSON)