Day thirty. The seller calls, and the question is the one it is always going to be: is anything actually happening. You have an answer. Whether it is worth anything depends entirely on whether you can say where it came from.
Most listing reports fail at exactly that point. They are a screenshot of somebody else's dashboard, or a handsome PDF whose figures cannot be traced back to an event that occurred. They survive one reading. The second month, when the number goes down, the seller starts asking what it measures, and there is no answer, because nobody chose what it measured in the first place.
A listing report is an accountability document. It is the record you put in front of somebody whose largest asset is sitting on the market while they pay to hold it. So the useful question is not which charts to draw. It is which events the software writes down, how precisely it writes them, and what it refuses to guess at.
Views, and the difference between a view and a visit
Views are kept as events, not as a counter. Listing pages, the property site on its own subdomain, and the marketplace all record the same shape: which page was seen, which subdomain served it, the source, medium and campaign that brought the visitor, a session identifier, and a hash of the address. The raw address is never stored, and on the listing tracker the last block of an IPv4 address is zeroed before anything is written at all.
Because the session identifier is kept, total views and unique visitors are two different numbers rather than one number described two ways. Because the source and medium are kept, the traffic from the postcard's QR code is separable from the social post, from the email campaign, and from people who typed the address in. Views that arrive through a listing game are tagged with their own medium, so a burst of game traffic can never be quietly presented as organic interest.
Crawlers are excluded. A property site with a public subdomain is crawled continuously, and a report that counts crawlers is not a report. Automated traffic is flagged at write time by user-agent and dropped from the nightly rollup that produces the daily view count and unique-visitor count. Prewarm requests, which the caching layer issues against the page itself, carry a header that stops them being recorded at all.
The per-resource view detail, broken down by day, by source and by medium, is on the metrics dashboard.
Saves are a smaller number and a better one
A save is one row per signed-in user per listing, unique on that pair, with a running count kept on the listing so it can be read without counting rows. It will always be a fraction of the view count and it is worth more, because it costs an account to leave one. Say so in the report rather than burying it: a hundred views and four saves is a legible sentence about the pricing, and it is a better conversation than a bare traffic figure.
It also has an honest limit. Nobody can save a listing anonymously, so the number describes signed-in interest, not everyone who liked the house.
Showings, and the feedback that usually evaporates
A showing is a record, not a memory. It carries a status of scheduled, completed, cancelled or no-show, the time it was arranged and the time it happened, a rating from one to five, a structured set of what the buyer liked and disliked, the agent's own notes, and a marker for whether that feedback was typed in, dictated, or lifted out of the conversation by the model afterwards.
This is normally the part of a seller update that arrives as hearsay a fortnight late. Held as records with dates on them, four showings and three separate remarks about the driveway is not an anecdote, it is a finding, and the seller can act on it. The same records feed the buyer's own preference profile, so the feedback does two jobs.
The open house, counted at the door
Registered and attended are stored as different things: an attendee row has a registration, and separately a check-in time and the person who checked them in. Walk-ins record who added them. QR scans keep their own row with the time, the device and the scan location, so the door count is evidence rather than an estimate made in the car afterwards.
Afterwards the survey asks the question the report needs: overall experience out of five, whether they are interested in this property, and which next step they would pick, from booking a viewing, to making an offer, to needing more information, to not interested. A seller update that can say eleven registered, nine came, and two selected make an offer is doing work that no traffic chart can do.
What you did, logged while you were doing it
The other half of a listing report is not about the property at all. It is about the agent. Calls, email in both directions, texts including the ones the answering agent handled on your behalf, in-app chats, showings, open-house responses, gifts, referrals, meeting bookings, webinar registrations and signature requests are all written to one activity timeline as they happen, each stamped with its direction and a key that stops the same event being counted twice.
That matters because the activity column of a seller update is the one agents reconstruct from memory at eleven at night, and reconstruction is where reports quietly become fiction. If the log writes itself, the month's work is already there, and it is there in the order it happened.
The status history cannot be edited. Every market-status transition on a listing is recorded with its previous value, its new value, the person who made it and the time. The model that holds those rows throws on update, on delete and on force delete: the trail is immutable by construction, not by policy. When a seller asks when exactly the listing went from active to under contract and back, that is a fact, not a recollection.
Market movement, and whose numbers those are
Context comes from licensed market datasets held at ZIP, city and county grain: median sale price and median list price, price per square foot, change year on year and month on month, days on market, months of supply, sale-to-list ratio, the share of homes selling above list, the share taking a price drop, inventory, new listings and homes sold. Two years of history sit behind each area, which is what lets a report show a direction rather than a snapshot.
Those figures also drive a sell signal, scored from zero to one hundred for an area and published openly, so a seller can read the market read for their own ZIP without taking your word for it. Start at the Seller's Guide and look up the postcode. Where a listing needs property-level depth, comparables, tax records, sales history and a valuation, a United States deep-data search covers more than 160 million properties and costs 175 credits for that property.
These are third-party datasets and the page says so. They are attributed, not passed off as something OpenLuxe measured.
A figure a seller cannot trace is a figure they will not believe the second time you show it to them.
The lines we do not draw
The absences are part of the specification, so they are printed here rather than left to be discovered.
No time on page, no scroll depth, no heat map. Nothing in the platform records how long a visitor lingered or how far they scrolled, so no report will ever put a number on it. Products that quote you an average dwell time on a listing page are usually quoting a model, not a measurement.
No first-party price history. Status transitions are recorded; a separate price-change ledger on your own listing is not. Price history that appears against a United States property record comes from the data provider, and it is labelled as such.
Nothing is sent to your seller behind you. Scheduled and autonomous sessions draft outward messages into an approval queue and wait for a person; the nurture view surfaces that a contact is due, computed from the last logged touchpoint, and then stops. A report about accountability that mails itself out unread would be a strange thing to build.
OpenLuxe is not an MLS. It provides no MLS or IDX access and syndicates nothing to third-party portals. What it measures is your own property site, your own marketplace listing and your own activity, which is the part you are accountable for.
Assembling one
There is no button that prints a seller report, and this page is not going to imply there is. What there is, is every figure such a report should contain, already recorded, already attributable, and reachable in one place each: the view detail by day and source on the metrics dashboard, the saves count on the listing, the showing records with their ratings and their notes, the open-house register with its check-ins and survey answers, the contact timeline for everything you did, and the market read for the postcode.
Put those in front of a seller in that order and the conversation changes shape. It stops being a defence of the last thirty days and becomes a decision about the next thirty, taken from the same evidence by both people in the room.
The schedule
For reference, the record behind each figure and the claim it will support.
- Views
- One row per page view, carrying the page, the subdomain it arrived on, the source, medium and campaign that brought it, a session identifier and a hashed address. Total views and unique sessions are separate figures.
- Crawler traffic
- Flagged at write time by user-agent and excluded from the nightly rollup, so a public property subdomain being crawled around the clock does not inflate a seller update.
- Saves
- One row per signed-in user per listing, with a running count on the listing itself. Lower volume than views and higher intent, because a save costs an account.
- Showings
- Scheduled, completed, cancelled or no-show, with the time it was set and the time it happened, a one-to-five rating, structured likes and dislikes, and a note on whether the feedback was typed, spoken or extracted from the conversation.
- Open house
- Registration and check-in are separate columns, walk-ins record who added them, and QR scans keep the time, the device and the scan location. The post-event survey asks the next step outright.
- Your activity
- Calls, email in both directions, texts including the ones the answering agent handled, chats, showings, open-house responses, referrals, meetings, signature requests and more, written to the contact timeline as they happen.
- Status changes
- Every market-status transition on a listing, with the previous value, the new one, who made it and when. The model refuses updates and deletes, so the trail cannot be tidied up afterwards.
- Market movement
- Licensed ZIP, city and county datasets: median sale price, price per square foot, year-on-year and month-on-month change, days on market, months of supply, sale-to-list ratio and inventory, with two years of history.
Open the metrics dashboardRead a market signal by ZIPSee the activity timelineCreate an account
Recording views, saves, showings, open-house check-ins, surveys, touchpoints and status changes costs nothing: they are written as the events occur, on every listing, with no plan to be on. Credits are the platform's unit of payment, one credit is one cent, bought when you need them. A United States deep-data property search is 175 credits.
OpenLuxe is not an MLS and provides no MLS or IDX access. Market trend data is licensed from third-party providers and attributed to them. Nothing on this page is a performance guarantee; it is a description of what the software records.
