This is my top 10 list for MLS Features in 2009. Many of these are not new - but these are the elements of MLS systems that I see people getting excited about in demos:

10. VOWs & enhanced private portals

9. Increased "push" notification options (email reminders, text messaging)

8. Mobile solutions - increasingly sophisticated

7. Expanded use of mapping - better geo-coding, driving directions, map-based statistics...

6. Increased branding and report customization

5. RETS - increased control, MLS "mash ups" using RETS

4. Google-like natural language query in the MLS

3. Share listing to social networking

2. Improving communication between pros, and with consumer (portals, showing feedback, tracking activity)

1. Multi-tasking

I talked about and illustrated these features in some depth last week during and after the free "2009 MLS Landscape" presentation I gave during the NAR meetings in San Diego, where I reviewed the 25 current MLS system offerings.

If you are interested in engaging me to present on MLS trends, the future of MLS, current MLS offerings and these features to your MLS staff, board and/or selection committee, contact me!

Clareity Consulting conducted a brief survey to gather some initial feedback from MLS industry leaders regarding NAR's two new initiatives, HouseLogic and Realtor Property Resource (RPR) that were presented Friday November 6th via a national webinar. Since time between the webinar and the NAR annual meeting was short, the response was limited – but with a nice mix of MLS executives responding from various size organizations nationwide, we learned some valuable information about how HouseLogic and RPR were perceived.

HouseLogic

Respondents were somewhat more favorable than not about how valuable the site will be for consumers:

Keep in mind that NAR's stated target audience for the site consists of "Responsible Proactive Homeowners" – it's not clear how big an audience that really is, or if 100% participation from that audience would be enough to meet NAR's goal of having one of the top10 real estate sites. Perhaps the target market for the site will expand overtime and additional valuable content will be created. It's unclear how this site will perform competitively against sites that have both content and listings,in terms of providing value for consumers.

43% of the respondents think that "HouseLogic will improve the Realtor brand strength with consumers":

Respondents were less favorable about how valuable the site will be for agents and brokers – but 78% believe that agents and brokers will find at least some value in the Realtor® Content Resource. Plainly at the local level agents will still need to differentiate from each other with unique content – they can't all use the same content from HouseLogic.

39% of respondents indicated that the site content could  be used to benefit their local site. More than 34% weren't sure – it's probably too early to tell how useful the content will really be just from the initial webinar presentation.

When asked to say what they liked most or least about the HouseLogic site and its strategy, respondents said the following:

• The content is valuable to consumers and it will keep the REALTOR value in the forefront. It will allow REALTORS to stand apart from other practitioners
• The general concept is good, however as with RCSMLS, RIN, DXM,and realtor.com, NAR frequently has execution problems. I am also concerned about the possibility of large brokers and franchises feeling that HouseLogic unfairly competes with their efforts and existing websites- "leveling the playing field".
• If the site gains enough visitors and is easily available through local association and MLS sites, it could help with the "R" image. Least:it does not do much for the individual members. Why not just enhance realtor.com since consumers already come there?
• The connection between agent and Realtor.com and how the consumer is going to find an agent from the HouseLogic site.
• Strengthens the value the Realtor family brings to the buying and selling public...should ultimately re-establish the Realtor as the expert on all information related to real estate
• Least: consumers still can't tell difference between agent &realtor, some parts of site aren't useful such as consumer's tracking their projects.
• Consistent messaging adds value to the trusted brand - REALTOR
• Potential for influence with respect to housing related issues
• I don't believe that homeowners will leave their trusted on-line sources to use a Realtor-branded resource, particularly when they find that they may be asked to assist NAR in their political agenda (i.e. consumer"call to action").
• Seems to put NAR out in front of members
• Real Estate is still local, consumers are still going to get advice from agents personally, sounds like HGTV to me.
• The details on how the site was developed and crafted. I'd like to provide the webinar at our next board meeting. Is this possible?

Answering that last point, the webinar is available online at the following location:
www.realtor.org/about_nar/stinton_webinar_110609

RPR - Realtor's Property Resource

77% of respondents found the presentation "Very informative" and "Informative".

Almost 32% of respondents indicated that they thought the RPR site will be valuable for agents and brokers initially – this doubles to 64% when asked about the value in five years.

The majority of respondents said that LPS/CyberHomes is a better strategic partner for RPR than Move.com – only 14% did not think so (note that this seems to correlate most heavily with tax data quality in each market).  One third of the jury is still out on this question.

Less than 5% of respondents don't think that MLS listing data and cooperation is key to RPR's success.

The respondents were almost evenly split on the idea of using MLS data to develop the RVM (Realtor Valuation Model).

Half of the respondents did not like the idea of the RVM (and possibly other derivative data products) to be a primary source of revenue for RPR.

Over 40% of respondents did not think that the RPR would save their MLS money on public records.

