Event Property Design for User-Level and Account-Level Attribution

The three entities every B2B SaaS event must be able to address

The three entities every B2B SaaS event must be able to address

Every B2B SaaS event needs to answer two questions at once: who did this, and on whose behalf? Miss either one and every metric downstream, activation rates, feature adoption, churn signals, inherits the same blind spot. The person who signs up, the person who pays, and the person actually clicking around inside the product are routinely three different humans, and no amount of clever querying after the fact fixes an event stream that never captured account context in the first place.

Claudiu Murariu of InnerTrends puts the stakes bluntly: account-level data is "mandatory," and product analytics built on user data alone can actively mislead a team, to the point where he argues it's "better not to have data at all" than to trust a partial picture. He's right, and the mechanics behind the claim are straightforward once you look at how B2B products actually get bought and used.

Take a project management tool that defines activation as two or more users joining a workspace and completing at least one task together. That's not a user-level metric, it's an account-level one, built out of person-level events that have to be stitched back to a shared workspace. Without an account identifier riding on every event, there's no way to compute it, only to approximate it, badly.

The buying side compounds the problem. 61% of B2B deals involve three or more decision-makers, each entering the funnel at a different point and touching the product differently. A single-contact attribution model, one where every event just points back to "the user," can't represent that structurally. Fragmentation starts well before anyone designs a schema, too: traffic sits in GA4, product usage in one tool, revenue in ChartMogul, pipeline in HubSpot, with no shared identifier tying the four together (saashero.net, 2026). Layer on measurement loss from ad blockers and consent rejection, which SegmentStream's 2024 Measurement Landscape Report puts at 30 to 40% of users missed by traditional analytics setups (cited at leapbuzz.com), and the coverage gap compounds on top of an identity model that was already incomplete.

None of this gets fixed downstream. Activation metrics, feature adoption analysis, and behavior-grounded guidance to customers all depend on dual attribution, person and account, being present in the schema from day one. What follows is the design work that makes that possible.

Every event in a well-built stream needs to be addressable from three independent angles. It should be traceable to the person who acted, the account they acted within, and the event itself, which carries properties describing both at the moment it happened.

The person has an identity, a role, and a behavioral history that persists across accounts. The account has its own plan, configuration, and collective usage state, independent of any single person inside it. The event is the connective tissue: not just "what happened," but "what happened, by whom, on behalf of which organization, under what conditions."

This gets complicated fast, because the relationship between person and account isn't one-to-one. A single user can belong to multiple accounts, which is routine in collaboration and project management tools where consultants, agencies, or cross-functional employees sit inside several workspaces at once. Without account context stamped onto each event, a user's actions can't be attributed to the right workspace, and usage in one account bleeds invisibly into another.

Some events don't even have an individual actor behind them. "Payment_failed," "subscription_cancelled," "trial_expired," these are account-level state changes that affect everyone in the account simultaneously. They still need to land in the event stream, carrying the right account properties, even with no user_id driving them.

Role matters just as much as identity, and this is where a lot of adoption math quietly breaks. Not every person in an account is expected to touch every feature: billing admins exist, view-only members exist, and treating them as equally "eligible" to adopt a feature skews the numbers before analysis even starts. Role as a first-class property on the event is what makes eligible-cohort analysis possible later, covered further down.

The design goal that falls out of all this is simple to state and harder to enforce: every event should be independently queryable by person or by account, without a join that collapses one view into the other. Properties on the event payload answer "who did this, and in what context?" Properties on the person or account profile answer "what is the current state of this entity, right now?" Conflating those two questions is where most schemas quietly go wrong, and it's the mistake the rest of this piece is built around avoiding.

The property pairs that make dual attribution work on every event

Two identifiers are non-negotiable on every single event. The first is user_id, a stable, system-assigned identifier for the person, never an email address, since emails change and get reassigned. The second is account_id, the stable identifier for whatever organization or workspace the person was acting within at the moment the event fired. Account_id has to be present even when a user belongs to several accounts at once; without it, there's no reliable way to know which workspace an action belongs to.

Before someone logs in, they still generate behavior worth capturing. That's what anonymous_id is for: a device-scoped placeholder that the analytics layer aliases to a real user_id at the first identify call. Get that handoff wrong, and pre-login product behavior, browsing, signup friction, trial exploration, simply vanishes from the record.

Beyond those anchors, a set of global properties belongs on every event regardless of what the event actually represents. That includes an event_id for deduplication, an event_version to track schema changes over time, a timestamp reflecting when the event actually happened (not when it was ingested), a platform field distinguishing web, iOS, Android, or API, and an app_version that isolates behavior shifts tied to a specific release.

