Real Estate Data Sharing and Alignment

A RESO White Paper

Access to broad data creates opportunities to improve real estate information and services for professionals and consumers. The real estate information marketplace’s value is increased through well-planned combinations of data sets between organizations. Multiple Listing Services (MLSs), in particular, can create greater efficiencies when combining large sets of data across geographies.

There are many ways to create these efficiencies, one of which is data sharing initiatives between MLSs. Data shares are not always the right answer for a given organization’s needs and can be difficult to scale as participating organizations and their technical systems grow in number. But they are prevalent and worth understanding. In any collaboration, the role of standards in aligning combined data is a critical knowledge point.

This white paper from the Real Estate Standards Organization (RESO) was developed in partnership with companies that have built and managed data share initiatives, from technology vendors to MLSs to trade organizations. Their experiences provide insights into the potential benefits, challenges, and decision points for organizations seeking to combine multi-market data through a data share or an alternative method.

The guide will explore:

• The current state of data sharing in the real estate industry
• Planning, development and maintenance concepts
• Business challenges for creating and maintaining a data share
• Technical challenges, described in a straightforward, nontechnical fashion
• Best practices to align, integrate and share data between systems and organizations

Contents

• Why MLSs Share Data
• The Technology Systems that Data Shares Support
• Data Terminology
• Current State of Data Shares
• Background: Data Creation and Distribution
• Types of Data Shares
• Breadth of Data Sharing Access and Rights
• Features of a Successful Data Share
• Data Alignment Preparation
• Business Challenges for Data Shares
• Technical Challenges for Data Shares
• Getting Started
• Acknowledgments

Why MLSs Share Data

MLSs share data with one another to create business efficiency for their primary customers, which are real estate brokers and agents. These customers employ the shared data to improve their services to consumers through better technology and information.

Property owners, buyers and renters transact real estate based upon their own needs and preferences. These preferences are not set by an MLS’s self-defined service area. Consumers define their own marketplace boundaries. So they pursue data that crosses MLS borders.

MLSs and their brokers utilize data shares to serve differing data needs of their customers, including:

• Across a large geographic area
• In markets with overlapping MLSs
• For relocation to a new area
• For referrals to out-of-area brokers

The data employed in a data share is only authorized for specific uses by the parties involved. These uses can range from brokers and agents viewing the listings in an MLS system to incorporation in client reports, statistical models, consumer apps and public displays.

Harmonizing data across MLSs can also provide benefits to downstream technology vendors. The MLSs become regional data hubs that allow those vendors’ services to scale more quickly.

The Systems that Data Shares Support

Brokers have many needs for this cross-market data, including:

• Brokerage and MLS tools: production tracking, transaction management, financial reporting, accounting, payment processing
• Agent reporting: customer relationship management (CRM), showings management, comparative market analysis (CMA) reports, prospecting, property histories
• Consumer marketing: websites, search apps, listing alerts, saved consumer searches, home valuation reporting

Data Terminology

Data alignment is arranging different data sets into a format where they can be combined into one larger data set. The current state of a data set’s alignment, or lack thereof, should be assessed at the beginning of planning for a data collaboration.

In a simple example, three real estate data sets might call the price of a real estate listing “Listing Price,” “Ask Price” and “Offer Price.” In data alignment, those three sets of prices are all aligned under a standard name, “List Price,” and the disparate data sets can now be combined efficiently together.

This alignment can happen at the source data system but often happens in on-the-fly transformation by the technology providers doing the data integration.

Data integration is the process of combining information from multiple sources into one unified set of data. Separate sets of data from different data producers are aligned according to standard definitions and consolidated into a consistent source of information.

Data integrations can be used to power products within one organization or across many.

Data shares describe one of the most common data integrations in the real estate industry. MLSs allow their customers to access information from other MLS organizations by integrating their separate data sets into common technology systems. This guide will explain some of the methods for data sharing.

Data shares can take on many forms and can be complex, much like the greater real estate industry. This guide will break down common models and simplify them, highlighting tips, best practices, challenges and requirements for successful data shares.

