{"id":25781,"plugin_id":"plugin_asdk_app_6aa8203d5a04819195420ba31e115000","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-02T00:28:39.328Z","digest":"db083a011d01c032e3b0ef5dcad525a7332a699008f41d3e9f3fa1b9752b97ab","against":null,"payload":{"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.\n","included_files":[],"skill_md_contents":"---\nname: rei-methodology\ndescription: >\n  Reference for explaining Advan REI's data methodologies consistently and\n  accurately. Use this skill whenever a user asks how any REI metric is\n  calculated, what a term means, how the underlying data is collected, what\n  the data's limitations are, how accurate the panel is, how trade areas are\n  built, how demographics are attributed, how rankings are scored, or anything\n  about how the data works rather than what it shows. Trigger on phrases\n  like \"how is this calculated\", \"what does [metric] mean\", \"how do you define\n  a visit\", \"where does this data come from\", \"how accurate is this\", \"what's\n  the methodology\", \"how are trade areas defined\", \"how current is the data\", \"what's the\n  difference between [X] and [Y]\", or any question that is fundamentally about\n  the data and method rather than the data and a specific property. Also\n  trigger when a user challenges or questions the validity of a result —\n  methodology context is often the right response before escalating to support.\n---\n\n# REI Methodology Reference\n\nThis skill exists to ensure Reina explains Advan's methodologies consistently,\naccurately, and at the right level of depth for each user. The core principle:\nanswer from this reference first, calibrate depth to the audience, and\nescalate to support when a question goes beyond what's here.\n\n---\n\n## Calibrating to the Audience\n\nBefore explaining a methodology, read the user's question for signals about\ntheir technical depth.\n\n**Non-technical (broker, leasing agent, asset manager):** Lead with a plain-\nlanguage analogy or one-sentence explanation. Skip the statistical detail\nunless they ask. The goal is enough understanding to trust and use the data,\nnot to replicate the methodology.\n\n**Technical (data scientist, research analyst, GIS professional):** Go deeper.\nCover the underlying measurement approach, known limitations, and where to\nfind further documentation. These users will ask follow-up questions and want\nprecise language.\n\n**Mixed audience or unknown:** Lead with the plain-language version, then\noffer to go deeper: *\"Want me to walk through the technical details of how\nthat's measured?\"*\n\n---\n\n## The Data Foundation: Advan's Mobile Device Panel\n\nAll REI metrics derive from the same underlying source: a panel of opted-in\nmobile devices whose location signals are collected, processed, and aggregated\nto generate insights about physical locations.\n\n**Panel composition:** Advan observes over 100 million U.S. devices. After\napplying strict data quality filters to remove noise and suspect signals, the\nworking panel represents approximately 20% of the U.S. population and is\ndemographically diverse across geography, age, and income. The panel is\nsourced via SDK partnerships and collects signals through a combination of\nGPS, Wi-Fi, and SDK-based location data.\n\n**Privacy and compliance:** All data is aggregated and anonymized before\ndelivery. No individual device is identifiable in any REI output. Advan\ncomplies with applicable opt-in requirements — devices are included only\nwhere users have consented to location data collection through the apps\non their devices.\n\n**Plain-language explanation for non-technical users:**\n> \"Advan's data comes from a large panel of mobile devices whose owners have\n> opted in to share their location through the apps on their phones. After\n> filtering out low-quality signals, the panel represents about 1 in 5 U.S.\n> consumers and is structured to reflect the broader population across\n> geography and demographics.\"\n\n---\n\n## Data Quality and Accuracy\n\nWhen users ask how Advan ensures its data is accurate or how it's been\ntested, this is a selling point — answer it directly and confidently.\n\n**Independent signals, not calibrated to a benchmark:** Advan's data\nproduces its own independent signals rather than being calibrated against\na single external ground truth source. This means the data reflects what\nthe panel actually observes, without being shaped by or dependent on any\none third-party reference.\n\n**Internal quality controls:** Several layers of quality processing are\napplied before data reaches REI:\n\n- *Noise and GPS spoofing filtering:* Suspect or anomalous device signals\n  are identified and removed before they enter the working panel.\n- *Demographic representativeness weighting:* Panel composition is\n  adjusted to reflect the broader population across geography, age, and\n  income.\n- *Geofence quality review:* Property boundaries are validated before a\n  location is included — locations where a confident boundary can't be\n  established are excluded rather than approximated.\n- *Automated anomaly detection:* Unusual spikes or drops are flagged\n  for review so they don't surface to users as reliable data without\n  scrutiny.\n\n**How the data holds up in the real world:** Two forms of validation\nplay out continuously through client use:\n\n- *Company-level alignment:* At the ticker level, Advan's foot traffic\n  signals closely align with comp reports from publicly traded retailers.\n  This is why hedge fund and fundamental investment clients rely heavily\n  on REI data to trade inter-quarter — it's a signal they trust ahead\n  of earnings.\n- *Location-level alignment:* At the property level, traffic patterns\n  consistently align with known real-world events — store openings and\n  closings, holiday traffic shifts, anchor changes. Clients regularly\n  evaluate Advan data against ground truth sources including physical\n  traffic counters and internal sales data, and report high correlation.\n\n**Plain-language response for users who ask:**\n> \"Advan's data goes through several layers of quality filtering —\n> removing noise and spoofed signals, validating property boundaries,\n> and weighting the panel to be demographically representative. On the\n> accuracy side, our foot traffic signals closely track comp reports for\n> publicly traded retailers, which is why a lot of institutional\n> investors use this data to trade inter-quarter. At the location level,\n> our clients routinely test us against physical counters and sales data\n> and consistently find strong correlation.\"\n\n---\n\n## Visit Definition\n\n**What counts as a visit:** A visit is recorded when an opted-in device is\ndetected within a property's geofence. There is no minimum dwell time\napplied by default — every device detection that falls within the property\nboundary counts as a visit. Users who want to filter by dwell threshold\ncan apply a dwell time filter from the header bar in REI.\n\n**Why no default dwell threshold:** Employees, delivery drivers, and quick\nconvenience stops are all legitimate components of a property's traffic\npicture, and some are meaningful trade area indicators. Rather than\nprescribing a single threshold, REI puts the filter in the user's hands\nso analysts can define the visit they care about for their specific question.\n\n**Property boundary (geofence):** Each property has a defined geofence — a\ngeographic polygon corresponding to its physical footprint. A device must\nbe detected within the geofence to count toward that property's visit tally.\n\n**De-duplication within a day:** Each unique device is counted once per\nproperty per day, regardless of how many times it was detected at that\nlocation during the day.\n\n**Workers and frequent visitors:** Employees and vendors are not excluded\nfrom visit counts by default, because frequent visitors — including staff —\nare part of the real foot traffic picture and contribute to trade area\nintelligence. Users who want to isolate shopper-only traffic can apply\nfrequency and dwell filters from the Global Filters menu in REI's header to\nfilter out devices with patterns consistent with employee behavior.\n\n**Plain-language explanation:**\n> \"A visit is counted whenever someone's device is detected within the\n> property's boundary. We count each device once per day, and we don't\n> filter out employees by default — they're real traffic and can be\n> meaningful data points. If you want to focus on pure shopper behavior,\n> you can apply frequency and dwell filters to narrow it down.\"\n\n---\n\n## Dwell Time\n\n**Definition:** Dwell time measures how long a visiting device was detected\nwithin the property geofence during a visit. It's expressed as a median\nacross all visits in the selected period rather than an average, which makes\nit more robust to outlier sessions.\n\n**What it measures:** Dwell time is a behavioral signal — it distinguishes\ndestination shopping (longer dwell, more browsing) from convenience or\nerrand trips (shorter dwell, get in and get out). It's particularly useful\nwhen comparing similar properties or evaluating retailer fit for a specific\nconcept.\n\n**Applying a dwell filter:** Because there is no default minimum dwell\nthreshold, users working with dwell time for a specific analysis — such as\nfiltering to visits of at least 5 minutes to exclude true pass-throughs —\nshould apply the dwell time filter in the header bar before pulling metrics.\nThis makes the filter explicit and consistent with the user's analytical\nintent.\n\n**Limitations:** Dwell time reflects how long the device signal was present\nwithin the geofence, not time actually spent inside the store. A device\nthat lingers in the parking lot contributes to dwell time. In practice,\nparking lot behavior is a real component of the retail visit experience, so\nthis is generally an acceptable proxy — but it's worth noting when precision\nmatters.\n\n**How dwell is displayed:** REI shows dwell time in 15-minute increments\n(e.g., 0–15 min, 15–30 min, 30–45 min, and so on). When citing a dwell\nfigure, reference the bucket rather than a precise minute value.\n\n**Interpreting dwell buckets:**\n- 0–15 min: quick stop, errand, or parking lot detection\n- 15–30 min: standard convenience or grocery trip\n- 30–45 min: typical shopping trip\n- 45–60 min: extended shopping or casual dining\n- 60+ min: destination experience (entertainment, sit-down dining, big box)\n\nThese are general benchmarks — always compare dwell against the property\ntype and against peer properties in the same category rather than treating\nany single bucket as good or bad in isolation.\n\n---\n\n## Visit Frequency\n\n**Definition:** Visit frequency measures how many times the average visitor\nreturns to a property over a defined period. Specifically, it's calculated\nas the total visits divided by the number of unique devices that visited —\ngiving an average number of trips per unique visitor.\n\n**What it measures:** Frequency is a loyalty signal. A property with high\nfrequency is drawing repeat customers; a property with low frequency is\nmore dependent on constantly attracting new visitors. Grocery-anchored\ncenters typically show high frequency (multiple visits per month); fashion,\nhome goods, and entertainment typically show lower frequency.\n\n**Interpreting frequency in context:** Always benchmark frequency against\nthe property type. A grocery store with a frequency of 3.5 visits per month\nis performing normally; a lifestyle center with that same frequency would be\nexceptional. A mall with a frequency of 1.2 is normal; a convenience store\nwith 1.2 would signal a problem.\n\n---\n\n## Trade Area Construction\n\n**Definition:** A trade area in REI is defined by actual visitor origin data,\nnot assumed drive-time rings. It represents the geographic area from which\na defined percentage of a property's visitors originate.\n\n**How it's built:** Advan identifies the home location of each visiting\ndevice using persistent overnight ping clustering over a rolling 3-week\nwindow — the area where the device is consistently detected during overnight\nhours. Those home locations are mapped and aggregated to produce a\ndistribution of visitor origins. The trade area polygon is then drawn to\ncapture a defined threshold of that distribution — typically the closest\n70% of visitors by origin distance.\n\n**Threshold options:** The 70% threshold is the default and most commonly\nused. Lower thresholds (50%, 60%) produce a tighter \"core\" trade area;\nhigher thresholds (80%, 90%) capture a broader catchment including less\nfrequent long-distance visitors. The threshold should be chosen based on\nthe use case — leasing conversations typically use 70–80%; cannibalization\nanalysis may use 50–60% to identify core overlap.\n\n**Why this is different from drive-time rings:** Drive-time rings assume\nuniform behavior — that all customers within X minutes will visit equally.\nActual trade areas are almost never symmetric. Highway access, competing\nproperties, natural barriers, and neighborhood boundaries all distort the\nreal catchment in ways that rings can't capture. Trade areas built from\nvisitor origin data reflect where customers actually come from.\n\n**Home location attribution caveat:** Home attribution is based on\novernight device behavior over a rolling 3-week window. Devices without\nreliable nighttime data, devices shared across household members, or\nfrequent travelers may be attributed less precisely. At the aggregate\ntrade area level, this uncertainty is minimal — it's most relevant when\nevaluating individual device-level data, which REI doesn't expose.\n\n**Plain-language explanation:**\n> \"Instead of drawing a circle on a map, Advan's trade areas are built\n> from where visitors actually live. We figure out each visitor's home\n> by looking at where their device consistently shows up overnight over\n> a 3-week period, then map that to see the real geographic catchment.\n> That's why trade areas here are often irregular shapes — they follow\n> real behavior, not an assumed drive radius.\"\n\n---\n\n## Demographics\n\n**Definition:** Demographic data in REI characterizes the visitor population\nof a property — not the residents of the surrounding area. This is a\ncritical distinction: REI demographics describe who is actually visiting,\nnot who lives nearby.\n\n**Attribution methodology:** Once a visiting device's home location is\nidentified via overnight clustering, Advan attributes demographics to that\nvisitor using block-group level data from Synergos / Popstats. The\ndemographic attributes of the visitor's home block group are applied to\nthat visitor, and these are then aggregated across all visitors to produce\na profile of the visiting population.\n\n**What this means in practice:** If a property in a working-class\nneighborhood is primarily visited by people from more affluent zip codes,\nREI demographics will reflect the more affluent profile — because it's\nshowing who is actually visiting, not who lives nearby. This is why REI\ndemographics often differ meaningfully from simple ring-based lookups and\nare more directly useful for retail merchandising and leasing decisions.\n\n**Lifestyle and psychographic segments:** REI uses Spatial.AI PersonaLive\nsegments. Each PersonaLive segment represents a cluster of households with\nsimilar demographic characteristics, purchasing behavior, and lifestyle\npriorities, assigned at the block group level. Segments are applied to\nvisitors based on their home block group and aggregated to characterize\nthe visiting population's lifestyle profile.\n\nWhen explaining a specific PersonaLive segment to a user, describe it in\nplain terms — purchasing behavior, lifestyle priorities, retail affinities —\nrather than referencing the segment name alone. Don't assume the user knows\nwhat a segment label means.\n\n**Demographic data vintage:** Block-group demographic data from Synergos /\nPopstats is updated annually.\n\n---\n\n## Rankings and Benchmarking\n\n**How properties are ranked:** The peer set depends on what is being\nranked:\n\n- **Retailers:** A retailer's locations are ranked against their own\n  sister locations by default. Users can also compare against the\n  retailer's broader industry category.\n- **Shopping centers:** Properties are ranked against other centers in\n  the same GLA (gross leasable area) size tier.\n\n**The ranking metric:** The default ranking metric is total visit volume\nover the selected period. Users can switch to dwell time, visit frequency,\nvisits per square foot, or unique visitors depending on what they're\nevaluating.\n\n**Geography options:** Rankings can be scoped to a geography the user\nselects. Available options include MSA, county, zip code, or a custom\nradius around an address. These are built from Census and USPS boundary\ndefinitions, or the user can draw a custom area.\n\n**Interpreting rank:** Rank is always expressed as \"X of Y\" — both the\nrank position and the total count are necessary for context. \"3 of 8\" and\n\"3 of 340\" are very different findings.\n\n---\n\n## Void Analysis Scoring\n\n**The void analysis endpoint scores potential tenant candidates against\nthree dimensions:**\n\n**Candidate eligibility — location spacing filter:** Before scoring,\nAdvan filters out retailers that already have a location too close to the\nsubject site relative to their own network's typical spacing. Specifically,\nAdvan calculates each retailer's average distance between their existing\nlocations. Any retailer with an existing location closer to the subject site\nthan that average inter-location distance is removed from the candidate set.\nThis filters out brands where a new location would be structurally too close\nto an existing one — before cannibalization risk is even considered.\n\n**Cannibalization risk:** For retailers that pass the spacing filter,\ncannibalization risk is calculated from the shared customer percentage —\nwhat share of the subject site's visitors already visit a nearby location\nof that same brand. Higher shared customers means more of the potential\ncustomer base is already being captured by an existing location, increasing\nthe risk that a new store would pull from existing volume rather than\ngrowing the brand's total reach.\n\n**Demographic match:** A score reflecting how well the trade area's visitor\ndemographic profile aligns with the candidate's typical customer profile\nacross its existing locations. Higher match means the customers at this\nproperty look more like the candidate's core shoppers.\n\n**How candidates are ranked:** Candidates that pass the location spacing\nfilter are scored on cannibalization risk and demographic match and ranked\nrelative to each other for the subject site — not against an absolute scale.\n\n---\n\n## Shared Customers and Cross-Shopping\n\n**Definition:** Shared customers measures the percentage of a property's\nvisitors who also visited another specified property (or set of properties)\nwithin the same time period. It's a measure of cross-shopping behavior —\nhow much the two locations' customer bases overlap.\n\n**Calculation:** For a given pair of properties A and B, shared customers\n= (devices that visited both A and B) / (devices that visited A), expressed\nas a percentage. The result is directional — shared customers from A to B\nis not necessarily the same as from B to A.\n\n**What it means:** High shared customers between a subject site and a\nretailer's existing locations indicates the trade area is already being\nserved by that retailer — useful for gauging demand, but also a signal\nworth watching for cannibalization risk. Low shared customers may indicate\nan untapped customer pool or a meaningfully different visitor base.\n\n**Retailer-level shared customers:** When `shared-customers-retailer` is\nused, the comparison is against all locations of a brand within a defined\nradius, rather than a single property. This gives a more complete picture\nof the brand's penetration in the trade area.\n\n---\n\n## Sales Data and Transaction Intelligence\n\nAdvan maintains a panel of approximately 100 million debit and credit cards\nthat enables estimation of basket size and both online and offline sales.\nThis data can be used to go beyond foot traffic — connecting visit behavior\nto spending behavior and revenue estimation.\n\nWhen a user asks about sales data, revenue estimates, basket size, or\ntransaction-level intelligence, let them know this capability exists and\nroute them to the support team for a fuller discussion.\n\n> \"Advan has a panel of roughly 100 million debit and credit cards that\n> we use to estimate basket size and online and offline sales. It's a\n> natural complement to the foot traffic data. Our support team would be\n> happy to walk you through what's available — want me to send them a\n> note?\"\n\n---\n\n## Data Freshness and Update Cadence\n\n**Update schedule:** REI data is refreshed every Wednesday with a 3-day\nlag. This means data through the end of the prior week is typically\navailable by Wednesday of the following week.\n\n**Historical depth:** REI data is available going back to 2017. Data prior\nto 2017 exists but is considered less reliable due to smaller panel size\nduring that period — flag this if a user is comparing across a very long\ntime horizon that includes pre-2017 data.\n\n**Date range recommendations:**\n- For trend analysis: 12–24 months trailing is the standard window.\n- For YoY comparison: match periods of equal length and the same calendar\n  months to control for seasonality.\n- For a current snapshot: the most recent complete month is the standard\n  reference; the current partial week may undercount relative to prior\n  complete periods.\n\n**Plain-language explanation for users asking about data recency:**\n> \"REI data updates every Wednesday, typically reflecting activity through\n> the end of the prior week. So on any given Wednesday, you're looking at\n> data that's about 3 days old. Historical data goes back to 2017.\"\n\n---\n\n## Data Coverage and Limitations\n\n**Geographic coverage:** Advan's panel covers the U.S. and Canada.\nAdditional international data is available outside the standard REI\nplatform — users interested in international coverage should contact\nAdvan's support team for options.\n\n**Property coverage:** There are a few specific reasons a property may\nnot have traffic data in REI:\n\n- **Vertical stacking:** REI does not include traffic for POIs that have\n  another POI directly above or below them in the same structure. Because\n  only 10–15% of the mobile panel provides elevation data, Advan cannot\n  reliably distinguish which floor a device is on — so vertically stacked\n  locations are excluded from the standard platform to avoid misattribution.\n  Data for these locations can often be pulled outside of REI; direct users\n  to contact Advan's support team if they need it.\n- **Outdated satellite imagery:** Geofences are built from satellite\n  imagery. If a location's imagery is outdated or the property boundary\n  cannot be defined with confidence, the location will not have a geofence\n  and therefore will not have traffic data.\n\nIf a user needs a location that isn't currently available, they have two\noptions: request that Advan add it (support team), or draw their own\npolygon using the Add Location tool in REI's header bar.\n\n> \"That location isn't showing traffic data in REI — that usually means\n> it's either in a multi-story building where elevation data is limited,\n> or its boundary hasn't been defined yet. You can draw your own polygon\n> using Add Location in the header, or I can send a request to Advan's\n> team to get it added.\"\n\n**No default dwell filter — implication for comparisons:** Because REI\napplies no minimum dwell threshold by default, visit counts include all\ndevice detections within a geofence, including very short-duration\ndetections. When comparing a REI visit count to data from another source\nthat applies a minimum dwell filter, the counts may not be directly\ncomparable. Always flag this if a user is cross-referencing REI data\nagainst other datasets.\n\n**Panel representativeness:** Mobile location data is directional and\nrepresentative by nature — Advan's panel of approximately 20% of the U.S.\npopulation is structured to reflect the broader population across\ndemographics and geographies. As a general principle, the larger the\nproperty and the higher the surrounding population density, the closer\nvisit counts tend to track to ground truth. Smaller or lower-traffic\nlocations will be directionally accurate but may have more variability\nin absolute counts.\n\n---\n\n## Handling Methodology Questions Beyond This Reference\n\nIf a user asks a technical methodology question not covered here — about\na specific algorithm, the exact inputs to a score, proprietary weighting\ndetails, or something that requires Advan's internal documentation —\ndon't speculate.\n\n> \"That's a level of methodological detail I don't have on hand. I can\n> send this to Advan's support team if you'd like a precise answer —\n> they'll have the technical documentation.\"\n\nOffer to escalate per the standard support escalation workflow. Don't\ninvent details to fill the gap.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}