Yep, sorry. But maybe this post is different, because we write MLS software and need to try to accommodate the many diverging views. Wow, are there ever a lot of different ways of looking at this issue. (Fortunately, the very cool REMBEX site and Google’s custom searching make finding all these views pretty easy.)
Of course, the discussion on DOM is hot now that the market has changed in several parts of the country. I think FBS and other MLS vendors could start a pretty accurate leading indicator on the housing market simply by posting our issue tracking list publicly. When we start getting requests for new ways to track days on market and prices changes, that’s a pretty strong sign that the market is turning down in that area.
Our system is supposed to help our customers understand the listing data in all markets, so responding to these requests is important to us. When it comes to continuous days on market (CDOM), though, designing a good response is not easy, as evidenced by all the divergent views linked above. First, what is CDOM? The general theory is that the system should add together the days on market from listings on the same property, if the listings meet certain criteria. The devil, of course, is in the “certain criteria.” When are two or more listings related enough that the DOM should be aggregated?
Is a listing that has been canceled and re-listed within 30 days by the same agent related enough? How about 60 days? How about 25 days but re-listed by a different agent in the same office? How about 40 days and re-listed by a different agent in the same company? How about five days and re-listed by a different agent in a different company … for 25% less?
For every set of rules established, an exception will be slipping around the corner. For this reason, we’ve been advocating two approaches to solving this problem:
- Property History — Our system has a property history function, which is intended to show all listings for a given property. This function allows whoever is looking at the report to decide for themselves whether the listings are related enough to justify adding together the days on market. Given the disparity in views on this topic, simply providing the data without interpretation (which is all that CDOM is, one interpretation) seems best. The biggest challenge with a property history function is matching addresses or parcel (tax ID or PIN) numbers. This is where data standards are oh so important. Every MLS should require parcel number for every listing, but many do not, which requires us to match on address. Our system does a lot of validating and auto-correction of addresses on listing entry, including checking against the USPS database, the local tax database (if available), and the street mapping data source (NAVTEQ or TeleAtlas), but that doesn’t help in very rural or new areas where addresses may not exist or are not well-formed. Another approach is bounded geo-codes (latitude/longitude), but the same properties that are difficult to match on address are equally difficult to map. The bottom line is that matching on addresses is much more difficult than parcel number and so parcel number should be the required standard.
Side note: We need to do a better job of integrating the history of each listing into the property history report. Currently, users can see all the listings for the property on a single report, but they have to pop-up a separate report to see the detailed history for each individual listing, and it would be much better if the two reports (property and listing history) were one. We intend to integrate the two when we roll out our new search module in our next release.
- Catch ’em Early — In addition to re-setting DOM, some users cancel and re-list in order to get their listings back on the hot sheet. CDOM does not handle the hot sheet problem but preventing entry of the duplicate listings in the first instance would, and could provide a mechanism for the MLS to review legitimate exceptions. Many larger MLSs may not be able to provide this level of review but stopping the entry of a limited set of more certain duplicates is an easier algorithm to develop than determining after the fact which among all listings should be aggregated.
Perhaps there are other approaches, too? For example, we have a function in the system that allows other users to report suspected errors in the listing either to the listing agent or the MLS. Perhaps we could allow other members to submit their own calculations of the DOM? Nah, just kidding. Standardize the data, report the data, let users judge for themselves, that’s the approach we suggest. At the same time, I can see some advantages for CDOM in market-wide stat reports and possibly for searching, though that doesn’t make developing an accurate algorithm any easier. What are your thoughts? Is CDOM the only way to solve this challenge?