Current State of Data Shares

Hundreds of MLSs are involved in data shares. Some are national, some are regional and others are one-to-one reciprocal MLS agreements.

It’s common for an MLS to be involved in multiple data shares. This could include a nationwide data share in a third-party product, as well as direct data sharing with select partners in the MLS’s primary software system.

Data shares displayed on this map were contributed by the data share operators involved in the collaborations. While not all U.S.-based MLS data shares are displayed, the broad adoption of data shares in the industry is evident.

With the benefits of data sharing evidenced by this broad usage, it’s important to document the best practices and obstacles to help potential data share participants make informed decisions.

Background: Data Creation and Distribution

Before analyzing the different ways data shares come together, it’s important to clearly understand how real estate data is traditionally created and distributed, one listing at a time.

Listing Data Creation and Distribution from Seller to Buyer

Listing Creation: Seller, Agent, Broker

An MLS data share’s primary content is listing data fields and media such as photos, videos, floor plans and other documents. This includes real estate listings for sale or for rent and often sold and leased transaction data. Individual listings in technology systems are sometimes called property records.

Property listing data is first created by a property owner coordinating with a listing agent who works for a brokerage. The owner signs a listing agreement that belongs to that agent’s brokerage.

MLS Listings: Input, Maintenance, Output

The listing broker submits the listing agreement to an MLS. The MLS stores listing records in a database. These property records then go out through the MLS user interface (UI) for agents to view, for apps that share listings with agents and their clients, and for data feeds that customers access through an application programming interface (API). MLSs often have additional offerings like data shares, tax and public records data, and derivatives like statistics and reports.

As the listing agent and broker update listing details, statuses and media, that data continues to flow down to the MLS’s services, as well as to the agents working with property owners, buyers and renters.

Types of Data Shares

There are many types of data shares. This guide uses the broad concept of property data being accessible from one organization’s users to another set of users, regardless of technology or venue, to categorize data shares.

From the perspective of the agents and brokers involved, these basic visuals show how their data flows through data shares and where they can access that shared data. The types of listings that are integrated and the usage restrictions can vary among data shares (active vs. sold listings, view/share/publish data).

Custom MLS Integrations

One of the most common types of data shares occurs when MLSs and their vendors engage in custom work for one-to-one partnerships. Each MLS gets access to the other MLSs’ APIs, pulls down the data and transforms it on the fly to integrate that data into its own data set.

With no requirement for any participant to be on a shared software platform or database, the MLSs and their vendors customize a technology solution to work for their unique situations. These integrations are effective but can be challenging to scale due to the custom nature of working with different software platforms.

Data is often being transformed in every transfer between each organization, or node, on the data share network. As these custom integrations are between different technology platforms and organizations with changing business rules, the data alignment, timeliness and accuracy complexities can grow significantly as the data share grows.

Shared Primary System

In a shared primary system, MLSs are using the same MLS software platform. The single software provider integrates each MLS’s data set into the other systems.

Users see the listings from other MLSs in the same MLS interface they already use. While these data shares are effective, primary MLS systems are often not transporting standardized data. This can limit the efficiency of the data share when attempting to scale it to include MLSs on other software systems.

Shared Database

In a shared database, MLSs aggregate their data into an independent data repository. This repository delivers the shared data back to each MLS’s system. This model works for MLSs using different primary software platforms.

In practice, these shared repositories are more than just databases. They may have their own APIs, input modules, distribution features and more. They can be developed directly by MLSs or technology partners. The brokers and agents see the larger combined data sets in their desired user interfaces.

Reciprocal Access 

In reciprocal access, MLSs agree to allow users from all participating MLSs to log in to one another’s systems to see listings. MLSs can initiate data sharing in this way even if they use different software platforms and lack the ability to create an independent shared database.

Security is always a top concern when allowing new parties to access systems. Access to reciprocal data shares might be done through reciprocal login credentials for partner MLSs’ subscribers, reciprocal links or single sign-on solutions.

The requirement for agents to log into a separate system from their usual MLS interface can be a barrier to high utilization.

Shared Aggregator View

