Your Market Data Is Unified. Your Operating Data Is Not.

Picture an acquisitions analyst at a multifamily owner opening three tabs on a Tuesday. The first is a rent comp for a 240-unit asset, pulled from HelloData, current to last week. The second is the parcel record, pulled from a county feed, current to the last assessment. The third is a spreadsheet, and the spreadsheet is the problem. It holds the occupancy and trailing collections for the twelve properties the owner already runs in the same submarket, and it is current to whenever someone last exported it from the property management system. The comp is fresh. The parcel is fresh. The owner’s own number is nine days old and lives in a file with FINAL in its name.

That scene is the whole argument. The category the industry calls “CRE data platforms” is two layers wearing one name. The first is third-party data: market data you license from outside, ownership records, tax history, parcel geometry, comps, demographics. The second is first-party data: operating data you already own, inside the property management, leasing, and maintenance systems your teams run. The rankings that circulate every year compare the first layer carefully and treat the second as one more feed. For an operator, the second layer is the one with no pipeline, and it is the one your reporting and every AI initiative you have been asked about actually depend on.

The ranking that started this

In June a guide titled Best CRE Data Platforms for Unification & Warehousing in 2026, from the automation consultancy Next Automation, made the rounds. It ranks Cherre, ATTOM, Regrid, LightBox, and HelloData, each as the winner for a use case, and it opens with a diagnosis most people in this industry would nod at: firms do not have a data problem so much as a data-unification problem. The listings live in one system, the ownership records in another, and the portfolio truth in the property management system. Unify it all in one layer and the analytics take care of themselves.

I agree with the diagnosis. I disagree with the ranking’s answer, and not because the platforms are wrong. Cherre is a serious entity-resolution product, and since July 14 it is a RealPage product: RealPage closed the acquisition that day, cash, terms undisclosed, brand retained. That puts Cherre’s footprint and roadmap in question for any operator not on RealPage. A market-data layer owned by one PMS vendor has every reason to resolve that vendor’s operating data first and everyone else’s second, and how far that goes is not yet known. ATTOM’s bulk feeds are the right way to load nationwide property records into a warehouse you run. Regrid is the parcel specialist. LightBox is the environmental and geospatial one. HelloData collects rents, concessions, and amenities across apartment properties programmatically and does it well enough that it sits in our own connector catalog as a source.

The trouble is the phrase “the portfolio truth in the property management system.” In the ranking it is one item in a list of feeds, alongside listings and parcel data. In an operator’s actual stack it is not a feed. It is the only one of those sources that nobody outside your building can hand you clean, and it is the only one you are legally and commercially responsible for getting right.

Two layers, not one

The difference between the two layers is not the data’s subject matter. It is who owned the data before it moved, and therefore who did the cleaning. One is third-party data. The other is first-party data. Every other difference follows from that one.

Third-party data is clean on arrival because cleaning it is the product. ATTOM sells you records that already reconcile. Cherre sells you a property record that has already resolved six sources into one. You are paying for the resolution as much as the data.

First-party data has no equivalent vendor, because it is yours: nobody else has it to sell. A unit in Yardi is a unit. In RealPage it may be a space. In Entrata it is a unit again with different sub-fields, and the lease status codes, the charge codes, and the work-order priorities differ across all three. No outside company can tell you whether a lease that renewed on the fifteenth counts once or twice in your occupancy number, because that is a decision about your business, and the answer is encoded nowhere except in how your team has always done it.

So the first layer can be bought. The second has to be built, or at least moved, and the moving is where operators get stuck.

Why the rankings miss it

The rankings are written for the reader who will consume the data: the analyst, the asset manager, the AI agent. From that seat, all sources look alike. Each one is a table you want in the warehouse, and the question is which vendor supplies the best table. That framing is right for third-party data and wrong for first-party data, because first-party data has no vendor. The property management system is not trying to sell you a warehouse feed. It is trying to run your leasing office, and it exposes data as a secondary concern, through APIs that were designed for integrators, on pricing that treats extraction as an add-on.

