Resolve several people at one address into a household where the buying unit is the household, without letting one member's data quietly drive another's experience
For some businesses the unit of value is not the individual but the household: a family streaming subscription, a shared account, a product bought once and used by several people at an address. Treating each person as a separate customer in these contexts misreads the relationship entirely, splitting one buying decision across several records, fragmenting the view of value, and producing recommendations that satisfy nobody because they average across people with different tastes.
Resolving to the household is genuinely useful here and genuinely sensitive. The same stitching that lets a streaming service understand a family also, done carelessly, lets one member's behavior drive another's experience, which ranges from awkward (a teenager's viewing shaping a parent's recommendations) to a real privacy harm (one member's activity, perhaps something private, surfacing where another member sees it). The recipe is high readiness because the value is real but the privacy design and the merge-split correctness are demanding, and getting either wrong is worse than not stitching at all.
This recipe resolves individuals to a household where that is the right unit, with the data-handling rules that keep it from harming the people inside it.
A household resolution that reflects the real buying unit, used where the household is the right unit and bounded where the individual is. The metric is household resolution accuracy: correctly grouping the people who belong together without false households that merge unrelated people sharing an address or an IP. The value shows up in subscription and shared-account contexts as a coherent view of the household and as recommendations that account for the shared nature; the honest framing is that household resolution is the right tool for a specific set of businesses and the wrong tool for most, and applying it where the individual is the real unit creates the lowest-common-denominator personalization the recipe warns about.
The second outcome is a defensible boundary: clear rules about what household-level resolution may drive and what must stay individual, so the stitching does not become a privacy incident.
A CDP or identity layer that maintains both individual and household resolution and exposes which level applies to a given decision. Composable stacks suit this because the household graph and the individual-versus-household boundary need to be inspectable and governed. The capability that decides whether it is safe is merge-and-split correctness: households change (people move in and out), and a graph that can only merge accumulates stale households that group people who no longer belong together, so clean splitting is as important as accurate merging.
Compare the tools on Martech Stack Builder
Identity or CDP ownership owns the household definition, the merge and split rules, and the boundary of what resolves to household versus stays individual. Legal is critical, because the basis for resolving individuals to a household, the rules for cross-member data use, and the disclosure that requires are real GDPR-strict questions, and household resolution is exactly the kind of processing a regulator scrutinizes. Data engineering builds the household graph, the merge-split handling, and the resolution service. Analytics audits resolution accuracy and hunts for false households. The recipe takes quarters because the household signals worth trusting are limited (avoiding IP), the merge-split logic needs real data to tune, and the privacy design is substantive rather than a checkbox. This is not a starter recipe; it is for businesses where the household is genuinely the unit and the investment is justified.
Work in this order. Resolve individuals, group them on deterministic signals, and keep the grouping splittable and consent-bounded.
Household or account-level resolution covers steps 1 and 4, cross-device identity resolution step 2, identifier graph write steps 3 and 6, and consent-scoped signal collection steps 5, 7 and 8.
The first failure is the IP-defined household. Grouping everyone behind an IP address into a household has been unreliable since around 2020 and is functionally broken in shared-living and post-pandemic patterns, producing households that merge roommates, neighbours on shared infrastructure, or transient visitors. Household signals have to be deterministic and shared-by-design (payment, account structure), not network-inferred.
The second is the cross-member leak. The defining risk of household resolution is one member's behavior shaping or surfacing in another member's experience, which is awkward at best and a genuine privacy harm at worst when the behavior is private. The rules for what household-level data may drive, and the consent boundary around cross-member use, are the core of the recipe, not an addendum, and they are why legal is a critical role.
The third is the household that never splits. People move out, families change, accounts get reassigned, and a household graph that only merges accumulates errors that compound, eventually grouping people who have nothing to do with each other. Clean splitting on the signals that indicate a household has changed is what keeps the resolution honest over time.
The Workshop works out with your team which of these matter for your stack right now, and what to do first: a 90-minute session with the people who own the decision.
The deterministic household signals that avoid the broken IP heuristic, the merge-split rules that keep households current, and the cross-member consent boundary that keeps one person's data out of another's experience: those are the decisions that turn household stitching from a privacy risk into a coherent view of the real buying unit.
Did this recipe match your situation?Anonymous response. Sign up to leave a longer note tied to your account.
Resolve individual visitors to the account they belong to, so the buying committee shows up as one account rather than scattered anonymous leads
Connect the same person across phone, laptop, and tablet using signals you can stand behind, with an honest fallback when you cannot
Run identity resolution behind one service rather than each downstream system maintaining its own join logic, so a single resolution rule survives the next stack change