In a shared aggregator view, MLSs aggregate their data into a third-party system (not an MLS’s primary software system) and allow users to view this shared data in that third-party system. The data is not distributed back to the MLS systems directly.

While this model looks different than the typical data share, it provides the simplest access to technology implementation for MLSs. The largest data share in the U.S. is a shared aggregator product called RPR View from the National Association of REALTORS® subsidiary, Realtors Property Resource. It accounts for 200+ MLSs sharing data with other MLSs nationwide and another 100+ MLSs sharing regionally.

The benefits of simple implementation also come with the challenges of gaining high usage by customers. Brokers and agents are used to finding property data in their traditional MLS interface and the need to log into a separate system can limit the level of utilization.

Shared Aggregator Distribution

In shared aggregator distribution, MLSs aggregate their information in a third-party product that delivers a combined feed of data downstream to broker tools and other vendor tools.

Breadth of Data Sharing Access and Rights

Data shares often progress through stages. They begin with MLS participants finding value in the simplest method. Over time, participants tend to want more streamlined access by being able to see the full data set in their own MLS’s primary front-end system.

There are also different types of data sets. There will be specific agreements between MLSs that define the allowed uses of each kind of data, such as:

• Internet Data Exchange (IDX) Data: Information and media to be shared on websites and apps publicly by participants of MLSs
• Virtual Office Website (VOW) Data: Similar to IDX but also including information only to be shared between an MLS’s participant broker, their agents and their registered clients
• Broker Back Office (BBO) Data: Information that MLS participant brokers are licensed to use in their company tools but not share with the public
• Participant Data Access Policy (PDAP) Data: A single broker’s data that can include fields that are only allowed to be viewed by that one individual broker (as opposed to BBO, which is a multi-brokerage data feed)

Features of a Successful Data Share

The technology implementation of the data share will be critical to its success. A data share should provide a unified set of information that is timely and accurate. Past data share experiences have indicated a need to plan to have personnel available to manage business administration and technology implementation details.

Common Rules for Usage

Brokers and MLSs in the data share may be granted different levels or rights to use the data. These capabilities and restrictions should be laid out in detail.

• Is the data only available to view listings within the MLS? (Common implementation)
• Can the brokers use the data in CMA reports, and are those report providers capable of integrating the data?
• Can the brokers display the data on a public/IDX or VOW website?
• Can the brokers continue to use or display the data after the property is sold?
• What happens if the data share is dissolved?

No organization plans to fail, but some initiatives do. The sharing partners need a plan for diligently removing their data from the systems involved. Lack of a plan can create confusion and aggravation for MLS staff and members.

The licensing agreement for initiating a data share, maintaining and using it, and potentially shutting down the service should be complete prior to sharing data.

Strong Communications Channels Between MLSs

Data shares are not “set and forget.” After the initial implementation takes place, there will continue to be changes for as long as the data share exists. This should be a common understanding for the staff of all participating organizations.

Each individual MLS will be making changes to its data set, requiring all others to react. There will be changes in field names, lookups and the data in property records, sometimes tens of thousands at a time. The leaders of these MLSs should be participating in regular meetings that report on planned data changes and allow for discussion as to why others in the group might want to adopt similar field additions or changes.

Leadership may see value in functional teams meeting across MLSs as well. Staff working in technology, compliance and other disciplines might find value in coordinating their efforts when managing changes to the data share. Aligning along common rules is more likely to happen when staff members are working together and having an open dialogue rather than reacting to any perceived misalignment by outsiders.

Strong Communications and Training for Customers

Communicating the reason for the data share and the process of rolling it out are important steps in keeping all parties aboard. A thorough, highly scheduled communications plan should be developed prior to announcing the initiative.

Users will need training on rules for data usage in any scenario and on the data share software features if the MLSs share a primary system. Full product training will be needed if the MLSs are using a shared aggregator view, and there should be a guide for the services being offered if the MLSs are providing a shared aggregator distribution service.

Standard Fields and Local Fields