Of those that had assessed the quality of LPS tax records in their market, half  said the quality was "Great"or "Good" and half said it was "Fair" or "Poor". Since the primary value proposition in the proposed trade for MLS data is the tax data, this points to an important RPR opportunity for improvement (the more negatively inclined might say it's a serious flaw in the model).

How soon their contracts for public records expires may be one factor that plays into MLS cooperation with RPR. 36% of respondents' contracts don't expire until 2011 or later.

Respondents were split as to whether RPR poses a significant threat to existing local and regional MLS operators – if you add the "Yes" and "Eventually" answers, 54% see the threat coming down the road.

Regarding sending MLS data to RPR, respondents were again split, with 59% saying they would do so (at least eventually), 27% being unsure, and 13% indicating that they do not intend to do so.

When asked what pre-conditions their MLS might have to cooperate with RPR, answers were as follows:

• We would want license agreements specifying the details of how RPR could utilize the data and which data elements could be used.
• I say eventually because I believe that NAR will put us in the position of having to do this via the "free" approach to members. We'd be looking for proper licensing of the content to RPR for specific uses only;agreement limiting the scope of what RPR will do - no compete as far as services, etc. better outline of the future plans; how the site will be monetized beyond selling the RVP to governmental agencies; some type of alternative to "free public records" which won't be truly free to MLSs.....still too many unanswered questions to be more specific here.
• Ability to enhance RPR data and re-license to produce revenue for MLS company (not in the MLS business any longer)
• Many will hold out for compensation of some sort.
• Any data provided from MLS will have to be exclusive to the Realtor family only. Can't be sold to third parties.
• Possible revenue sharing
• Not sure, perhaps paid for the information just as any third party vendor who wants our MLS, which we no longer entertain, by the way.

Clareity suggests MLSs read this excellent post on the subject of pre-conditions from the FBS blog: wordpress1.flexmls.com/blog/what-are-the-terms-youll-require-for-nars-rpr-to-use-your-mls-data/

The majority of respondents said that RPR would drive some MLS operators and software vendors to innovate and improve their service, and 66% said this competition is good for the industry (6% said "No," and the rest weren't sure).

Finally, Clareity Consulting asked for respondents to tell us what they liked most or least about the RPR presentation and strategy. Responses were as follows:

• Like the aggregation of public records, foreclosure data made readily available to local and regional MLSs. Concerned that local nuances maybe left out. Would like to see revenue sharing ideas on the table.
• REALTORS will continue to have the most current information on homes for sale and those that are pending so our interest in the RPR should help maintain REALTORS as key to real estate transactions as the RPR becomes the most important resource to the industry.
• I am concerned about the concentration of power that this will likely vest in RPR over the entire industry. I am also concerned this may evolve beyond public records and demographics into a true nationwide MLS database, a database that would likely be a very attractive target of interest to the DOJ and FTC.
• Least - only enough info to see how they will sell it to members,not enough info about the full business plan. Liked: great platform - even if it does look like an MLS :-)
• Lack of details - do "we" get to integrate Cyberhomes products FOC into our MLS product/website? A camel is a horse designed by a committee, and I see a lot of "committee" mentality on the RPR BoD.
• The agents will love it! They won't use much of it, but they will love it!
• This tool creates a huge information resource for Realtors and equips the agent with more real estate research data than the consumer could obtain, and better quality data as well once the MLSs cooperate
• I am GREATLY disturbed by the RVM development which will be greatly misunderstood by consumers and purchasers of this developed data. The developed data will very likely be misused and eventually misleading to the consumer. I think that part was a very poorly conceived idea. No input was allowed by professional third party licensed and certified appraisers in its development of the RVM.
• Will potentially streamline and consolidate MLS's in common service areas; it potentially will reduce the cost for MLS's purchasing public records; it will provide quality data for a quality REALTOR to REALTOR platform.
• Very robust...perhaps too much so for the average Member.
• It looks like an MLS to me. The NAR directors could give the OK to offer compensation at any time, and we have an MLS.

Conclusion

At this point, Clareity Consulting is not trying to issue an opinion on either of the NAR initiatives.  This report is intended to provide our industry colleagues and clients objective information to help them understand industry reaction to these two projects, share feedback, and discuss important questions about the many details that are still in the process of being determined.

Following is a follow up article to the comprehensive "Study of Multiple Listing Service Public Listings Websites" I performed earlier this year - http://www.realtown.com/mattcohen/blog/2009-mls-web-sites-study

One of the most important elements of an MLS listings web site is to have a feature that reports on the effectiveness of the site back to brokers and agents. HAR.com did a great job of this by implementing STAR (Strategic Traffic Activity Report) and IRES has produced its ColoProperty.com Usage Reports. When planning your future effort or evaluating your current one it is important to consider how you are implementing such reports.

Typically, reports show the following overall site statistics over the preceding month, quarter and year:

• MLS subscriber leads (email, phone, text, etc.)
• Hits
• Page views
• Visitor Sessions
• Unique visitors
• Average minutes spent on site
• Total visitor minutes
• Times listings viewed

Going beyond the site-wide statistics, reports to subscribers - broker and agent levels as applicable in your market - should show their own statistics over the preceding month, quarter and year:

• The number of times their listings were viewed - this could be interactive when viewed online and allow drilldown to a real-time breakdown of traffic by listing by date
• The number of click-throughs to their web site
• The number of times their email was viewed (requires use of click-to-see email addresses)
• The number of times email was sent to them via the web site
• The number of phone calls made to them (requires use of phone redirect)
• The number of text message leads sent to them (requires text message feature)

Ideally, these types of reports should be available via subscriber logins to the web site and also 'pushed' to subscribers who have listings on the site via email on a monthly (or at least a quarterly) basis.

There are many other aspects of the MLS public listings web site value that need to be communicated to subscribers - but ensuring that these type of metrics have visibility is a good starting point.

I've been involved in scores of MLS contract negotiations over the past dozen years, working alongside attorneys to make sure business issues are properly addressed - but the environment keeps changing and I must be ever vigilant to make sure new issues are taken into account so that my clients are well protected.  Last year I posted an article on the subject – “Negotiating Win-Win Technology Contracts” (http://www.realtown.com/mattcohen/blog/negotiating-technology-contracts) but it’s time for an update.

RETS (www.rets.org) has been a boon to the real estate industry, but it has added another level of complexity to MLS system contract review.

Consider RETS when defining contractual performance and uptime language.  Back when RETS was less critical, one might define system speed, functionality, and availability as part of a performance and uptime guarantees solely in terms of common “front end” functions: this search would take a maximum of this amount of time; these statistics would take a maximum of that amount of time; these functions work substantially as they were documented this percent of the time. Now that RETS is becoming more important for many MLSs, benchmarks for the speed, functionality and availability of RETS must be included in the contract either explicitly or as part of more general performance-oriented language. Also, a process for setting benchmarks and the follow-up step of measurement against those benchmarks must be set.

It’s also important to make sure the RETS feed is available, tested, and validated as early in the conversion process as possible, and that there is a contractual obligation on the part of the vendor to provide this in a timely fashion – ideally at least two months before system cutover. This is especially important if your MLS has been providing delimited data and photographs via FTP but would no longer plan to do so with the new vendor. You don’t want a lot of last minute calls from brokers, IDX vendors, statistics producers and other companies getting a data feed from the MLS – all complaining that there is not enough time for them to learn RETS and transition to it. Even if you provided RETS to these companies in the past, the new vendor’s RETS server may likely have some idiosyncrasies or differences in RETS metadata that will cause problems if brokers and others to whom data is distributed don’t have a chance to properly test the new RETS feed properly.

Those are just two examples of how a single technology becoming more important requires MLS system contract changes. MLSs should be wary of signing extensions without appropriate review on contracts that no longer have the relevance they did during the original term and should carefully review their new contracts to ensure business issues are addressed. MLS systems are continually changing and interacting with other real estate information systems in new ways (i.e. SSO) and MLS system contracts have to reflect that. 

I'm on my way back from the RETS meeting in Chicago so I'm writing up a small recap of what I was privy to during the meeting sessions I attended.

First, a bit of background. Last week the COVE group (several of the largest MLSs) met and determined that the need to complete data standardization (improving on standardization of data fields, including field contents) was urgent. They plan to work on this to and then present the work to RESO – hopefully this will accelerate the current pace of the standardization effort.

During the “RETS Issues, Challenges & Perceptions Panel”  Matt Lavallee (MLS Property Information Network) presented a number of his theories, including an addition of or move to a standard more focused on synchronization than the current transactional approach. In his market he sees few use of ‘ad hoc’ or ‘live’ queries and provides a "live" CSV feed or direct SQL access. Other MLSs, vendors, and client writers explained their differing perspective on the feasibility of this approach. Rob Overman (LPS) in particular described the use of ad hoc queries for mobile PDA and voice-based solutions. Dan Woolley responding via Twitter indicated that one still needs transactional model for small data sets and real-time reports - CMA, buyer tours etc. Ray Ewing (SANDICOR) said that they have many vendors that query just for a few listings.

Matt L. then suggested that there are only a few nationwide vendors needing data standardization – that most vendors (local) don't care. This was not in alignment with others understanding, especially the COVE group as previously mentioned. It also didn’t make sense to me, as the standardization is a key component of making it easy for vendors to get data and provide their product into additional markets. Mike Wurzer (FBS) spoke up on the subject of data standardization to say that “Brokers are sick of the expense of disparate data feeds. Transport is irrelevant. The lack of data standards is the pain point. Data standards are possible - CARETS and others did it. RESO needs the [guts] and resources to drive that down the road.” Kristen Carr (Bridge Interactive Group) responded that data standardization is moving forward. Mary Frances Adams (TREND) indicated that “If we all agree on a data standardization and every MLS maps to that, we can all talk to one another - but we don't have to change input sheets.” This may not exactly be true if data standardization gets down to what enumerated values of any given field might be and there is no way to translate from existing fields to the new values. Matt L. made a great point – “It's not the name changes that are hard. How do you back out 12 years of old data? Condo is not a property type. It is an ownership type. How do you back out 12 years of data where condo has been a property type? To our membership the data has value in the form it is in.” Pat Bybee (Metrolist) warned, “We're not fond of mandates from NAR. When they said they would create green fields it had ripples around the industry.Setting up an aspirational standard would be good. As soon as NAR mandates something forces rally against it.” Matt L. responded, “Standard names have been there a long time but it's voluntary - no one uses them.”

Matt L. then expressed that “RETS keeps little vendors out of markets”.  While there was some agreement that RETS has a learning and support curve, there was not general agreement for the conclusion among MLSs and others present. Jeremy Crawford (SANDICOR) specified that “We've seen vendors from all industries come, in our market and I have vendors that have been successful in minutes. No way I'd open up SQL and try to lock them down.”  Jim Smith (NTREIS) said, “When we used SQL I had 2 DBAs … Now that I have RETS, I get by with a clerk. I got one support call last week for RETS. One.”

Moving on to another subject, I brought up the business concern that the standards effort was not properly resourced to move the standard forward at a good clip – COVE group is just one example of the impatience in the market. I suggested roles for leadership, documentation, project management, and communications. A discussion of how to pay for such resources ensued which I ended by saying, “Every other industry that has standards has figured out how to staff and pay for that effort. We can too.” Pat B. agreed and indicated that the RESO board will be putting a budget into NAR to address these needs. David Harris (eNeighborhoods) agreed that the effort needs resources and suggested that everyone send email to bod@rets.org on the subject to indicate their support.

The second day, the RESO board reported that they are working on a budget - workgroup chairs will submit budgets to the board soon.  They listed 2009 Accomplishments - Server compliance, document managment, improved vendor/MLS communication, and a budget process definition. The board committed to put together a RETS roadmap - purpose, mission, vision, short, medium, long term goals - Kristen Carr, Ryan Bonham, Sergio Del Rio, Steve Clarke leading. At a high level the board has short term goals for improvement - accountability, compliance, standards publication. RETS medium term goals include the strategic plan and roadmap, RETS logo and name usage, and data standardization. Long term goals include  data standardization  for additional schema, review RETS to streamline the standard, additional directions for RESO, and expanding compliance. The RETS roadmap will 'connect the dots' for these goals with timeframes, long overdue!

Hitachi showed the technical structure and features of the compliance tool at great length. They also showed their selected tool for documentation – Confluence wiki. This is exciting, though when I posted to Twitter one friend tweeted back that “Confluence is kind of challenging, actually. My school uses it predominately and, for one, formatting is a real problem. Another friend tweeted, “You'll have to tell me what you like about Confluence. We use it at work and we all hate it.” I’m still excited by this work, because improved documentation management is desperately needed and it looks like Hitachi has done a nice job customizing the tool to the RETS community’s needs.

Both RETS change proposals made by Troy (FBS) passed by wide margins:

• #79 Add Preferred flag to GetObject responses. This proposal recommends adding a flag to GetObject responses that indicates if the given object is the preferred or primary object for the requested record...In some MLS software systems, the ability for photos to be uploaded also allows for a particular photo to be marked as the “preferred” or “primary” photo for that record (without it necessarily being the first photo uploaded or moved as first in the list of photos) which indicates that this photo should be used on reports and other displays when only a single photo is shown.
• #80 Optional Query. This proposal recommends changes to RETS to allow the Search transaction Query and QueryType parameters to be optional. By making the Query and QueryType parameters optional, users only need to provide 2 required parameters (SearchType and Class) and are able to instruct the server to return all records available to their account.

Tomorrow the roadmap will be preliminarily discussed (originally this was a workgroup meeting, so I did not plan to attend) though no decisions will be made at this meeting. For some insight into my own thinking on the roadmap, see my previous posts, Completing RETS (http://www.realtown.com/mattcohen/blog/completing-rets) and Completing RETS: The Survey (http://www.realtown.com/mattcohen/blog/completing-rets-survey). I had a great conversations about the roadmap with Paul Stusiak who will be leading that discussion before heading to the airport.

It's difficult to write about opportunities for the future of the RETS standard without some folks thinking I'm bashing the past. To be clear, I honor and respect the past - but also welcome the future. Discussing the possible future of the RETS standard and engaging stakeholders can only make that future better. So, I put up a short survey for MLS executives to let their voice be heard.

In my previous post, "Completing RETS" (http://www.realtown.com/mattcohen/blog/completing-rets) I pointed out that there are some types of data that it would be ideal to represent using RETS to achieve the business objective of making it easier to move from MLS system to MLS system or to move data from MLS systems to other systems where the data could be used. When asked how important each data type was, here's what the MLS executives said:

Documenting and being able to transfer MLS business rules via RETS was the most strongly desired of the data types I queried on.  Every MLS executive has gone through some pain moving these rules from system to system. As I had previously commented on my blog, how to work with or incorporate some type of business rule markup language is an area ripe for discussion. Being able to move prospects and saved searches from system to system was also strongly desired - end-users not being able to move this data from system to system is a part of what makes MLS system transitions more difficult and time consuming for MLS subscribers. Thinking beyond the MLS, being able to move such data from broker and agent websites into the MLS - or from an MLS public website to a broker/agent website once the consumer has selected a professional to work with - would be wonderfully convenient. Customized search screens in the MLS are not that commonly used, so that didn't rate as highly. David Harris from eNeighborhoods had suggested that Open Houses was an area that needed to be better represented in RETS, and while the MLS executive segment didn't see it as that important, that non-alignment may point to the need for even wider discussion and measurement-taking, involving other stakeholders.

A supermajority of survey respondents wanted to see data types they ranked as 'Very important' or 'Important' to be added to RETS over the next year. I'm not sure that's possible given the current resources of the RETS community. To quote Mike DelGaudio, “Finishing out these remaining schemas …  is can of worms that many implementers won't be prepared to execute quickly, affordably, or safely.”  And, as one respondent said “I rated all the elements as very important and want them all this year. Will that happen? Heck no, and I know it. … RESO has [taken] years to approve what we have now. … After years of trying we don’t have common set of data definitions. If RESO can’t get that done, how on earth do you expect them to tackle some of the "people" fields (to use DelGaudio’s term).”  I agree – this is a challenging endeavor! However, if the interest is there and scope and time are truly fixed then MLS executives could discuss the third part of the project equation, additional resources, with NAR. This is all part of creating a project plan for RETS - a roadmap that we can measure progress against.

That leads to an interesting subject – the RETS roadmap. 26% of the MLS executives surveyed said they were aware of the “long term roadmap for RETS”. That’s really fascinating, because there’s no such thing. There was one back before 2007 but once we left the road heading to RETS 2.0, the roadmap was stuffed into the virtual glove box (just try finding the roadmap on rets.org) and the focus of the effort turned to small-scale changes and, based on the immediate needs caused by the NAR policy, compliance. I confirmed the lack of a long term roadmap with some RESO board members.

On the subject of MLS executive stakeholder involvement in the standard, the majority of MLS executives have not been to a RETS meeting and only 34% of those surveyed said they understand the process for making changes to RETS. The good news – of those five executives that said they had tried to get a change to RETS made, four said that they were successful. The process can work if MLS executives and other stakeholders want to get involved!

While surveying MLS executives on the future of RETS, I did ask some questions about the present that might interest the reader:

58% of respondents said that RETS has made accessing data easier for subscribers and only 16% said it made it more difficult.

• I would say that once they understand the process they like it better, but it is getting them to move to the new process that is more difficult.
• Most Brokerages are required to find vendors who understand RETS. Small vendors, in most cases, don’t have a clue.
• The vendors all seem to have different problems, they blame the MLS programmers. It seems that the different RETS clients cause different problems for the vendor which in turn causes problems for the MLS.
• Too many web masters don’t understand it.
• When we switched from one platform to another (through the same vendor) the agents still had to reenter all their saved contacts, etc. The possibility that this could be different would be a huge improvement.

• More online resources to help third parties get started with RETS.
• MLS administrators need more training as the subscribers seem to be learning RETS as well and a difficult time implementing it.
• Develop a standard RETS Client

As one respondent said, “[RETS is] easier for staff to provide MLS® because they only have to set permissions and criteria once. It’s harder for staff because now have they must liaise with 3rd Party Providers educating them as to the different "flavour" and/or implementation of RETS.”

When asked what RESO could do to make it easier, respondents had a number of comments – but most of them seemed more focused on their technology vendors rather than the standards effort itself:

• Get the vendors to understand that RETS is RETS and the MLS does not have to customize for each vendors RETS client.
• Allow more filters; i.e. a way to "throttle" the data.
• Vendors using RETS need to change their model of operation. Instead of open access for each subscriber, vendor should have an authenticate standard and then all queries are done by the vendors account, instead vendors say turn RETS on for each subscriber creating security issues.

Of those surveyed, a 53% majority still serve data primarily using FTP or some other method – hopefully this will improve over time.

There has been a lot of great discussion lately about charging for RETS, reflecting my 2003 paper on the subject (for which I took so much heat). It’s nice to be validated six years later!

One respondent clarified: “The charge is only for third party vendors who sell product to members. The real issue MLS’s need help with is defining the categories of data subscribers. We don’t charge members for RETS feeds, other than a criteria change fee.”

Let’s end this post on a really positive note. I asked MLSs what benefit they’ve gotten from RETS. There were some negatives to start with, but most of the comments were quite positive.

• I think the true test will be what impact it will have on our servers and bandwidth issues. Also updating to more current versions seems to be an issue.
• At this point none.
• Have not seen any benefits to our MLS. The programmers seem to spend more time on RETS than they do programming the MLS System for the members.
• RETS hasn’t added anything except another way to transfer data. We did fine with and ftp feed and framing. It might have made a difference to some IDX vendors, but was no big deal to MLS.
• If you ask an agent how they get data to their site, they couldn’t tell you. They don’t care as long as it gets there.
• We use ftp to send data to most third-party vendors. For the most part RETS access is used to provide members with another means of data/photo access other than our MLS vendor’s standard front end. One reason we use ftp to service third party vendors is that with RETS my staff frequently has to spend time helping the vendors understand our data structures and resolving issues with their RETS client and query structures/syntax.
• To up a RETS data feed is much, much too confusing. IDX … has an extremely straight forward up process - terminology and the layers to things up in RETS makes no sense to non-programmers

The more positive responses:

• For vendors who are familiar with RETS, they are up & running with their application within days, instead of weeks or months.
• CARETS
• More flexibility with the data, more timely updates and easier marketability for our products.
• Got rid of the ftp servers and closed the security loophole that ftp created.
• Created data standards for accommodating data from different marketplaces; created modules for our MLS application which can be unbundled and plugged into other RETS utilities
• Simplified support to vendors, stability in providing data, not needing to provide various versions as in FTP files, easier for image access (we prefer that vendors pull via http (URL supplied by RETS) versus accessing photo via RETS - saves time, bandwidth etc., able to offer real time data
• Expedited, more secure, and manageable means of data transport.
• Better support and access to real time data
• Better, more accurate and standardized feeds available to our members.
• The move to RETS has made the prospect of data sharing with neighboring systems more straight forward. The neighbor can pull down the data on their own with limited use of our programming staff.
• We have been easily able to partner up with third party aggregators.
• We’ve had a few venders that will only do RETS, so this has opened a door of opportunity for them to present their product to our members.
• List Exporter (self hosted) uses RETS to provide filtered IDX files which requires very little policing of IDX sites.
• Depending on the service - brokers might pay extra.
• For the vendors serving our subscribers it is very valuable.
• Much easier to implement and provide from our side. Non-dues revenue - increased choice for members dealing with 3rd Party Suppliers - better controls for access to MLS® data
• We use it internally to calculate some statistics and to feed a MLS Data Checking tool. It feeds our public website and a good portion of our broker IDX feeds. I agree with the responses to the blog, facilitating the transport of saved searches and such is a very big deal.
• It’s important for the future of real estate to have a standard that is going to put everyone one on the same page. RETS has opened a lot of doors as far as data is concerned for us and all MLS’s that are utilizing it but it’s a standard so I believe it will change as needs and demands evolve!

RETS has come a long way over the past ten years on the backs of hard-working volunteers – but there is room for RETS to mature further. Involving stakeholders and looking at business objectives with fresh eyes will be important as we move forward. Putting more resources behind the effort and continuing to formalize the requirements gathering process, the road map, and the project planning and communications side of the RETS effort will be crucial, if one wants to see more than small incremental changes to the standard made over a long period of time. Working to restructure the effort and providing the resources needed to do so will require resources for RESO that MLS and Association executives will need to advocate for, if they have an interest in RETS moving forward in ways outlined in this article.

The Fall RESO/RETS Conference is September 23rd - 25th, 2009 in Chicago, IL - more information is available here: http://www.rets.org/meeting

A standard, like software, is never complete - it just goes on to the next version. But, the RETS standard has been going on for ten years - I think it's time to take stock about how far it has come and talk about where it could or should go.

If you're an MLS executive or an agent, why should YOU care about this RETS stuff moving forward quickly? Doesn't it already facilitate your data feeds, syndications and MLS collaborations? Think about this - recently I was negotiating an MLS contract and wanted to know what data, created by my client and their subscribers could be moved from the old system to the new one:

• Listings? Of course.
• Roster? Of course.
• Contacts? That might be possible with custom work, not using RETS.
• Prospects? No.
• Saved searches? No.
• Custom columnar reports? No.
• Custom search screens? No.

More than half of the items that we wanted to move from system to system using RETS couldn't be done. Each one we couldn't move would mean pain (time/effort) for the MLS subscribers as they had to re-create the data in the new system manually. This isn't just relevant to moving from one system to another - it's relevant to offering a parallel system - or multiple MLS front-ends - or any number of potential MLS add-on products. And I could make similar points about the difficulty of moving between other real estate systems, such as association management and transaction management systems.

This difficulty in moving systems or adding systems (some would call this the "friction  of the transaction") does not encourage the most competitive marketplace for real estate technology - and this is bad for my MLS and Association executive clients and bad for their subscribers and members. Face it - most of the people driving the data standards are more established vendors - and they do not have incentive to improve standards to make it easier to move to another system. So, if you want the standards completed to the point where you can move *all* of your data from system to system, increasing real estate application innovation, increasing competition in the technology marketplace and making transitions between systems easier for your members - YOU have got to work with your peers to drive the standard forward.

If you want to contact the Chair of the RESO Outreach and Education committee, email Kristen Carr (kcarr@big-llc.com).

The Fall RESO/RETS Conference is September 23rd - 25th, 2009 in Chicago, IL - more information is available here: http://www.rets.org/meeting

"Is Google a scraper?" That was the question at the center of news stories surrounding MIBOR's decision to tell a broker not to let Google index their site. The quick answer is "No" - there was no restrictive terms of service or limiting robots.txt file on the site, so technically Google did absolutely nothing wrong. But the question being asked ... that was the wrong question.

Finally, after the hype died down, the 'real' question started to emerge: "Should or could MLSs require that brokers not allow individual listing pages be indexed by search engines".  Since listings are given to brokers for advertisement, unless the seller opts out of online advertisement, since most consumers are searching for property online and search engines are an important part of online marketing, search engines will be an important component of giving listings the proper exposure and should be leveraged as much as possible. Also (and obviously) the MLS could probably make rules pertaining to an IDX feed but realistically not regarding the broker's own listings. But whether search engines should be allowed to index the sites is again the wrong question.

What's the real concern here? We've had IDX for some time - was it really just okay when it was invisible to search engines? Of course not. The real concern about 'data scraping' only comes from when the data is misused - that is, used for a purpose other than that intended by the homeowner when they provided the information to the real estate professional and by that professional when they added their own creative descriptions to the data to create the often copyrighted listing content.

What kind of misuse has there traditionally been? When a site is easy to scrape someone can come along and grab the listings in an automated way for display in an unauthorized location. Data can also be recompiled to create derivative products or to market back to the consumer. If the scraper adds an automated reverse telephone look up to scraped data, someone giving a real estate professional information to market their property one fine morning may find themselves called by moving companies and other service providers that very evening - and it reflects poorly on the real estate professional when that happens. So, the real question we need to ask ourselves is,  "How do we stop the misuse of data while not compromising the ability of the broker to market properties and promote the web sites on which the properties are located?"

Let's look at the type of requests consumers put into search engines. I believe that there has been a lot of hype about needing the whole address in the web page title and that individual addresses need their own website. Do consumers really expect to type in "100 Test Street in Testville, TN" and come back with a website? I don't think so - not at this point. We all know how the traffic comes in via web site search terms: "houses in Testville, TN" ... "Testville Tennessee real estate" ... "homes in Testville" "Subdivision Name in Testville". So, city, state and neighborhood/subdivision are obvious candidates  to allow a search engine to index. Key attributes might also be searched on - "lake view" etc. But the full address? Price? Bedrooms? Bathrooms? Square feet? Lot size?  I say, "ridiculous!" Are they needed for search engine optimization (SEO)? I believe the answer is an emphatic, "No". Since those bits of data don't help in the indexing of the listing by search engines for marketing of the property online BUT they are prone to misuse when programatically gathered (scraped) there is no reason why MLSs should not require that websites put anti-scraping mechanisms in place on those key items, while allowing search engines to programatically gather other information for the purpose of providing free links back to the web site.

But, anti-scraping begins at home. Less than 5% of MLS public sites have any anti-scraping in place to speak of - and good  measures are far more rare. But, I digress - before we launch into a tangent of anti-scraping tactics, we need to agree on a strategy for the level of protection required for the data to balance marketing with information security and privacy, and we must set policy that is reflected in contract terms pertaining not only to industry sites but to syndication endpoints as well.

Note - I've been traveling for more than a week and am writing this at o-dark-thirty in an airport parking lot - it's not my finest piece of writing - sorry! Hopefully I'm getting the ideas across anyway...

I hope that MLS executives and board members find this presentation about the MLS Mission Statement educational and useful when considering strategic planning activities. 

View the presentation here: http://www.callclareity.com/MLS-mission.cfm

I have an MLS client who wanted to get the 'lay of the land' when it came to MLS public sites. I called over 50 MLSs with public sites and asked a few questions of interest to my client - perhaps you will find the answers of interest as well:
 
Do you display sold/off market listings on your public site(s)? 
NO- 29        YES- 10        Considering- 13
 
Do you allow your brokers to display sold/off market listings on their sites?  
NO-17        YES- 21        Considering- 14
 
Do you display property address on your public facing web sites and online partner sites?
NO-4        YES- 36         Opt Out- 14

Visiting 94 public web sites, I found that 93% displayed street address and 95% of those displaying addresses also displayed a map to the  listing.

 

One of the highest rated sessions at Clareity's MLS Executive Workshop was the "Virtual Office Websites: Challenges and Opportunities" presentation. I've posted the presentation, along with some talking points here: http://www.callclareity.com/VirtualOfficeWebsites-2009.pdf

I have posted the results of the 8th Annual MLS Customer Satisfaction Survey on http://www.callclareity.com/ - linked right from the home page. This year, 178 MLSs (14 more than last year) completed the survey, representing 817,140 subscribers. 

The Annual MLS Customer Satisfaction Survey is a valuable source of input for MLS executives when evaluating a vendor's service and system capabilities, but I encourage all clients to do their due diligence: there are many factors to consider in evaluating which MLS system is best for your specific organization - this is just one piece of the puzzle.  

When I help an MLS organization in their system selection process I always try to guess what the final selection outcome will be after I get back the proposals (but before the final demonstrations). Reflecting on the last three RFPs where my guess was incorrect over the past few months, the following were the reasons why:

* In the first RFP, I thought they would value performance and ease of use but they prioritized robust reporting and statistical outputs.

* In the second RFP, I thought they would prioritize price, system customization capability and overall system satisfaction but they made a surprising selection and couldn't really articulate why they went the way they did - but I don't second-guess clients.

* In the third RFP, I thought they would prioritize the 'partner fit' as the two finalists fielded very competitive systems at similar prices but their impression of the system overall was the most dominent factor in their decision.

I always try to make sure clients have the most thorough information at their fingertips to make a good business decision in an MLS system selection process, but how they will weigh that information and make a final decision is always interesting and the unexpected results fascinate me.

I’ve been looking at some of the “next generation” of consumer real estate search – beyond “natural language” search – this search includes commute time to jobs, cost of living preferences (insurance, entertainment, housing, utilities, etc.), distance to amenities (parks, grocery store, gyms, golf, airport, etc.), school information  and performance, crime/safety information, and other demographics (own/rent, age, occupation type, education, income, family size), neighborhood and property foreclosure information, as well as all the traditionally searchable MLS fields. Consumer sites are also starting to get more sophisticated about suggesting homes that are similar to others the consumer has displayed an interest in and ordering the search results on relevance to all of the aforementioned lifestyle and demographic criteria and weighting as indicated by the consumer.

In contrast, MLS is still mostly focused on searching and displaying the listing characteristics, and prospect searches are often displayed in order of price rather than on the more complicated criteria that consumers use to select neighborhoods and homes. I reflected on this limitation to some degree in my earlier blog post, “ Improving Prospecting Part 2 - Gesture and Intent and Beyond

Now, imagine the consumer goes through the effort of outlining their lifestyle and other non-listing-characteristic criteria on a web site and are presented with the carefully selected listings that match both their property characteristic criteria as well as all those other parameters. When they go to the real estate professional, that professional  has no way of inputting any of that into their MLS for search – let alone having a way (say, via RETS) to have all of that preference information flow automatically into the MLS from the consumer’s search site(s) to generate a search for their new prospect.

MLSs can’t get complacent about new property search capabilities and leave them to consumer oriented websites alone to implement. As I’ve described above, there’s a relationship between consumer search and professional search that will necessitate, at the very least, following in the use of these capabilities and implementing the means for consumer preference data to flow from system to system.  Or even better, real estate professional IT systems can lead those accessed by the consumer, allowing the professional to provide the consumer with additional professional-grade information and interpretation that helps maintain the real estate professional’s  value.

In advance of Clareity Consulting's sold out MLS Executive Workshop I asked MLS executives from around the country how they have either cut costs while maintaining the same level of service or kept costs the same while increasing the level of service they provided.

I received twenty-one great ideas that will be shared during the Workshop, and I'm sure others will come up during the Workshop itself.

One idea that I'm looking forward to discussing is 'unbundling' products and services to reduce costs to those that don't utilize much service.  I can see how this could reduce the cost for some people to belong to their local/regional MLS, especially those who cut back to the absolute basic MLS package. But I believe that the subscribers that would do this are doing wrong by both their industry and consumers by decreasing their own use of the information tools that  enhance their professionalism.  The whole industry can be painted with the broad brush of unprofessionalism based on the actions of these subscribers. Further, this decreases the buying power of the MLS for providing those professional-grade  tools that the subscribers need now more than ever to show value to the consumer.

I can see where unbundling makes sense - it seems logical that people should only pay for those resources they use - but I have those more strategic concerns. I am really looking foward to  the Workshop!  

According to a letter sent to MLSs and associations by NAR, "When associations use the Realtor Ecommerce Network, the burden of meeting the PCI security standards falls on NAR, the merchant, rather than the associations." This is incorrect and puts these organizations at risk.

For those not familiar with PCI compliance, If your organization accepts credit cards, there is a set of rules you need to be aware of called “PCI Data Security Standards”. PCI stands for “Payment Card Industry” and includes the five major credit card companies. These companies have all agreed that any company that stores, processes or transmits credit card or debit card data must comply with a rigorous set of information security guidelines.  By the end of 2007, any organization that accepts payment card transactions was supposed to be in compliance with the standards – and if not, the credit card companies (or the bank through which the cards are processed) could assess fines on non-compliant companies and even disallow further credit card transactions until PCI Data Security Standards compliance has been achieved.

To clarify this issue, I quote from the PCI Security Standards Council (https://www.pcisecuritystandards.org/) site: "Does PCI DSS apply to merchants who use payment gateways to process transactions on their behalf, and thus never store, process or transmit cardholder data? PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted."

The key words here are "processed or transmitted". Let's say I had a web site that sold widgets and I linked out to Paypal when people checked out on my site. To be clear, when the user input their credit card information, the URL in their web browser said "http://www.paypal.com" and no portion of the checkout process involving the credit card involved my web site. In that scenario, my web site has nothing to do with the credit card information - the information is never input on my web site, processed or transmitted from my web site - everything happens at Paypal - so they are the only one that needs to be PCI compliant. If, for example, NAR were to fully host and audit the association management systems AND other credit card systems where credit card information is processed and transmitted, then they could be solely responsible for PCI compliance - just like the Paypal example. However, MLSs and Associations take credit cards often on paper or via email (electronic fax), via point of sale devices, and allow for the input/processing and transmission of the credit card information via a system that is located on their local area network. Therefore, it is the responsibility of such MLSs and Associations to attain their own PCI compliance.

PCI compliance is not easy to attain and maintain, but it's just part of doing business within the rules. My company, Clareity Consulting is working with a number of MLSs and Associations to help them attain PCI compliance - and our sister company, Clareity Security is the exclusive real estate industry reseller of McAfee Secure, which provides ongoing vulnerability scans required to fulfill the PCI requirements.

If you have management responsibility for such an organization and don't have your PCI compliance documentation in order, you may wish to consider moving forward on that quickly in 2009.
 

Clareity Security set the standard for real estate industry standard for login security over four years ago, introducing strong authentication to the industry. Strong authentication, also termed "multi-factor" authentication, involves two of the three following items: something you know (e.g. a password or PIN), something you have (e.g. a token, PDA or cell phone), or something you are (e.g. biometric information). Recently, some have promulgated the idea that "adaptive security" can replace strong authentication, implying that adaptive security is comparable in strength to strong authentication - this is simply misleading.

Adaptive authentication tries to detect abnormal use and then takes action when that abnormal use is detected. For example, if a user usually logs on from Detroit, Michigan and there is a logon attempt from Honolulu, Hawaii, the system would attempt to make an assessment of whether the logon was valid. That works great in the banking context, but it just doesn't apply in any significant way to MLS authentication security, where the most common problem is users intentionally sharing accounts within the same geographic area and even within the same office, where they would likely be using the same computer type and perhaps even the same IP address. MLS users also utilize a variety of computers to access the MLS - at customers' homes, at coffee shops, or sharing computers in broker offices - that makes it even more difficult for adaptive technology to reliably distinguish between legitimate and illegitimate logon attempts. To have MLSs interrogating users to try to distinguish between true "cheaters" and false positives – it's untenable.  It will anger legitimate users, and be a waste of staff time to boot!

Last year, Clareity Consulting reviewed security at an 1100 member MLS, evaluating the usage of 800 UserIDs used over the course of a day. Of the 800, 5 UserIDs would have been noted as suspicious behavior by adaptive authentication technology - logging on from five or more IP addresses during the day. However, more thorough review revealed that 3 of the 5 were legitimate uses - users using wireless cards and crossing cell tower boundaries or logging in from different client homes and their own office. In this evaluation, only 3 users had abnormal download amounts – two were not actually "cheaters", but one was and this correlated with the excessive login report. All of this illustrates the problem adaptive authentication has creating "false positives". Worse yet, over 150 of the 800 UserIDs were found to be sharing account information but were using three or fewer IP addresses during the day - the same rate as the non-abusers - and since system use times were short, it was extremely rare (<2%) that these users would have tripped the "simultaneous logins" alert. Some of the "cheaters" even only used a single IP address and a single computer during the day! They work together in the same office so they appear to be ONE user to adaptive authentication.  Is having a 60% false positive rate while letting more than 95% of the "cheaters" off the hook indicative of successful security technology? The answer is clearly, "No!"

What is worse is what happens when adaptive security thinks it has found a cheater. Typically the next step is to try to validate the user so they can get into the MLS right away (say, before their listing appointment) by asking them secret questions. This level of security isn't any better than standard password security since three things the user knows (username, password, question answers) isn't any better security than two things (username, password) and is just as easy to share among “organized cheaters”. In fact, once you understand that adaptive security isn't actually "strong" and often boils down to knowledge-based authentication, one must ask the question, "Can knowledge-based authentication be effective?" A study done by respected consultants Forrester Research (http://blogs.forrester.com/srm/2008/04/end-user-securi.html) says the answer is "No". If the adaptive system is allowed to go to the next level and suspend accounts - in a system doomed to false positives - one is treading in dangerous customer service territory. 

Taking this even further, protecting the web interface is just one part of the MLS authentication problem – subscribers (and cheaters) utilize PC-based software for  both attended and unattended downloads of information, use tools such as RETS, and are increasingly moving to wireless devices and even  interactive voice response (IVR). Most of the adaptive technologies are device dependent, and are not extensible to the many ways that real estate professionals currently access information or those ways that will surely become more prevalent in the future. How can it deal PDA or third party software or with unattended downloads? This is why Clareity determined that one of the most critical success factors for a strong authentication mechanism was ensuring that it was device and platform independent.

Even if one willfully ignores how adaptive authentication concept doesn't work for real estate industry use cases, the technology itself has not had a good security track record. The following article discusses how RSA's implementation was defeated back in 2007 - note that it remains defeated today:
http://blog.washingtonpost.com/securityfix/2007/11/new_malware_defeats_sitekey_te.html

Some have pointed out that financial institutions use adaptive authentication – they are correct, but what they leave out is that banks are swiftly moving away from adaptive authentication alone and are moving to strong authentication mechanisms. Most people are familiar with initiatives such as Bank of America's SafePass, sending one time passwords to the cell phone via SMS text message.  Note that Clareity Security has the exclusive patent for the real estate industry for sending one-time passwords via SMS text messages. That's reflected in Clareity Security's deployment a few years ago of TEXT-pass, an authentication method that doesn't require tokens.

While some of the reporting capabilities inherent in adaptive authentication technologies have a place in a multi-layered authentication defense, adaptive security on its own is not strong authentication, and cannot be considered to provide a similarly high level of security - as would be required for MLSs considering data sharing or regionalization when one or more of the parties had already implemented strong authentication security.  Attempts to mislead or confuse the marketplace by stating that adaptive security has high value and is an actual alternative to strong authentication, are simply shameful.