Completions

For customer-data engineering + retention leadership

Customer LTV per location, per channel, per brand — at runtime

Not in a quarterly spreadsheet. Not in a nightly batch. Event-driven recompute on every transaction, with a four-stage customer-graph pipeline (Ingest, Resolve, Version, Compute) feeding it.

By Jay Christopher11 min read

What this gets you

  • Per-location × per-channel × per-brand CLV at the customer-record level — a three-dimensional figure, not a single brand-level number.
  • Runtime event-driven recompute — every transaction, every behavior signal, every identity-resolution change triggers an immediate CLV update. No nightly window.
  • Four-stage customer-graph pipeline — behavior signal ingestion, deterministic plus probabilistic identity resolution, versioned customer history, and the CLV compute stage.
  • Canonical CLV math primitives — NPV, discount rate, retention curve (BG/NBD, Cox, Kaplan-Meier), margin-versus-revenue toggle, all configurable per business model.
  • GDPR + CCPA + DSAR compliance — versioned customer history provides the audit trail; data-subject requests trigger export, delete, and audit-log capture without breaking the analytical aggregates.

One brand-level CLV number averages every signal worth having

Customer data platforms ship CLV as a feature. The output is one number per customer at the brand level. For a single-store DTC brand this is the right shape. For a 200-location operator with three banners, six acquisition channels, and four customer segments, it is an average of signals worth keeping separate.

Per-location CLV surfaces which markets are training the highest-quality customer base. Per-channel CLV surfaces which acquisition path is worth bidding higher on. Per-brand CLV at multi-banner operators reveals which banner is compounding LTV faster than the others. The three-dimensional record — per location, per channel, per brand — is the unit of decision the marketing, retention, and FP&A teams actually need to operate from.

The compute model also has to change. Single-tenant CDP CLV runs nightly or weekly against the historical record. A 200-location operator with 100,000+ customers and millions of monthly behavior events either misses the recompute window or produces figures that are stale by the time downstream systems read them. Runtime event-driven recompute updates CLV on every transaction — paid-acquisition bidding, retention investment, and loyalty-tier decisions all consume the current figure, not yesterday’s.

The infrastructure is a four-stage pipeline. Behavior signals ingest from every channel. Identity resolution stitches records deterministically and probabilistically into the canonical customer graph. Versioned history captures the audit trail for DSAR and analytical reproducibility. The compute stage runs the CLV math primitives over the resolved record and produces the three-dimensional figure.

What is in market — and what each category leaves to you

The CDP and the customer-analytics layers are mature. The per-location plus per-channel plus per-brand decomposition and the runtime event-driven recompute architecture are operator-side wiring.

Enterprise CDPs — Segment, mParticle, Tealium, Treasure Data, BlueConic

Mature on event ingestion, identity resolution, and audience segmentation. CLV features compute a brand-level number per customer. Per-location and per-channel decomposition is operator-built on top.

Customer-data platforms — Amperity, ActionIQ, Lytics, Bloomreach, Hightouch

Strong on identity resolution at scale and on cross-channel reconciliation. CLV is shipped as a feature; the multi-banner three-dimensional record and the runtime recompute model are operator-side.

Customer analytics — Mixpanel, Amplitude, Heap, Pendo, Fullstory

Excellent at event-level behavioral analysis. Not designed to produce CLV figures or to feed downstream decisioning at runtime. Complementary to the customer-graph pipeline; not a replacement.

Retention and churn modeling — Custify, ChurnZero, Gainsight, Totango

Strong on the retention-prediction side. Useful as signal sources for the CLV compute stage; not a replacement for the four-stage pipeline.

Open-source CLV — Lifetimes (Python), BTYDplus (R), Brachmann + Plus academic implementations

Mature implementations of the CLV math primitives — BG/NBD, gamma-gamma margin modeling, Kaplan-Meier survival curves. The math is solved; the per-location scoping and runtime wiring is the work.