Data shares will include fields that are part of the RESO Data Dictionary and unique, local fields. Local field names that are synonyms for standard fields can be mapped to RESO Data Dictionary field names for alignment. Doing so prepares the data share for faster integrations if other MLSs join in the future.

A number of MLSs with the same software vendor might have the same nonstandard names for standard fields in their core systems. This might make it seem efficient to start a data share with the nonstandard names between MLSs using that same vendor. But not standardizing for the data share upfront could impede the data share’s capabilities to integrate with other systems and markets in the future.

It’s important to include the unique local fields in the data share, even if they are not part of the RESO Data Dictionary. Unique local market information is important for the brokers and consumers viewing this data. The most robust implementation would include all standard and local fields (as allowed by license) that an agent can see in its MLS also included in the data share.

Provenance: Documenting Data’s Identity and History

Maintaining records of the source of information can be important depending on the complexity of how data is being delivered and where aggregated data sets will be implemented. A record of where data was first created and all of the different systems the data has traveled through is called the data’s provenance.

For example, MLS data might flow through a multi-MLS aggregator, into a different multi-MLS data share and then into broker tools that consume content from multiple data shares. If the property records have changed in any way through these steps, understanding when and where the changes happen can make data reconciliation easier, thus avoiding duplicate and mismatched listings, statistics and reports.

Obstacles to Maintaining Data Provenance Records
The real estate industry, by and large, has not implemented industry wide unique identifiers in property records to maintain accurate data provenance. Using IDs that are unique only to one system or one MLS causes data collisions and confusion in multi-organization data integrations.

Common obstacles:

• Brokers and agents across states and license types have identical license numbers
• Participants and subscribers across different MLSs have identical MLS ID numbers
• MLS organizations have multiple technology systems that distribute their listings
• Downstream tools receive data that has traveled through multiple layers of technology systems and that has been altered during the distribution process

Unique identification differentiates between brokers and agents (licensees), companies (organizations) and technology products (systems). The ideal identification that a data share’s records would maintain include:

• Originating Broker and Agent IDs: The licensees that originally created the listing record for the property
• Originating Organization ID: The organization (usually an MLS) where the listing record was originally created
• Originating System ID: The originating organization’s technology system that gives access to the listing record (often an MLS’s API service)
• Source Organization ID: The organization from which the listing was most recently directly received (could be the originating organization or a downstream organization in a multi-layered distribution)
• Source System ID: The system from which the listing was most recently directly received (could be the originating system or a downstream system in a multi-layered distribution)

Example:
In a simple MLS scenario, a user could send a request for listings based only on the listing ID numbers of the requested properties. But those listing ID numbers could be the same for two different properties in two different organizations:

• In MLS A, listing number 111111 is for 123 Main St
• In MLS B, listing number 111111 is for 456 Pine St

A downstream service could identify a unique listing if it received both the MLS’s organization ID and listing ID for every listing. Some vendors prepend an MLS organization ID to the MLS listing ID when sending the data out to a data share or other integration.

Multiple data shares sending data to showing and CMA services need to agree on which ID identifies the MLS that created the listing to uniquely identify listings across MLSs. Without using a common identifier system for MLSs, identifying the originator of each listing becomes a  complex, brittle process of bolting nonstandard rules on top of one another.

Complex Processes and Relationships Benefit from Data Provenance Practices

Aligned Property Data: Universal Parcel Identifier (UPI)

A property might be listed by a broker in three different MLSs. Each of these listings would have different MLS listing ID numbers. Listing addresses are also inconsistent, such as 3rd St vs Third St. vs. 3rd Street. These differences might be from human input or vendor dependencies, like a geocoding system returning its version of an address.

A data share might receive these three listings with differing addresses and listing IDs for the same property. The Universal Parcel Identifier (UPI) can be used to signify that all of these listings are referencing the same property. If the three listing records all include the same UPI, the downstream consumers of the data share, MLS and broker systems can match them with one another and display a single view of the property to customers instead of displaying it three times.

Aligned Organization Data: Unique Organization Identifier (UOI)

