MLSs Dealing With The Pandemic: Virtual Open Houses and DOM Read More

Weaving a tangled web with IDX

Apr 15, 2011 Michael Wurzer

Controversy swirling around the National Association of REALTOR’s IDX policy is hardly new. The source of much of the controversy lies in the conflict between what non-NAR members are able to do with listings versus the restrictions on what NAR members can do with listings through IDX.

To review these issues, NAR’s MLS policy committee appointed a work group called the IDX Data Use Work Group, and that group recently published recommendations to (among other changes) amend the model IDX policy as follows:

Following publication of this recommendation, several smart people have said the language “by electronic means” is too broad and that allowing RSS for IDX may have negative repercussions. Here are my thoughts:

  • Right Intent.  The work group seems to have the right intent, which is to allow IDX to be a source of innovation and competition for brokers and agents.
  • The Devil Is In The Details.  Though the intent is heading in the right direction, I think the policy could use some refinement coupled with these changes to mitigate some of the concerns from the broad language.  I address a few of these below.
  • RSS. Allowing RSS feeds is a cool idea, but I wonder if some thought should be given to what goes in that feed.  To my way of thinking, there’s a big difference between including the entire listing versus the few fields that might constitute an “ad” for the listing.  Do consumers really want or need to see every field in the RSS feed?  Does the complexity and risks of the issue change if only certain fields are included?
  • Persistent Versus Transient Download.  The most common way of using IDX data today is for the vendor to download the entire IDX database to their own server and store (persist) it there to serve queries to their web site.  An alternative method is to only request the data from the MLS server when you need it (transient) and not store the results on your own server.  Many of the problems with the broad language “electronic means” is the result of the IDX data being distributed and persisted on so many different servers.  One way to allow more innovation without so many risks is to only allow transient queries for the IDX data via an IDX API built for that purpose.  That way, usage is more easily monitored and data access more easily terminated to address those concerns.
  • Terms of Use.  I’ve written about this topic before but the most important issue here is to ensure that proper terms of use are crafted and agreed to by all the parties using the IDX data.  More specifically, those terms of use need to vary depending on the data, with more strict rules covering the entire data set as opposed to perhaps the few fields that might make up an “ad” for the listing(s).  Terms of use also are critical to enforcing transient use of an API, but we shouldn’t underestimate the value of being able to enforce a contract.

In summary, the direction the work group is moving is the right one to allow innovation and competition, and yet some additional terms of use could be applied to ensure that the program survives that very innovation.  IDX is one of the best NAR policies ever crafted in the Internet age, and care should be taken with any changes.