Ask a revenue leader how much ancillary income a portfolio generated last quarter, and the answer arrives quickly. Ask which resident touchpoints produced that income, whether it was the move-in checklist, a renewal offer, or a maintenance visit, and the answer usually does not arrive at all.
That gap matters more than it looks. Other income is not a mystery in most portfolios; it shows up on the operating statement every month. What is missing is the connective tissue between a dollar of that revenue and the specific resident interaction, channel, or property system that generated it. Without that connection, revenue leaders cannot tell which programs to expand, which properties are underperforming, or which vendor relationships are actually working.
This article is about that connective tissue: why it is missing, what it would take to build it, and which KPIs are worth tracking once it exists.
Why revenue attribution breaks in multifamily
The property management system was not built to answer this question, and it was never supposed to be.
Funnel Leasing describes the major PMS platforms, Yardi, RealPage, and Entrata, as the operational backbone of multifamily, noting that they function as “systems of record, ensuring data integrity for mission-critical functions like rent collection and financial reporting.” That framing is accurate and also the source of the problem. A system of record for rent collection has no native reason to track which resident touchpoint led to a storage rental or an insurance signup, because that was never its job.
Writing for Thesis Driven, Propexo co-founder Remen Okoruwa put the underlying issue directly: the PMS, maintenance platform, and CRM each know their own slice of the resident relationship, but “none of them know about the resident as a whole person whose history spans all three.” Revenue attribution requires exactly that whole-person view, and it is precisely what the current generation of point solutions was not designed to provide.
The consequence shows up first in marketing and leasing, before it ever reaches ancillary revenue. Okoruwa’s account of a former Bozzuto marketing leader is instructive: a renter who clicked an ad, toured the property, and applied the following week showed up as three separate leads across three separate tools, and the operator had “almost no visibility into which channels were actually driving signed leases.” Ancillary revenue attribution is the same structural problem one step further down the resident lifecycle. If a lead cannot be tracked consistently across three systems before signing a lease, a service transaction is even less likely to be tracked consistently across the systems that touch a move.
PMS data vs service transaction data
Two different kinds of data sit inside a multifamily operator’s stack, and they were built with two different purposes in mind.
PMS data describes the lease. Move-in and move-out dates, unit assignments, rent ledgers, and renewal status all live in Yardi, RealPage, or Entrata, structured around the unit and the lease term. Service transaction data describes something else: which resident purchased a mover, packing service, storage unit, insurance verification, or connectivity plan, and when. That data is often generated by a separate vendor, on a separate schedule, with no shared identifier connecting it back to the lease record.
The result is what a SurfaceAI analysis of multifamily technology stacks called a fragmented environment where information “trapped in separate tools, the PMS, spreadsheets, cloud storage, email threads, creates blind spots.” The same analysis pointed to a cross-industry benchmark worth noting here: 68% of organizations cite data silos as their top data management concern. Multifamily is not an outlier on this point. It is a straightforward case of an industry where the core operating system was designed for accounting, not for tracing revenue across vendor boundaries.
Okoruwa’s reporting on the current state of PMS openness reinforces the scale of the gap. Even as major platforms have opened up their APIs, a recent industry survey found that “no platform scored above 6.5 out of a 10-point scale, and the lowest averaged just over 3” on openness, and the editorial verdict was that none of the recent improvements had meaningfully changed how the industry experiences these platforms day to day. Getting data out of a system is not the same as being able to connect it to a resident record elsewhere in the stack.
For an operator managing 10,000 units or more across a mixed Yardi, RealPage, and Entrata estate, this means service transaction data and PMS data typically exist in parallel, reconciled manually if they are reconciled at all.
Mapping resident touchpoints to revenue
A useful way to think about this problem is to borrow, carefully, from how marketing measurement handles a similar challenge.
Marketers have spent two decades building attribution models because a customer rarely converts on a single interaction. Adobe’s overview of the practice describes the two simplest approaches: a first-touch model that “prioritizes the first touchpoint in the customer journey,” and a last-touch model that credits whichever interaction happened right before conversion. Both are easy to build and both are incomplete, which is why more sophisticated multi-touch models exist to distribute credit for a conversion “across every touchpoint in the customer journey, rather than handing all of it to a single click.”
The resident lifecycle has its own version of this same journey. A resident encounters a mover recommendation during the move-in checklist, a packing offer during a reminder email, a storage upsell during a maintenance visit, and an insurance verification requirement at lease signing. Each of those is a touchpoint. Revenue that lands in other income was generated by one or more of them, and right now, most operators can only see the total, not the path.
Mapping touchpoints to revenue does not require the full sophistication of a multi-channel marketing attribution model. It requires something more basic first: a consistent identifier that ties a resident to a unit, a move event, and every service transaction associated with that move, regardless of which vendor processed it. Without that identifier, no attribution model, however sophisticated, has anything to work from.
Attribution by property, service, and move event
Once a consistent identifier exists, attribution can be organized along three axes that map to how revenue leaders actually make decisions.
By property. Which communities are converting move events into ancillary revenue at a meaningfully higher rate than the portfolio average, and which are lagging? Property-level attribution surfaces execution differences that a portfolio-wide number hides entirely. A regional average can look healthy while individual properties are leaving revenue on the table.
By service category. Movers, packing, and storage behave differently from insurance and from connectivity, both in adoption pattern and in how the offer reaches the resident. A single blended attribution number obscures which category is actually driving performance and which is riding on the others.
By move event. Move-in and move-out are not the same commercial moment. A move-in is an onboarding sequence with multiple scheduled touchpoints; a move-out is a shorter, more compressed window with less runway to convert a resident into a service transaction. Attribution that does not separate the two will consistently overweight whichever event happens to generate more transaction volume, without explaining why.
Traditional tools focus on task tracking and administrative coordination. Moved embeds revenue-generating services and insurance verification directly into the workflow, which is what makes property-level, service-level, and move-event-level attribution possible in the first place, because the transaction and the resident record originate in the same system rather than being reconciled after the fact.
KPIs executives should track
Four metrics give a revenue leader a working view of attribution without requiring a full marketing-grade measurement stack.
Attribution coverage rate. The share of total other income that can be traced to a specific resident, property, and service category, as opposed to sitting in an undifferentiated other income line. This is the single number that tells a revenue leader how much of the portfolio’s ancillary revenue is actually explainable.
Revenue per move event. Ancillary revenue divided by completed move-ins and move-outs over a period, tracked separately for each event type. This normalizes for occupancy and turnover volume, so a property is not penalized or credited simply for having more or fewer moves in a given month.
Service category adoption rate. The percentage of eligible residents who transact in each category, movers, packing, storage, insurance, and connectivity, tracked at the property level. Adoption rate differences between properties running the same program are usually the clearest signal of an execution gap rather than a demand gap.
Property-level variance. The spread between the highest- and lowest-performing properties on attribution coverage and adoption rate. A wide variance across otherwise comparable properties is usually the fastest way to find where a program is breaking down operationally, before it shows up as a portfolio-wide number that looks merely average.
None of these metrics require inventing new infrastructure. They require the underlying transaction data to already carry a property, service category, and move-event identifier, which is the same requirement that underpins property-level attribution in the first place.
Building an attribution framework
A working attribution framework rests on four requirements, in order.
First, a shared identifier. Every service transaction needs to resolve to the same resident and unit record that the PMS uses, not a separate identifier maintained by whichever vendor processed the transaction. This is the single highest-leverage change, because every other requirement depends on it.
Second, category-level coding. Revenue needs to be tagged by service category at the point of transaction, not reconstructed later from vendor invoices. Movers, packing, storage, insurance, and connectivity should each be a distinct, queryable field, not a line item buried inside a combined other income total.
Third, move-event tagging. Every transaction should be associated with a specific move-in or move-out event, not just a date range. This is what makes it possible to calculate revenue per move event and to separate the two commercial moments described above.
Fourth, a system of record that is actually queried, not just reported. A dashboard that a regional manager checks quarterly is not the same as a data layer that a revenue leader can query on demand. Okoruwa’s reporting on operators who have solved this problem points to the same underlying shift: firms that treat their data as infrastructure they own, rather than a report their vendor produces for them, are the ones who can answer attribution questions on demand instead of assembling them from scratch each time a board asks.
These four requirements do not require replacing the PMS. They require a layer that sits alongside it, purpose-built to originate resident-linked, category-coded, move-event-tagged transaction data rather than reconstructing it after the fact.
Frequently asked questions
Why can’t we just pull this from our PMS reports?
Because the PMS was built to track leases and rent collection, not service transactions from third-party vendors. Funnel Leasing’s description of Yardi, RealPage, and Entrata as systems built for accounting and lease administration explains why: revenue attribution requires a resident-level view spanning multiple systems, which is not what those platforms were designed to produce.
Is this the same problem as lead attribution in marketing?
It is a related version of the same structural problem. The Bozzuto example above shows a prospect fragmenting into multiple leads across systems before ever signing a lease. Ancillary revenue attribution is the continuation of that fragmentation further down the resident lifecycle, after the lease is signed and the move begins.
How many properties need this before it is worth building?
Attribution coverage rate and property-level variance both become more useful as the number of comparable properties grows, since the whole point is to compare performance across communities. Portfolios of 10,000 units or more are large enough that even a modest gap between well-attributed and poorly-attributed properties represents a material amount of unexplained revenue.
What is the single highest-value change to make first?
Establish a shared identifier linking every service transaction to the same resident and unit record used by the PMS. Every other part of the framework, category coding, move-event tagging, and the KPIs built on top of them, depends on that identifier existing first.
Closing
Ancillary revenue is not hard to see. It shows up in other income every month. What is hard is tracing any single dollar of it back to the resident touchpoint, property, or move event that produced it, because the systems that generate that revenue were never built to talk to each other. Closing that gap does not require a new PMS. It requires a shared identifier, category-level coding, move-event tagging, and a small set of KPIs built on top of them.
If you manage 10,000 units or more and want to see what property-level and service-level revenue attribution would look like for your portfolio, reach out to our team.
Related reading: how the move-in and move-out workflow produces revenue for property managers, and the complete guide to resident onboarding automation. See also Moved for multifamily operators and the resident experience.