Maintaining identification of the organizations and systems in the data share flow is important. RESO’s Unique Organization Identifier (UOI) service supplies a set of IDs for organizations in the data provider space like MLSs, brokers and their software vendors.

Data providers can employ these public, consistently maintained identifiers to record the provenance of data as it passes through different organizations. Data consumers rely on these broadly used IDs to understand which organizations supplied the information that they are accessing. The demand for more data provider implementation of these IDs is growing.

Aligned System Data: Unique System Identifier (USI)

The source of data includes both the organizations that allow access and the technology systems that are involved. RESO’s Unique System Identifier (USI) provides a mechanism for maintaining records of these technology systems.

Most often, MLSs use an API service to allow access to their data. An MLS might have API services from multiple software vendors, and each of those software vendors might have multiple different versions of their API products.

Each version of an API service has its own USI so downstream consumers will understand the source of the data. By tracking the organization and the system that provided the data, data consumers can better understand why their data might look different coming out of one system vs. another.

Aligned Licensee Data: Unique Licensee Identifier (ULI)

Brokers and agents, the licensees who create listings and transactions, can carry multiple licenses and MLS IDs. A single identifier for every licensee would create a significant opportunity to align data records around the practitioners involved in real estate transactions.

RESO is testing a model for a Unique Licensee Identifier (ULI) with multiple MLS organizations and technology vendors. More support for this initiative is needed to provide valuable data alignment tools to stakeholders in the industry.

Data Alignment Preparation

There are many resources available to prepare an MLS to thoroughly investigate a potential data share. Understanding the data of all parties is critical.

RESO Analytics Certification Reports

An objective source for identifying the fields that will be included in a data share is the RESO Analytics platform. MLSs have their data available via an API service. When the MLS applies for certification, RESO analyzes the service’s capabilities and the data set. Upon ensuring these items are in compliance with RESO standards, the system receives a certification endorsement and RESO Analytics reports.

These reports allow the MLS to analyze all of its data elements from RESO standard fields, local fields and specific data sets like fields intended for IDX data feed usage.

The metadata, or menu, of data elements is analyzed and matched to the property records. The fields within the property records are used at different frequencies by the agents and brokers.

The availability slider allows users to see which data elements are available and used most frequently by the parties that are creating the property listing records.

Users should review:

• Resources available
• Fields within resources
• Lookups and their associated lookup values
• The availability of field and lookup data (how often there was data in these fields for the tested property records)

Performance (and Why It’s Important for Data Shares)

RESO Analytics certification reports also offer an option for certified data providers to show their system’s performance. These reports allow customers to assess the speed and depth of the data transport of an MLS’s RESO Web API service(s).

It is wise to review each data share participant’s RESO Analytics certification report to ensure that all of the fields that the data share participants need are included in the Web API service. A fully fueled API makes for a fully fueled data share.

RESO Analytics Alignment Reports

Matching a data provider’s entire data set to multiple other organizations is a significant task. For MLSs and others that have gone through the process of certification with RESO, there is a simpler way than comparing detailed certification reports.

MLSs can obtain alignment reports from RESO for multiple vendors and/or MLS organizations involved in a data share. MLSs will be able to quickly see which fields they have in common and which are different across marketplaces, providing critical decision-making information about potential additions to each MLS’s available fields in their API services, as well as which fields will be included in the data share.

Importantly, a field that is useful in one MLS may or may not be in another MLS. And a field that exists in two MLSs might be utilized, or have available data, at very different levels in each MLS.

But for any brokers using the service, including all of the fields that they might potentially need will make the service more efficient for a broader customer base. Not all participants need to use a field for it to still be valuable in the data share.

Provider Alignment Reports

Provider Alignment Reports allow one organization like an MLS to assess the alignment of its data across more than one API service. Roughly 30 percent of MLSs employ more than one API service, and they are often surprised to see how different their data is when it comes out of each API.

Provider Alignment Reports have both a visual representation of alignment for high-level presentations, as well as granular, detailed views of the full set of data elements in the systems.

Market Alignment Reports

Market Alignment Reports illustrate the level of alignment between multiple organizations. In this example, seven different MLSs with different sets of technology vendor API services can see how much of their data is aligned in those APIs.

