Pricing Tier: Free

L3 Identity Resolution Playbook — Generic Framework Edition

Background

Most organisations resolve customer identity overnight, in batch (L2). That is too late for anything that has to happen while the customer is still there — the anonymous session that would convert if the screen recognised them, the opt-out that must take effect before the next message goes out. Going real-time (L3) closes that gap, but not the way it’s usually imagined. It does not re-match or rebuild identity on the fly — that heavy work stays overnight. Instead it does event-to-profile stitching: when a live event arrives carrying an identifier, that identifier is looked up against the already-built profile index and the event is attached to the existing unified profile, in under 50 milliseconds. The real work — and what this playbook scopes — is deciding which use cases justify real-time, and making sure each event actually carries an identifier that can be looked up.

What Is This Workbook

This is a self-serve, platform-agnostic toolkit for taking customer identity from overnight batch (L2) to real-time (L3). It sets out the method: the two-plane model that separates the heavy identity-matching (which stays overnight) from the fast real-time lookup; the two filters that decide which use cases are worth doing in real time; and the engineering output — the data fields each use case needs on its event and the architecture to source them. Includes the methodology, worked examples, and a flow graphic.

Benefits

Corrects the costly misconception that real-time means resolving identity on the fly — the two-plane model that keeps you from building the wrong architecture.
Two filters that kill non-viable use cases before you build: value + real-time activation, then the deterministic-key check.
Produces a concrete engineering deliverable — the fields per use case, split into ready-to-stitch and must-be-sourced, with the sourcing architecture.
Keeps your proven L2 batch graph as the source of truth.

Who This Is For

Data architects, identity leads, and martech/marketing-ops owners who’ve deployed L2 (batch, multi-signal resolution) and want to act on identity in real time — in-session personalization, live suppression, on-connect servicing.

Customer Identity Resolution in Customer Data Platforms – Free Framework Guide

A plain-language framework that treats customer identity resolution as a staged capability — L1 exact-key matching, L2 multi-signal coverage, L3 real-time activation — with a diagnostic to find the stage you are actually in. Free, no email required.

First-Party Data Collection: Own Your Customer Data Before the Vendor Does (Data.C4 Toolkit)

Capture every event — and actually keep it.

Most CDPs will collect your data. Far fewer let you hold it — raw, complete, fast, and free of vendor tolls. The gap only shows up later: when a model needs the request headers that got stripped, when an attribution audit hits an hourly batch sync, or when a renewal quote reveals the raw export was a paid add-on all along.

The Data.C4 Toolkit gives you a structured, evidence-based framework to evaluate how well a packaged or composable CDP delivers first-party data collection — across custody, payload fidelity, warehouse latency, and cost of access. Use it to decide which architecture fits your requirements before you sign.

Who Is This For

Founders and CTOs at high-growth D2C, subscription, or commerce businesses choosing their first CDP
Marketing Ops and Data leaders who need raw event data for ML, attribution, and bespoke segmentation
Teams moving to a warehouse-centred stack and weighing packaged versus composable collection
Consultants and agencies advising mid-market clients on customer data ownership and lock-in

What Is Inside

Data.C4 Workbook (PDF) — a structured framework that walks you through:

The four dimensions that decide whether you own your collection layer: custody (leverage on exit), payload fidelity, latency to availability, and cost to access
How packaged CDPs (Segment, mParticle, Tealium) and composable stacks (Snowplow, Snowflake, dbt, Hightouch) handle each, with concrete vendor behaviours
The seven knowledge areas vendors won’t volunteer — schema standardisation, dropped headers, batch-vs-streaming reality, retention caps, and the cost model for raw access
Six configurable parameters that turn the generic capability into your requirements
An importance-weighting step so the score reflects your priorities, not a generic average
Six due-diligence questions with side-by-side packaged vs composable investigation paths
Binary, weighted scoring that produces a clear, defensible verdict — worked through a full sample scenario

How the Toolkit Works

The toolkit follows Datawhistl’s four-step framework, applied to first-party data collection.

Step 1 — Understand the capability. Sections 1–3 define what raw, complete, low-latency collection actually means, set out the four assessment dimensions, and arm you with the knowledge areas vendors rely on you not knowing. This removes the ambiguity sales conversations depend on.

Step 2 — Configure your requirements. Section 4 turns the capability into six parameters. You select a value for each — that’s what gets tested against the architecture.

Step 3 — Weight your requirements. Section 5 has you assign an importance percentage to each requirement, totalling 100%. This makes the scorecard reflect your business priorities, independent of how strict your selections are.

Step 4 — Run due diligence and score. Section 6 gives you six questions with documented investigation paths for each architecture. Section 7 applies binary, weighted scoring to produce a verdict you can take into a board meeting or a vendor negotiation.

Benefits and Outcomes

Prove who owns the data — confirm in writing whether raw history lives in your storage or the vendor’s, before the renewal leverage matters
Protect the signal your models need — surface dropped headers, truncated payloads, and property caps before they break attribution and ML
De-risk vendor selection — get written commitments on export rights, warehouse latency, and access fees instead of demo theatre
Avoid hidden tolls — expose raw-export add-ons, faster-sync surcharges, and retention caps early
Build stakeholder alignment — present a scored, requirement-backed recommendation, not a vendor pitch

How to Choose Between a Packaged CDP and Warehouse-Native Architecture — Free Evaluation Framework

Before You Buy Any CDP — Read This First

Before you sign a six-figure contract for a Customer Data Platform, you need to know which architecture actually fits your business. Packaged or Composable (Warehouse-native).

Every vendor has a story: Packaged CDP vendors will tell you their platform is the fastest path to a unified customer view. Warehouse-Native advocates will claim a composable approach is the only way to be flexible and future-proof.

Both are telling the truth for the right buyer, but neither can tell you if you are that buyer. This free guide provides a structured, capability-led framework to help you separate genuine architectural fit from a well-rehearsed pitch.Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

What This Guide Contains

The two realistic CDP architecture patterns (Packaged vs. Warehouse-Native)
Why starting with vendor selection is the #1 reason CDP projects fail
The Five Components of effective CDP Architecture Evaluation
A clear 4-step process for evaluating any capability
A complete worked example using a realistic Series A D2C brand (Glow&Co)
Step-by-step application across key capabilities:
- Cost Scalability
- Event-Driven Activation Latency
- Cross-Session Journey Stitching
- Self-Serve Segment Experimentation
- Data Lineage & Compliance
Final weighted scoring model with a clear winner
Full Capability Register (50+ capabilities across 5 layers)