Account context needs its own layer of properties, and this is where a lot of schemas cut corners. Account_plan records the plan the account was on at the moment the event fired, which matters because plans change, and carrying plan on the event itself is what lets you correctly segment historical adoption by tier later. Account_created_at captures the account's age at event time, enabling cohort analysis without a join back to the accounts table. Account_size_band should be a stable categorical, something like "1 to 10," "11 to 50," "51 to 200," rather than a raw seat count, since raw counts drift with every hire and firing while stable bands survive plan changes cleanly.

Person context needs the same treatment. User_role records the role the person held within that specific account at that specific moment, the property that makes it possible to later ask "only people with editor permissions were eligible to use bulk export, so what share of them actually did?" User_created_at tracks how long the person has existed within the account, separating new-user behavior from established-user behavior without needing a join.

What doesn't belong on the event matters just as much as what does. Marketing attribution properties like initial_utm_source belong on the person or account profile, set once, not repeated on every downstream event. Repeating them bloats payloads and creates update-consistency headaches when an attributed source gets revised later, because now the same field disagrees with itself across thousands of historical rows.

Naming conventions matter more than they get credit for. Snake_case throughout, no dynamic values baked into event names (baking a date or identifier into an event name is a trap), dynamic values carried as properties instead. This single rule is what prevents the slow proliferation of near-duplicate event variants that eventually makes warehouse queries slow and expensive.

How property design at event time prevents "point-in-time" errors later

The question an event property answers is "what was true at the moment this happened?" That's the single most common shape of question in any meaningful product analysis. It's a fundamentally different question from querying a profile table, which only ever reflects the current state of the world, not the state of the world when the action occurred.

Here's where that distinction bites. An account upgrades from Starter to Growth mid-quarter. If account_plan lives only on the account profile and not on each event, every historical event from that lower tier now silently reads as though it came from a higher tier. Adoption analysis by plan tier becomes wrong retroactively, and nobody notices until the numbers stop making sense.

The same failure mode applies to roles. A user gets promoted from Viewer to Editor partway through the month. Without user_role recorded on each event as it fires, there's no way to correctly answer something as basic as "what share of Editors adopted bulk export within their first 30 days?" The profile says Editor today; the events from three weeks ago don't know that yet, and if they weren't tagged individually at the time, they'll just inherit the wrong label.

This is why account-context and person-context properties get denormalized onto each event at the moment it fires, not appended later. The goal is not padding. It's making every single event independently interpretable without requiring a time-travel join back to some other table's state as of a particular date.

There's a performance argument here too, not just a correctness one. Per Statsig (June 2025), queries built on well-structured user properties ran 50 to 100 times faster than equivalent queries that had to extract user attributes from event streams. Denormalizing at write time turns out to be far cheaper than reconstructing context at read time, every single time someone runs a report.

Versioning the schema is what keeps all of this from becoming brittle. Event_version lets a team change how a property is defined, expanding the account_size_band buckets, say, without silently corrupting historical queries, because downstream consumers can see exactly which schema version an event was fired under. A useful test for any property under debate: if its value could plausibly change between when the event fires and when someone queries it later, it belongs on the event, not only on the profile.

Separating product events, marketing attribution, and operational signals in the same schema

Three distinct systems tend to get tangled together in a single event stream, and per beefed.ai (December 2025), untangling them is most of the actual design work. Product events are the actions users take inside the app and the key lifecycle moments around them: signup, upgrade, cancellation, feature use. Marketing attribution is channel and campaign origin, which belongs as a property on the person or account profile captured at first touch, not as a repeated event fired on every ad impression or click. Operational and support signals are system-generated state changes, payment failures, provisioning completions, and they only belong in the event stream when they represent a moment that actually affects the user's experience of the product.

Mix these together carelessly and a workspace ends up with duplicate events like user_signup, UserSignup, and Signup_Clicked all coexisting, none of them clearly authoritative, all of them technically "real." Reports built on top become unreliable, and warehouse queries become expensive to run, per beefed.ai (December 2025). The failure here is a lack of interpretation, not a lack of data: it's data that looks trustworthy and isn't, which is worse, because a team acts confidently on numbers that are quietly wrong.

Account-level lifecycle events need a clear boundary rule. Something like trial_started or subscription_cancelled belongs in the product event stream, because it affects everyone in the account, but it should fire once at the account level, carrying account_id and relevant context, not duplicated once per user sitting inside that account.