Market Alignment Reports also offer a detailed view of all data elements across all organizations. These reports help data share participants analyze which of their API services will be the best to support their collaboration efforts.

Technology implementers analyze these detailed reports to assess which fields are common across organizations, which are highly utilized, which need to be altered to align with collaborators and which are critical to include in the data share service.

RESO Alignment Reports will soon be available to purchase, including significant discounts for RESO members. | LEARN MORE

Business Challenges for Data Shares

Costs of Maintaining Data Shares

Normalizing data sets for multiple MLSs and keeping them in sync over time carries costs. Technology vendors are hired to map the data sets, keep them in sync, maintain the data and support redistribution. Consistently monitoring and normalizing the MLS data set to the Data Dictionary improves outcomes.

Every technology vendor in the process will have its own fees. MLSs need to be in agreement on how fees associated with transporting and managing the data will be shared.

The challenges are not only technical. There are also business relationships to manage between MLSs and vendors. MLS staff time invested at the start of a data share is high. Ongoing costs must be planned for by the venture.

Varied Preparedness of Participants

MLSs that are not already offering a standardized API will need significant time and resources to become a reliable partner in a data share. Unstandardized data sets create an additional, time-consuming phase of an initiative, mapping all participants’ data before beginning integration work.

MLSs are dependent upon their software vendors to prepare for a data share. Vendors do not always have technical and time resources prioritized for this kind of work, creating a common bottleneck in the process.

When data sharing experiences become difficult and expensive, the likelihood of success decreases. Due diligence on all contributing resources and capabilities at the beginning of the process is warranted.

Geographic Coverage Objections

A frequent concern raised specifically about MLS data shares is that agents receiving access to MLS data outside of the geographies where they are best equipped to serve consumers might entice them to take on transactions in those markets. In practice, though, agents and their consumers already have access to nationwide listings through consumer-facing websites and apps.

The responsibility to provide proper agent representation falls on broker practices, state licensing regulations and REALTOR® Code of Ethics obligations. These geographic concerns can be a distraction for those seeking to share data.

Local, Legal and Language Differences

Different marketplaces employ MLS services differently based on the unique identity of the region. Local social practices, architectural features, naming conventions and other factors can differ between data share participants. Legal restrictions and capabilities may diverge across regulatory jurisdictions and licensing bodies. Multiple languages for data display might be available in one market but not another.

Whether across local municipality lines or international borders, data share planning must ensure that each participant can receive a data set that can be employed in a way that matches customer expectations. This may include employing RESO standards that support not only local fields but also international data sets and language translations.

Historical Perception

Data shares have become easier to implement in recent years, but their history includes some difficult failures. Those experiences can color industry opinions on the effectiveness of multi-organization data integration. While some data shares have worked well for many years, others have been shut down due to political and technical challenges.

It is important to acknowledge past failures with all stakeholders in the process, and to also highlight what has changed in the meantime. The first data shares did not include photos because the costs of hosting were too high. Today, the costs of underlying technologies, including services like cloud hosting, have greatly diminished.

Documentation about past challenges continues to grow and guide current data shares around well-understood roadblocks, improving the success rate of newer initiatives.

Normalizing Practices Across Organizations

The rules that MLSs employ around the use of their data, and how those rules are enforced, can greatly affect the success of a data share. Brokers and agents working in overlapping MLS marketplaces sometimes change which MLSs they join based on the way rules compliance is handled by those MLSs. This can incentivize a “race to the bottom,” as MLS operators call it. The organization with the least enforcement gets the most customers, creating problematic tension between MLSs.

Organizations should consider how many practices they can normalize, or make equal, between all participants.

Selection of the Data Set to Be Shared

Statuses of listings: Data share participants must decide whether to include active, pending and/or sold listings. The data share could include “coming soon” listings and those with special conditions, such as short sales. There are also specialized categories of listings that create requirements for data share participants to add new fields.

How far back will the data go? MLSs will have to decide how many years are available and/or required, including any differences between statuses.

