Same-Store Filter: Overview & How It Works
What is the Same-Store Filter?
The Same-Store Filter lets you compare performance across only the properties that were active in your portfolio for the full duration of every period you're comparing. This gives you a true "apples-to-apples" view of your performance trends, without new or removed properties skewing the numbers.
This is especially useful when your portfolio has grown or shrunk between the periods you're analyzing. Without this filter, changes in your KPIs might reflect portfolio changes rather than actual performance shifts. The Same-Store Filter isolates true performance trends by holding your comparison set constant.
How is the Same-Store Cohort Determined?
Each unit's In-Service Date and Out-of-Service Date determine its eligibility when the filter is applied:
- If a unit's In-Service Date falls after the start of any comparison period, it's excluded.
- If a unit's Out-of-Service Date falls before the end of any comparison period, it's excluded.
- Only units that were continuously in service across the entire span of all periods being compared are included.
This applies across your primary date range plus up to three additional comparison ranges.
Where to Find It
You can toggle the Same-Store Filter by accessing the Filters at the section level within any dashboard or individual report. Or, set an account-wide default in System Preferences. If an account-wide default is applied, the filter stays consistent across all reports within all dashboard sections.
What Gets Filtered
- KPIs: When applied, the KPIs you've selected recalculate to reflect only the same-store cohort of units.
- Your PM data: The Same-Store filter segments your managed units
- Market Benchmark Data: Direct market benchmark data also obeys the Same-Store Filter, so your portfolio and the market comparison stay aligned on the same basis.
What's Excluded by Design
Reports and KPIs with "Inventory" in the title intentionally ignore the Same-Store Filter. This is by design, these reports and KPIs need to reflect true growth and churn, which requires seeing the full, unfiltered inventory.
If you're looking for a report on inventory growth and retention specifically, check out the Inventory Growth & Churn dashboard template (available to ProData subscribers only) in your KeyData portal.
Supported Data Sources
The Same-Store Filter supports PM and direct market data. OTA data is not currently supported by this filter.
Getting Started: A Recommended Workflow
If you're not sure where to begin, try this approach:
- Start unfiltered. Review your data without the Same-Store Filter applied, and look for smaller time frames (weeks or months) where you notice large changes in pacing trends. The Pacing Detail chart is a great report for this!
- Adjust your date range + Apply the Same-Store filter to those time frames. This helps you determine whether the shift reflects true over- or under-performance, or whether it's simply attributable to portfolio changes (properties added or removed).
How As-Of Dates Can Affect the Total Units Count
Each date range you view, whether it's your primary range or a compare range, has its own As-of date. This is the date the data reflects for that range. Because of this, you may occasionally notice the Total Units KPI count differ between your primary range and a compare range, even though the Same-Store Filter is applied correctly to both.
This happens because eligibility for the same-store cohort is based on whether a unit was in service throughout the full date range being compared, not on whether the unit existed as of that compare range's As-of date. A unit can qualify as same-store for a period even if it came into service after that period's As-of date, as long as it was active for the entire range itself.
Example - A user is viewing:
- Primary range: 9/1/26 – 9/30/26, as-of 7/20/26
- Compare range: 9/1/25 – 9/30/25, as-of 7/20/25
Between 7/8/25 and 9/1/25, several new units came into service. Because these new units were active throughout the entire September 2025 compare period, they qualify as same-store units for that range. However, as of the compare range's As-of date (7/20/25), those units weren't in service yet.
As a result, the Total Units KPI may show different counts for the primary and compare periods. This isn't incorrect, it reflects the As-of date and same-store filtering logic working as intended, but it can be unexpected if you're not accounting for how As-of dates apply independently to each range.
Takeaway: If your Total Units count looks different than expected between periods, check the As-of date for each range before assuming there's a data issue. The same-store eligibility logic is applied correctly; the difference is a byproduct of comparing ranges with different As-of dates.