How do you instrument a revenue event that lands long after the click?

The problem is not delay alone

A contingency practice does not realise revenue when a case is signed. It realises revenue when a matter resolves, costs and liens are settled, and funds move from trust to operating. Between the click that produced the enquiry and that transfer sit an intake CRM record, a conflict check, a matter record in a case management system, a cost ledger, a lien file and a disbursement statement. Each is a different object, in a different system, under a different identifier. The delay is real, but the delay is not what breaks measurement — the record boundaries are. The instinct is to shorten the feedback loop by counting something earlier: a booked consultation, a signed retainer. Those are legitimate events, but none of them is the fee, and the relationship between them and the fee is set by facts the acquisition layer never sees — coverage posture, liability, venue, injury severity. The stage-by-stage layout of that path is set out on the personal injury law hub.

What each system can actually observe

Read down the last column and the shape of the problem becomes explicit. Every stage has an identifier of some kind. The one stage that produces money — the transfer out of trust into operating, against a specific matter — is the stage with no acquisition field on the record at all. Attribution here is not a reporting configuration; it is an identifier that has to survive every handoff between the two ends of the path.

Why the reported conversion is not a fee

There is a second, independent reason not to read reported conversions as a revenue signal. Google's tag documentation states that when users deny consent for storage, consent-aware tags do not store cookies or device identifiers, and that instead tags communicate consent state and user activity by sending measurements without cookies; Google products then use these pings to model your metrics ^[SRC-18]. A reported conversion total is therefore a mixture of directly observed records and estimated ones, and that mixture is not separable at the level of an individual row. It remains a usable directional signal. It is not a count of things that happened, and it cannot be audited from outside the platform.

The browser layer underneath it is also not settling into a stable shape. Google's Privacy Sandbox update states that Chrome will maintain its current approach to offering users third-party cookie choice, and that a set of proposals — including the Attribution Reporting API, Protected Audience and Topics — is being retired, while CHIPS, FedCM and Private State Tokens continue ^[SRC-16]. The operational reading is not that measurement is impossible. It is that browser-side attribution machinery is a poor foundation for a fee-attribution model, so the join has to be owned by systems the firm itself controls.

Reconstructing the path backwards

1. Give the enquiry a durable identifier at capture — a click identifier plus a first-party record id written to the intake CRM at the moment the form or the call creates the lead object.
2. Carry that identifier onto the matter record when the case management system opens the matter, as a mapped field rather than a value a person retypes.
3. Post advanced costs against the matter identifier, not only into the accounting package, so cost recovery and fee are readable from one object.
4. Record referred-out matters as objects with a counterparty, an expected fee and a status, so the fee line that never becomes a matter still has a record that can age.
5. Stamp the disbursement statement and the trust-to-operating transfer with the same matter identifier, so the realised fee joins to the identifier that started at the click.
6. Reconcile on a fixed cadence: click and lead exports against intake CRM records, intake records against opened matters, opened matters against realised fees.

Once that chain exists, offline conversion import becomes a choice rather than a capability question: the signature event, the realised-fee event, or both can be sent back, because the identifier survived. Where the chain does not exist, importing anything is guessing with extra steps. The build this depends on belongs to the tracking and measurement family of the capability architecture — see Tracking, Attribution and Measurement Systems.

The follow-up half carries a consent dependency

One constraint belongs here because it shapes the build rather than the reporting. Re-contacting intake records that did not sign is a follow-up problem, and automated calls and texts are constrained by federal telemarketing rules at 47 CFR 64.1200. Those rules require prior express written consent for autodialed or prerecorded telemarketing calls and texts, allow a consumer to revoke by using any reasonable method to clearly express a desire not to receive further calls or text messages, and require that revocation be honoured within a reasonable time not to exceed ten business days ^[SRC-14]. The architectural consequence is that a consent artefact — value, timestamp, capture source — belongs on the intake record from the moment of capture, not as a retrofit assembled before a reactivation campaign.

What the reconstruction still cannot settle

• It cannot separate a modelled record from an observed one at the row level, so the platform-side total stays an estimate even after the firm-side chain is clean.
• It cannot establish causation. A matter carrying a campaign identifier was tagged with that campaign at capture; last-touch overwrites, shared devices and stale identifiers all mean the tag is not proof that the campaign reached the client, and reaching the client is not proof that it is why the client signed.
• It cannot value enquiries that never arrived, so it says nothing about what a differently structured campaign would have reached.
• It cannot read case merit. Realised fee is a function of coverage, liability and venue, and a clean identifier chain does not make those facts visible any earlier.
• It cannot replace internal verification: every join described here needs access to the intake CRM, the case management system and the fee ledger. A Revenue Scan documents what is visible from the public surface and names where internal access would be required.