Required fields for viability: Do any of the participating MLSs have multi-field dependencies that must be satisfied for the data share to comply with their processes? For example, to change a listing to a new status, it may be required to fill out an additional field regarding prices, dates or participants.

An MLS might have a CMA or statistics application that requires certain data fields to operate. Some systems may require full roster sets to connect listings with brokers and agents on the buy and sell side.

Redundant or unused fields: There may be fields in MLS data sets that are unused by the brokers in practice or provide no value to the data share. Mapping and transporting them may cause unnecessary work.

Defining Allowed Usage of Shared Data

Venue of data usage: Is the shared data allowed to be used only in MLS interfaces, or can it be included in analytics, reports, derivatives and/or public display?

Which kinds of listings and fields have additional restrictions? Can they only be displayed to customers or within the brokerage? Which parties are allowed to view restricted fields and listing statuses?

Specific field restrictions: If there are multiple uses authorized by the data share, do some fields need delineated uses, such as privacy restrictions?

Process for approving new uses: Is there a mechanism for data share participants to propose, vet and approve or deny a new use for the data that was not imagined in the original data share licenses?

Display requirements: Does the data share require data to be displayed with watermarks on photos, MLS source identification, or restrictions on visual elements like orientation or size of advertisements and disclosures?

Aligned calculations and tracking: Days on Market (DOM) and Cumulative Days on Market (CDOM) are notoriously inconsistent across the industry in calculation and display. The data share may need to select a single shared calculation for DOM and CDOM.

Traffic statistics can also be difficult to track across systems. The number of times a listing is viewed is valuable information for participants, but creating a system to combine the views a listing is receiving in each MLS system and aggregating those statistics presents significant challenges.

Access restrictions for users: MLSs and related associations have rule sets much broader than those of the data share. Do agents and brokers need to be in good membership standing within all of the MLSs in which they participate to maintain access to the data share? How will MLSs keep each other informed of roster status?

Timely action on issues: With the data set, rules and practices formalized, attention must be paid to service levels. The perfect framework can still fail if customers disapprove of its execution. MLSs involved in a data share should set expectations for expeditious service and compliance interactions with customers.

Technical Challenges for Data Shares

Challenges with implementing and maintaining the technology systems in a data share are documented here for management and nontechnical staff to discuss with technology staff and vendors.

Mapping Data Fields

MLS systems contain both RESO standard data fields and local data fields. Sometimes, custom fields in a local MLS system are identical to those in the standard, but they are named differently. For example, an MLS system in Hawaii may have a field called “Lanai,” which maps to the standard field called “Patio.”

The MLS has to make this mapping with its technology vendor so that the data goes out through the API service with the standard name. The local systems and reports can still display the label “Lanai” to local consumers. When data share partners receive the data, they should all receive the “Patio” data field.

MLSs have thousands of fields and pick lists that were created before standards were prevalent, so they all need to be analyzed to maximize mappings to the standard, increasing the value of the data share.

Other mapping challenges include:

• Property type and property subtype fields can be mapped differently in different MLSs, causing fragmentation upon integrating the data sets.
• Some MLSs may employ more granular fields like rooms and unit types, while others may not.
• Traditional implementations of the Real Estate Transaction Standard (RETS), an older deprecated standard, require significantly higher mapping time and technical resources.

Participants can create a simple spreadsheet mapping documentation, easily accessible by all parties so they can engage in the process and reduce conflict.

Once the analysis has been done to map to the standard, an MLS should ask its own organization: should these changes also be made to our own primary MLS platform?

Missing Listings or Fields After Combining MLS Data Sets

A common problem in data shares is that one or more of the participating MLSs does not receive all of the listings from the data share. This happens upon initial integrations of the data sets and throughout updates of the data during operation of the data share.

There are countless technical reasons for these failures, causing mismatched listing availability across the data share. The MLSs and vendors involved must constantly monitor the listings in their own systems, validate that they match with the full data share’s listings, and then find and rectify the listings that failed to transform into their own data set.

