Brokers and agents need data on how advertising site visitors are interacting with listings, and there are a number of players in the real estate industry competing to provide this data. Each provider is tracking different things in different ways, and getting different advertising sites to implement their tracking mechanisms with little overlap. The way things have been going, I don’t believe that any of these competitors will “win” and achieve 100% adoption. That means brokers and agents are not going to win and be able to give sellers a complete view of what’s happening with the online marketing of their properties. Is there a solution to this problem?
What to Measure?
A long time ago, website owners just tracked “hits” to their website. Then, they got a bit more sophisticated, and started asking how many unique visitors there were. Then, at least in real estate, we started thinking from a business perspective and realized we needed to provide that type of information at the listing level, so it could be reported back to sellers. That was great, for its time. Now we’re at a point in most industries where e-commerce advertising effectiveness is tracked all the way from e-mail to website visit to sale, and expectations of what can or should be tracked in our industry are likewise evolving.
ListHub, for example, now tracks the following events where their tracking code is implemented:
- A property was displayed in a list of search results.
- Viewed the details of a single property.
- Sent an email to an agent.
- Sent an email to an office.
- Placed a phone call to the agent.
- Placed a phone call to the office.
- Clicked on the agent’s website of a listing.
- Clicked on the office’s website of a listing.
- Followed a listing or saved it to favorites.
- Clicked the virtual tour link of a property.
- Clicked to see more photos of a property.
- Clicked the video link for a property.
- Printed details on the listing.
- Clicked the property map.
- Clicked to get directions to a property.
- Shared a listing via social networks (which site specifically?) or email.
It looks like ListTrac is tracking many of the above items where their code is implemented, and is additionally tracking:
- Showing requests
- User registration information
There are lots of other folks tracking this type of information. In this post, I’m not going to try to be comprehensive about all of them and what they’re tracking.
Of course, we want to know where (on which website or app) and when each of these events took place. We may also want to know if it’s a professional view or a consumer view, or via a category such as MLS (back-end or prospecting/client collaboration), IDX, VOW, or advertising portal.
It’s also ideal to track who the consumer is, with as much specificity as possible. Consider everything Google tracks in its analytics – from demographics (age/gender), interests, language and geographic location, behavior (new vs. returning, frequency, engagement), technology (browsers, OS, etc.), mobile vs. desktop, and lots more. Note: when you have your reports designed, don’t let the geeks clutter things up with information useful to site designers and on the business end once in a while but not needed for regular reporting to agents and clients. Still, it’s good to collect this type of information, and agents would want even more if they could get it.
How to Measure?
There are many ways to collect all of this information, and the method of collection is driven by what we want to collect and where we want to collect it.The simplest way to collect some information would be by embedding a reference to a 1 pixel “invisible” (transparent) image with URL parameters that provide additional information. The image could be embedded in websites, emails, etc., and the server logs analyzed to create statistics. Unfortunately, most e-mail clients don’t download images by default, specifically to thwart this type of tracking. Also, browsers may cache the image, making this an unreliable form of tracking. Finally, while an image is good for tracking basic “hits,” technical limitations of this method mean that we can’t be as sophisticated as desired regarding “what” and “who” we track.The other way to collect information is to embed JavaScript code in the website, kind of like Google Analytics. There are a number of issues with this approach:
- It involves client-side code embedded in, or referenced from the page.
- The code and its interactions can affect page load and can slow down the user experience – especially if there are multiple tracking codes that have to be implemented.
- Referenced code can be / and has been changed by the third party controlling the code to collect undocumented information which may be inconsistent with the site’s expectations and what it communicates to users via its privacy policy. It can even hypothetically allow that party to interfere intentionally with the user experience (for example, generating a pop-up message). This lack of control may be unacceptable to site owners.
- Tools keep evolving for blocking front end / third party site tracking scripts and cookies.
- Advanced tracking involves making many additional changes to the website – not just an easy cut and paste of some JavaScript code. This, coupled with the need to currently implement various competing tracking codes (at least at the present time!), is completely untenable for website developers. This combination of issues, if nothing else, is currently the “nail in the coffin” of this approach.
- The pushback on this method has been significant, with quite a number of players indicating that this will happen over their dead bodies. Again, if we can’t figure out a method that works for everyone, this isn’t going to be successful other than as a fallback position for less technically capable local website developers.
I’ve heard one tracking company say that the third-party JavaScript approach is the only one that will work and that having code located on their own servers running client-side in the web browser allows them to verify there is no statistical manipulation from the publisher. I understand that argument, but find it very disrespectful of the publishers, especially since I’m not aware of any publishers “cheating” in a way that merits this kind of distrust. Many publishers do facilitate some “cheating” via view/click-fraud by not stopping “bots” – as has been discussed on this blog previously and which can’t be ignored for much longer – but that’s something the publishers have to deal with irrespective of tracking mechanism selected. The discussion must be had about how to address all of the other issues bullet-listed above if the third-party JavaScript method is even to be considered.
The alternative to the third-party JavaScript method is for sites to implement a RESO-standard API – both a “dictionary” and “transport” – for tracking, a standards effort that is currently in progress. Implementation might also include the creation of JavaScript libraries to collect some of the information and these types of libraries could be open sourced to facilitate adoption. Using a back-end API method would address most of the third-party JavaScript issues above and allow site developers to implement tracking using a single mechanism. It should also allow us to address at least the first of two critical, but, before now, unasked questions…
The Most Critical – But Unasked – Questions
The first critical question that must be asked is this: Who Gets the Measurement Data? There is an underlying assumption, the way tracking is mostly done today, that the party that collects the information is the party that gets to use it. I assert that such a tie can and should be broken. There’s no reason that tracking data, in a standard format, couldn’t be sent to a variety of report providers, encouraging competition and innovation in that space and allowing more of an opportunity for consolidated reporting regardless of the chosen platform.
Perhaps, just as brokers and agents today can decide where their listing information goes – IDX, specific publishers, etc. – they should also be able to decide what happens to the measurement data for the listing. For instance, brokers may want the data to just go to their back-end, where they have a great report for sellers that includes advertising effectiveness. Other brokers may want the data to go to their MLS, where there may be some basic reports available to agents. Still other brokers may want it to go to any number of companies that can provide unique reports (some possibly for a fee) to their agents. Finally, some may want it to go to many or all of the above. But, if one puts the brokers and/or agents in control over this data, and not every tracking report provider gets all of the data, what about reports showing traffic to a listing relative to “comparable” listings’ traffic? That wouldn’t be possible without all (or almost all) of the data. Maybe we would need to come up with something like broker reciprocity for this type of data.
Regardless, the point stands that there can be, and probably should be, various providers of reports, and simplifying collection of the data and providing a standard way of sending it to more than one provider is a worthwhile goal.
The second critical question that must be answered is this: “What Can They Do with the Measurement Data?” Website and app providers have – and must follow – privacy policies that they establish for the collection and use of user data. Putting website providers back in control of collection of data allows them to ensure that their policy is aligned with what they collect and share. But, once they share the data with report providers, who can say what those report providers can do with that data? Already, reports have surfaced of one report provider selling the data in unexpected ways. We must address this question before it imperils us. Perhaps one of my industry attorney friends will take up this question; it’s really more in their bailiwick then my own.
The Way Forward
As we answer the questions above, working on the technical, legal, and business issues surrounding the tracking of listing-related user activity, I anticipate new questions for debate. For example, consider all the issues surrounding tracking unique visitors between various websites and applications! Another intriguing possibility would be the creation of a RESO standard API for lead information, but I am getting ahead of myself.
First things first: if you have an interest in the issues above, I’d suggest getting involved in the Real Estate Standards Organization (RESO – http://reso.org), and if you want to be involved in the creation of standards for tracking, become actively involved in the work group. Alternatively, if you travel like I do and can’t make it to many meetings, write posts like this and bring them to the attention of those on the work group. Otherwise, there’s no complaining later!