Case study | Travel technology | Data and AI
Analytics a product team can actually trust
RoutePerfect helps travellers build their own trip itineraries. Like most digital products, it had plenty of analytics and not much certainty: three tools, three answers, and a lot of traffic that was never a person. We built the measurement layer underneath.
The problem: every tool gave a different answer
RoutePerfect wanted to know something simple: how many real people reach the trip planner, and where do they drop out. That question was surprisingly hard to answer. GA4, Microsoft Clarity, and session-recording tools each collect differently, so the numbers never reconciled, and every discussion turned into a debate about which tool to believe. Underneath that sat a bigger issue: a meaningful share of traffic to any travel site is automated, and conventional reporting counts a lot of it as people. Decisions were being made on numbers nobody fully trusted.
First-party data
Own the event stream
We moved the important events server-side into a data store RoutePerfect owns. When the app knows something happened, it records it, rather than hoping a browser tag survived an ad blocker, a consent banner, or a slow connection. Owning the raw event stream is what makes everything after it auditable: you can always go back and ask how a number was produced.
Bot filtering
Separate the humans from the machines
No single test identifies a bot, so we layered three signals: behavioural engagement (did the visitor do anything at all beyond arriving), IP intelligence (hosting, proxy, VPN, crawler and crawler-ASN classification), and timing irregularity, since automated traffic is usually too regular to be human. We built three cohort methodologies with different precision and recall trade-offs, then wrote down which question each one is honest for, including where each undercounts. A filtering method you cannot explain is just a different kind of guess.
Self-serve reporting
Reporting the team runs themselves
The analysis is only useful if the team can reach it without booking an analyst. We built a reporting tool into the product: overview, acquisition, events, and a multi-step funnel over the filtered cohort, plus a report builder where the team defines what they want, saves it, and reloads it later. Same underlying data, no spreadsheet round-trip, and every figure traceable to the events behind it.
How we implement AI and data systems
What owning the data caught
The clearest argument for this kind of work showed up in June 2026. RoutePerfect lets people enter the planner several ways, and one of them, selecting a ready-made popular itinerary, had never been included in the original list of planner events. It was a genuine planner entry that simply had not been flagged as one, so it had been invisible from the start.
On the day we identified it, that single missing event accounted for 8 of the 12 planner entries. Two thirds of the funnel step was uncounted, and every conclusion drawn from it had been quietly wrong. Once identified, it was added and the gap closed. That is the value of an auditable first-party layer: not that it always agrees with your other tools, but that when something does not add up, you can open it and find out why.
How we judge it
The measure here is not a traffic number. It is whether the team stopped arguing about which tool to believe and started making decisions from a figure they can trace. As with every client, we do not publish RoutePerfect's commercial performance data, and we would treat yours the same way. What is fair to say is that this is an ongoing engagement, and the reporting layer is in production and in daily use.
Frequently asked questions
What is RoutePerfect?
RoutePerfect is a travel technology company whose platform helps travellers build personalised trip itineraries, through a classic planner, an AI trip planner, and ready-made popular itineraries.
Why did they need a custom analytics layer at all?
Because their tools disagreed with each other. GA4, Microsoft Clarity, and session-recording tools each collect differently, so the same question returned different answers depending on where you asked. On top of that, a meaningful share of traffic to any travel site is automated, and standard reporting counts much of it as people. The team could not confidently say how many real humans reached the planner.
How do you separate real people from bots?
With layered signals rather than a single test: behavioural engagement (did the visitor do anything beyond starting a session), IP intelligence (hosting, proxy, VPN, crawler and crawler-ASN classification), and timing irregularity, using the coefficient of variation of gaps between events combined with a composite score. Automated traffic tends to be too regular. We built three methodologies with different precision and recall trade-offs, and documented which question each one is honest for.
What did you actually build?
A first-party server-side event pipeline into a data store the client owns, the cohort logic that separates real humans from mechanical traffic, and an in-app reporting tool: overview, acquisition, events, and a multi-step funnel, plus a self-serve report builder so the team can save and reload their own reports without waiting on anyone.
Will these numbers match GA4?
No, and that is expected rather than a fault. Different tools collect differently, so gaps are structural. The value of a first-party layer is not that it agrees with GA4, it is that you can see exactly how a number was produced and decide whether to trust it.
Not sure your numbers are real?
If your tools disagree, your funnel has gaps nobody can explain, or you suspect a chunk of your traffic was never a person, that is a solvable problem. It usually starts with owning the event stream.
