How HouseFacts built a data system it can act on

A home is the most valuable thing most people will ever own. It's also the worst-documented. The receipts are in a drawer. The contractor's invoice is somewhere in your email. The warranty you'll remember the day after it would have helped. What maintenance has actually been done lives in one person's head, a half-kept spreadsheet, or nowhere.

None of it feels like a problem, until you sell, file an insurance claim, do your taxes, take on a second property, or help an ageing parent with theirs. That's when the missing context gets expensive.

HouseFacts starts from the insight that homeowners don't need another place to put files, they need a system of record for the home itself.

A system that stays true from purchase to sale.

From individual spreadsheets, emails, and photos to an easy-to-use home management platform

It's a system of record for your house. You forward anything home-related to a custom email address — bills, invoices, contractor estimates — and it sorts everything automatically with AI: expenses, vendors, warranties, what got done and when.

So instead of that information sitting in your inbox and a drawer, the house keeps one organised record of itself.

The useful part is what you get out of it later. It builds a maintenance history with proof of who did what, which is what you actually need when you sell or file an insurance claim, and it tracks expenses against the cost basis for taxes. There's the usual calendar and checklists for upkeep on top, but the core is just that the house has a memory now, and it isn't in your head or scattered across devices.

Setting up HouseFacts' data infrastructure

Data privacy is really important for HouseFacts, given what people share with the platform. So we started with the part everything downstream depends on: collection and consent. There's no point optimising ad spend or building reports on numbers that are wrong at the source. So the first job was capturing every visit and signup once, with the visitor's consent state attached before anything is sent.

Then we connected the data destinations that "activate" the data: GA4 for reporting, Meta and Google Ads for conversions, the CRM for follow-up. We confirmed the most important conversions (signups and paid subscriptions) on the backend, not in the browser. Browser pixels are unreliable: an ad blocker can block them, and a missing consent can drop them. A server event is not exposed to either problem.

We then extended this across the full funnel, from the first ad click, to signup, to using the product itself.

We also connected the CRM (ActiveCampaign), so each new contact keeps the campaign they came from and enters the right follow-up, not the same generic welcome for everyone. Everything runs on one shared set of event definitions, instead of a separate tracking setup for each tool.

The result is a system HouseFacts can act on: Meta and Google bid on signups that actually happened and aren't counted twice, the follow-up someone gets matches how they came in, and when anyone asks which campaign produced a paying customer there's one answer instead of an argument over which dashboard to trust.

A few principles guided the data system build:

• Consent first. A tool receives data only if the visitor allowed it, and consent is not bolted onto the reports afterwards.
• Confirm what matters on the backend. The conversions that decide budget are confirmed by the server, not by a browser pixel that can be blocked or dropped.
• Collect first-party. Instead of a dozen vendor scripts loading in the browser, the website sends to one first-party layer HouseFacts owns. It is harder for an ad blocker to break, and easier to govern.