A director of IT at a multifamily operator put the consequence to us this way. The company owns its data, in the sense that the data describes its buildings and its residents, and it also does not, in the sense that the data sits inside the PMS where nobody can script against it or move it anywhere. Owned and locked in at the same time. That is a first-party problem, and no third-party platform fixes it. Cherre would be the first to say so: the Cherre comparison on our own site describes Connect feeding a warehouse alongside Cherre, first-party operating data on one side and third-party market overlays on the other, and that is the accurate picture.

The rankings do not miss this because their authors are careless. They miss it because from the consumer’s seat the operational layer looks like plumbing, and plumbing does not get ranked. It only gets noticed when the spreadsheet is nine days old.

What the operational layer is

It is the pipeline from the systems you run to the warehouse you own, and it has three parts that are easy to conflate.

Extraction is getting the data out of each system on a schedule: authentication, pagination, rate limits, and the schema drift that arrives with every PMS release. This is the part that used to need an engineer per system and a roadmap slot nobody had.

Loading is landing it in Snowflake, BigQuery, Databricks, or wherever your finance and corporate data already live. This part is nearly solved, because every warehouse ingests tables.

Modeling is deciding what the data means once it lands, so that a Yardi unit and an Entrata unit line up in one table. This is the part no vendor can do for you, because it encodes your business rules.

Connect does the first two across the operational stack: property management, leasing and CRM, maintenance, resident experience, access control, payments, and the rest of the catalog. It lands the data raw, in each system’s own shape, so nothing is silently reshaped on the way in and nothing is silently lost. For the property management systems the Unified API supports, there is also a normalized layer, which is what an application builder wants. Everything else in the catalog arrives raw, and the modeling on top is yours, usually in dbt or plain SQL, done by an analyst rather than an engineer.

The operational layer does not make the modeling disappear. It makes the modeling the only thing left, and puts it where you can see it.

The strongest objection

Cherre’s core value is entity resolution, and it can ingest first-party operating data. So why not treat the PMS as one more source into Cherre and let the platform unify everything?

The RealPage acquisition sharpens the question before it answers it. An operator on Yardi or Entrata is now asking a RealPage-owned platform to resolve a competitor’s records, and on what terms, at what priority, and for how long is unknown. That uncertainty is itself an argument for owning the pipeline rather than renting it.

You can, and for an institutional owner running portfolio analytics that is often the right architecture. The objection holds up. What it does not remove is the pipeline. Cherre resolving a Yardi record into its property graph still requires that the Yardi record be extracted, on a schedule, with the auth and the pagination and the schema drift handled by someone. Entity resolution is a modeling step. It happens after extraction, not instead of it, and the ranking’s own framing, where the PMS is a feed among feeds, quietly assumes the feed exists.

For most operators the feed does not exist yet. Every operator we have deployed Connect for had already chosen a warehouse and already had third-party data flowing into it. What they did not have was their own occupancy number arriving in the same place without a person in the loop. The stack was two layers. Only one had a pipeline.

What to do about it

Buy the third-party data. The ranking is a reasonable guide to which vendor fits which use case, and none of the five is a mistake for the job it is ranked for. Then, before the next board deck, run one test. Pick the operating number the deck depends on most, usually occupancy or trailing collections, and trace it backward from the slide to the system it came from. Count the humans in the path. If the answer is more than zero, you have a third-party layer and no first-party layer, and the ranking you read did not warn you.

Fixing it is not a data strategy project. It is a pipeline per system, into the warehouse you already own, followed by a modeling pass an analyst can do. The vendors in the rankings will keep your comps fresh. Your own number is the one nobody else can deliver.

The third-party layer got unified because somebody could sell the unification. The first-party layer is still waiting for the same attention, and the only company that can give it is the one that owns the data. That is you.