Most organisations own two versions of their customer journey. The first is drawn on a wall. It has boxes for awareness, application, interview and placement, arrows that travel in one direction, and a general belief in the room that this is roughly what happens. The second is scattered across systems nobody ever filed under customer data, it has no arrows, and it is the only version with evidence behind it.
A global staffing and HR services group went looking for the second one. Inside a short data-innovation engagement, one of the cases it selected combined four heterogeneous web sources into a single purpose-built backend. The span was stated plainly: registration through to placement, read from the candidate's point of view rather than from the website's. Two of those four sources were internal platform systems. The third was a web analytics feed. The fourth was the load balancer logs from the web estate, and that fourth one is the reason this case is worth writing up.
The challenge
The work that came before it was a contact-point mapping exercise, and the group was unusually clear about what it wanted out of it. Not the dozen touchpoints everyone already argues about, but every point of contact that could form part of a journey, written down. The moments where a person passes between marketing, sales and service, identified as objects in their own right rather than left as the white space between two boxes. And the ways those points of contact rely on each other, visible without having to be traced by hand.
The whole exercise was then run twice, because a staffing marketplace has two populations moving through it and they do not share a journey. Clients hire. Candidates get hired. The same web page sits in both maps and means something different in each.
Naming handovers and dependencies as first-class outputs is the part most journey work skips, and it is the right instinct. Journeys rarely fail at a touchpoint. They fail in the gap between two of them, where a form has been submitted and a system has accepted it and nobody has yet been made responsible for what happens next. A touchpoint map with no handovers on it reads as a smooth path because it has quietly deleted every place the path can break.
What a mapping exercise cannot do is tell you which of those breaks actually happen, or how often, or to whom. It produces a hypothesis with a lot of boxes on it. Turning that into something you can act on means measuring the real traffic, and this is where the honest difficulty starts.
A candidate lifecycle from registration to placement is not a session. It runs across weeks, sometimes months, over several devices, through a registration flow, a search, a set of applications, a screening conversation and a placement, and those stages live in different systems that were never asked to agree on who a person is. Standard web analytics is built for a different question. It answers what happened on the site well, and it answers what happened to this candidate badly, because its unit is the visit and the unit the business cares about is the person.
The approach
So the unit was changed. The backend was built candidate-centric, and the sources were fused rather than compared. Two purposes were stated for it: deliver end-to-end insight and measures across the registration-to-placement span from the candidate's perspective, and deliver a view of candidate browsing behaviour, the flows and the bottlenecks, on the group's own websites in order to raise conversion.
Three of the four sources are the ones anyone would have listed. Internal platform systems know what the business recorded. Analytics knows what the tagging plan chose to report. The load balancer log is a different kind of witness. It was not created to describe customers. It exists so that traffic reaches a server and someone can work out what went wrong at three in the morning. It records what was asked for, what was returned, and how long it took, for every request the estate served, including the requests that failed before anything downstream noticed and the ones that no tag was ever fitted to.
The source lists that fourth input without arguing for it. The argument is worth making explicitly, because it generalises past this engagement. Analytics data is curated by construction, which means it is shaped by the assumptions of whoever specified it, and those assumptions are usually optimistic about the parts of the journey they own. Infrastructure telemetry is complete by construction and meaningless by default. It sees everything and understands none of it. If your instrumented view and your infrastructure view disagree about how many people started a registration, the infrastructure view is not the one that is wrong.
The cost of that completeness is real work, and it is not modelling work. It is joining records that were never designed to be joined, deciding what counts as one person across systems with different notions of identity, reconstructing a sequence of intent out of paths and status codes, and keeping a lineage trail so that every measure the business ends up quoting can be traced back to the source that produced it. Data readiness is the entire job here, which is why a RealAI Consult scope for a journey brief prices the joining and the identity work as the deliverable rather than as setup. The analysis that follows is comparatively easy.
There is a second reason to build the fused view rather than a report. A candidate-centric event history is the same asset a model needs later, at training time and at serving time, which is why teams who start with a journey question end up with a feature store. Process mining over that history gives you the drop-off measurement with a source attached, refreshed as often as anyone wants it rather than redone by hand each quarter. And a model that scores or routes a candidate can only be deployed responsibly if the features it saw and the decision it made are written somewhere an auditor can follow. The Platform work we do starts at exactly this layer, because a journey view, a feature store and a lineage trail turn out to be three names for one piece of engineering.
The outcome
Being straight about what the source supports: it records the design and the intent, not a result. Four sources, one backend, a named span and two named deliverables. No conversion number is stated for this case, and none is invented here. Sibling cases in the same engagement do carry stated outcomes, and the engagement itself ran on a hard clock, from problem framing to something deployed inside six weeks. This case carries a specification.
That is still the part worth taking. The transferable decision was made before any analysis: refuse to accept the instrumented view as the truth, and go down to the layer that has no opinion. Every organisation running a funnel has this option available and almost none of them use it, because the logs sit with infrastructure, the journey sits with marketing, and nobody owns the join.
Three lessons hold up. The unit of analysis decides the value of everything downstream, and moving it from the session to the person is a data engineering commitment rather than a reporting preference. The sources with the least commercial framing are often the most honest, precisely because nobody optimised how they look. And the two populations in a two-sided business need two journeys, because averaging them produces a picture that describes neither.