Marketing attribution belongs on profiles, full stop. Initial_utm_source, first_touch_channel, referral_source, these get set once at acquisition time on the account or person profile. Analysts join to the profile when attribution context is actually needed, rather than dragging that context along on every downstream product event where it adds nothing and drifts out of sync.

Schema design can't fix the dark funnel, and it's worth naming that limit honestly. Per diggrowth.com (2026), over 80% of B2B SaaS deals show up in analytics as direct traffic or unknown source, no matter how clean the tracking plan is. What clean separation buys is narrower but real: the product event stream stays interpretable and trustworthy even when the attribution layer upstream is fuzzy or incomplete.

The discipline that ties this section together is starting minimal. Track only what's needed to answer the top handful of business questions the team actually has, then expand from there based on real analytical demand. Per beefed.ai (December 2025), every event added without a specific question behind it adds noise, plus governance cost down the line, and that cost compounds the same way duplicate event names do.

Eligible-cohort framing: why account and role properties are prerequisites for measuring adoption

Adoption rate is meaningless without knowing who was actually eligible to adopt. Reporting that some percentage of all users tried bulk export is noise if most of those users were on a plan or in a role that never had access to the feature to begin with. Most adoption dashboards get this backwards: they divide by total users instead of eligible users, which quietly overstates failure and understates success at the same time, and it's the single most common error in this whole discipline.

Three event-level properties, working together, are what define the eligible cohort correctly: account_plan tells you whether the feature was even available to that account at the time, user_role tells you whether that specific person had permission to use it, and account_id prevents double-counting someone who shows up across multiple workspaces.

Benchmarks are only useful once that denominator is right. B2B SaaS products typically see 20 to 30% adoption within the first 30 days of a new feature release, according to Pendo research cited at saasfactor.co, and the Product Metrics Benchmark Report 2024 (cited by Artisan Strategies) puts average core feature adoption rate at 24.5%. Those numbers only mean something next to your own data if your denominator is the actual eligible cohort, not every user who happens to have a login.

Getting that denominator right also unlocks a sharper diagnosis. Per saasfactor.co (citing Pendo research), 68% of adoption failures come down to discoverability rather than the feature simply lacking value. That distinction, "saw it and passed" versus "never had access at all," only becomes visible once plan and role properties sit on the events themselves, separating the two populations cleanly.

Account-level activation metrics push the same requirement further. An activation definition like "at least two users complete at least one task" requires aggregating person-level events under a shared account_id. Without that identifier, individual task completions can still be counted, but there's no way to know whether the account, as a unit, actually activated.

Repetition matters more than a single instance of use. Behavioral analytics research from Amplitude, cited at saasfactor.co, finds that features achieving repeated use within the first seven days see 3.2 times higher 90-day retention. Measuring "repeated" requires counting distinct events tied to the same person within the same account across time, which only works if user_id and account_id are both stable and consistently present across every session, not just the first one.

Adoption rate has a denominator problem by default, and that's the pattern across all of it. The schema has to be built so that denominator can be computed directly from the data, not estimated after the fact with a shrug.

Encoding usage cadence expectations so behavioral signals don't generate false alarms

Login frequency, taken alone, is a weak signal for most B2B tools, because usage rhythms vary wildly by category. A payroll product used once every two weeks is healthy at that cadence. Flag every seven-day gap as a churn risk, and customer success teams drown in false positives, chasing accounts that are behaving exactly as expected. Treating a single universal cadence as normal across every product category is the mistake worth naming directly, and it's the fastest way to burn a CS team's trust in its own alerting.

The fix is a property, not a smarter alert rule. An account or person record carrying a cadence tier, product_usage_cadence set to "weekly" or "monthly," say, gives the event stream something to filter against. Absence of activity then gets judged relative to the expected rhythm for that account, rather than against some arbitrary universal clock that treats every product the same way.

Some signals are genuinely meaningful, and they share a structure: a champion's login frequency drops relative to their own historical baseline, feature breadth narrows across successive periods, or activity spikes suddenly on billing and export pages. Detecting any of these requires comparing current event patterns against an account's own history, which only works if account_id and user_id have stayed stable and consistently present across every event since the account's earliest days.

Absence itself has to be something the schema can represent as signal. Knowing that a person who used a feature weekly has now gone three weeks without firing the relevant event requires that the event, the person, and the account are all still queryable together across that stretch of time. If account_id was missing or inconsistent in early instrumentation, that history is gone, and there's no baseline left to measure the silence against.