Getting access to the source MLS’s listing sheets and detailed reports can help a data consumer to assess whether all of the desired information is being delivered to data share participants.

Duplicate Listings

One of the biggest challenges in a data share is deduplication:

• A property listed in multiple MLSs with multiple disparate listing IDs
• A broker and agent listing that property with different MLS IDs on each listing
• A property listed for sale and for rent at the same time, with the same address

As described previously, implementing industry wide unique IDs for organizations, people and properties can greatly improve a data share’s ability to identify and deduplicate listings. This is critical for the user experience of the professionals and consumers who are viewing reports and displays of the data.

Tracking Changes in Data

When data in an MLS system changes, there should always be a record of it in a timestamp field, so participants know when they need to update their related systems.

Timestamps can signal that the whole listing record should be pulled again by the data consumer or be more specific. A media timestamp, for example, can identify that a photo has changed, signaling to the data consumer that only a photo needs to be updated rather than the whole listing, which would be more resource intensive.

In practice, some systems update portions of listings without updating the timestamp. This leaves data consumers without a signal to pull more recent data, leaving them to constantly check the entire data set to see if something changed.

Then, if there are changes, the data consumers have to go through a custom reconciliation to match the data in their system to the changed data in the source system.

This inefficient process is compounded when the large media files from every listing must be pulled as well, placing an onerous burden on data consumers.

One forward-looking solution that is beginning to be implemented is an event log (see EntityEvent Resource), which allows data consumers to view all changes in a system in order over time.

When changes come in large batches of bulk modification of records or metadata, participants should all have documented processes and preparation procedures to manage the changes consistently.

Accurate Days on Market

DOM and CDOM measures also have technical calculations meant to keep counts accurate. Document any inconsistencies in how these metrics are employed, how often they are calculated and how to identify when they were last calculated.

Syncing Up Broker Tour and Caravan Plans

Brokers often hold caravans, where many agents travel to an ordered tour of properties at the same time. These tours can be listed in the MLS.

When brokers in a data share want to set a caravan for listings in multiple MLSs, there is significant complexity in technically recording and displaying the tours accurately across systems.

System Availability

As with any technical venture, system uptime is critical. In MLSs, timeliness is a requirement for the businesses and consumers needing to sync when large financial transaction deadlines loom.

A data share adds another layer of complexity to the information stack that supplies services to the brokers and their customers. Ensuring that the MLS systems and the data share components have maximum uptime is important to customer perception of value.

Dealing with Idiosyncrasies in Systems

Each data implementation may have unique features that need to be incorporated into the plan. Identify and share these idiosyncrasies with all parties. Some examples include:

• Photos are sometimes duplicated in the Property Resource and the Media Resource
• Media and documents may be links or downloads
• Some systems have records with different numbers of columns
• Null and blank values are often implemented inconsistently
• Data and paging limits may restrict system design

Getting Started

MLSs considering data shares and integrations should review this guide with all parties before committing to an initiative. A full analysis should occur upfront for data assets and capabilities with technology vendors and customers. Identify integration partners, conduct due diligence, set important milestones and establish timelines with needed technology partners as first steps.

As with any technology change in the real estate industry, communicating the plan and the benefits to the customer base will be a critical step toward moving forward, especially if there are competitive vendors involved. Each vendor should be brought into the data share conversation early to find points of agreement on shared timelines.

There are many considerations for MLSs and their brokers contemplating technology integrations with diverse partner organizations. Taking the practices in this guide into account will greatly improve the likelihood of a data share’s success and longevity.

Acknowledgements

RESO is grateful to contributors who offered their feedback on data share experiences to improve this guide:

• Broker Public Portal
• Builders Update
• CoreLogic
• Council of Multiple Listing Services
• Doorify MLS
• FBS
• First MLS
• Heartland MLS
• Northern Kentucky MLS
• MLS Grid
• MLSListings
• National Association of REALTORS®
• NORCAL MLS Alliance
• Oregon Data Share
• Realtors Property Resource (RPR)
• San Francisco Association of REALTORS®
• Templates 4 Biz
• The Technology Collective
• T3 Sixty
• WAV Group