The pipeline, end to end

  1. Behavior signal ingestion. Every channel — paid media, GBP, POS, email, SMS, app, web, call analytics, review surface — feeds canonical behavior events into the customer graph. Per-event timestamping and source attribution preserved.
  2. Identity resolution. Deterministic matches (email, phone, hashed identifier) plus probabilistic matches (device, geography, behavior fingerprint) resolve disparate records into one canonical customer. Confidence intervals attached.
  3. Versioned customer history. Every state change captured as a point-in-time snapshot. Audit trail for DSAR. Replayable for analytical reproducibility.
  4. CLV math primitives. Net present value of projected future cashflow, discount rate configurable per operator cost of capital, margin-versus-revenue toggle, per-transaction margin extraction.
  5. Retention curve fitting. BG/NBD for transactional businesses (one-off purchases or repeat-but-not-subscription), Cox proportional hazards for subscription, Kaplan-Meier as a non-parametric baseline. Model per business segment, not per brand.
  6. Per-channel CLV decomposition. Each customer carries a CLV figure attributed to the acquisition channel, the engagement channels, and the retention channels. The decomposition is a function of the attribution model (first-touch, last-touch, multi-touch, algorithmic).
  7. Per-location CLV rollup. Customer-level CLV figures aggregate to location-level cohort CLV. Locations comparable on like-for-like cohorts (new customers, returning customers, lapsed reactivations).
  8. Per-brand CLV reconciliation. Multi-banner operators carry per-brand CLV records. Customers active across multiple banners get a brand- attributed share. Conflicts resolved by primary-brand rule.
  9. Runtime event-driven recompute. Every transaction or behavior event triggers an incremental CLV update for the affected customer. No nightly batch. The compute graph is event-driven and idempotent.
  10. Cold-start handling for new openings. Customers in their first 0-90 days at a new location have no individual CLV history. Cohort priors from comparable openings provide the baseline until the customer accumulates enough history for an individual fit.
  11. DSAR compliance.Data Subject Access Request triggers an export of the customer’s CLV record at the requested point in time, a cascading delete through the customer-graph, and an audit-log capture. Point-in-time snapshots persist for analytical aggregates.
  12. Per-franchisee accountability rollup. Per-franchisee CLV delta against the peer cohort surfaces in operator dashboards. Accountability metric independent of raw revenue, anchored on customer quality.
  13. Model accuracy measurement. Hold-out test sets compare predicted CLV against actual revenue at 12, 24, and 36 months. Per-model precision-recall and MAE metrics surface drift before it reaches downstream consumers.

Frequently asked

What is customer lifetime value software?

Customer lifetime value (CLV or LTV) software computes the projected revenue and margin a customer will produce over the lifetime of the relationship. Inputs include past transaction history, behavior signals, identity-resolved records, and a retention model. Output is a CLV figure used for retention investment, paid-acquisition bidding, loyalty-program tiering, and executive forecasting. Enterprise CDPs (Segment, mParticle, Tealium, Treasure Data, Amperity, ActionIQ) ship CLV as a feature; the per-location and per-channel decomposition is operator-side wiring.

Why decompose CLV per location and per channel?

A single brand-level CLV figure averages across locations and channels and tells you nothing about which location is producing high-LTV customers or which acquisition channel is producing high-LTV traffic. Per-location CLV surfaces which markets are training the highest-quality customer base. Per-channel CLV reveals which acquisition path is worth bidding higher on. Per-brand CLV (at multi-banner operators) shows which banner is compounding LTV faster than the others.

What does CLV at runtime mean?

Runtime CLV means every transaction, every behavior event, and every identity-resolution change triggers an immediate CLV recompute for the affected customer. The alternative is batch CLV — nightly or weekly recompute against the historical record. Batch works at small scale. At a 200-location operator with 100k+ customers and millions of monthly events, nightly recompute either misses the window or produces stale figures by the time downstream systems consume them. Runtime CLV is event-driven and incremental.

How is this different from Segment, mParticle, Tealium, Amperity, or ActionIQ?

Those CDPs are mature on data ingestion, identity resolution, and audience segmentation. Their CLV features compute a brand-level number per customer. The per-location and per-channel decomposition, the per-brand decomposition for multi-banner operators, the four-stage customer-graph pipeline (Ingest, Resolve, Version, Compute), the per-franchisee accountability rollup, and the runtime event-driven recompute architecture are operator-side wiring above whichever CDP you license.

What CLV math primitives are involved?

Net present value (NPV) of projected future cashflow per customer, a discount rate that reflects the operator’s cost of capital, a retention curve fit from historical data (BG/NBD for transactional businesses, Cox proportional hazards or Kaplan-Meier for subscription, Lifetimes library implementations for both), per-transaction margin extraction, and a margin-versus-revenue toggle that lets the figure surface either gross or contribution. The primitives are stable; the per-location and per-channel scoping is the operator-side work.

How does this handle GDPR, CCPA, and DSAR requests?

Versioned customer history (the third stage of the four-stage pipeline) carries the audit trail of every behavior event, identity resolution, and CLV recompute. A Data Subject Access Request triggers a CLV-record export at the requested point in time, a delete cascades through the customer-graph, and the audit log captures the request, the response, and the regulatory citation. CLV figures persist as point-in-time snapshots before deletion so analytical aggregates do not break.

Hire the agent that runs the customer graph

The customer-data-graph agent owns the four-stage pipeline (Ingest, Resolve, Version, Compute) and the runtime event-driven CLV recompute that feeds retention investment, paid-acquisition bidding, loyalty tiering, and executive forecasting downstream.

Hire the customer-data-graph agent

We scope on the call and send a private checkout link after.

Related reading: Cohort-framed KPI rollup · Save-flow propensity scoring