Customer Event Tracking via Direct Sync

A customer completes a purchase in Stripe. Three hours later, they open a support ticket in Intercom. The next morning, they click a link in your Mailchimp campaign. Each of these events lives in a different tool, tagged with some version of the customer's identity. Your support agent sees the ticket but not the purchase. Your marketing tool sees the click but not the ticket. Customer event tracking is technically happening in all three tools. The problem is that none of them know these events belong to the same person.

The standard advice for connecting events to profiles goes like this: ingest everything into a warehouse, build dbt models that join events to a customer table on user_id, schedule the pipeline, then push the results back out to the tools that need them. For a team with a data engineer and an existing warehouse, that works. For a team of 12 where the founder also handles ops, it's a six-month project that never gets prioritized. For background on how identity resolution works at the conceptual level, start there. This article gets into the specific mechanics of linking event data to profiles directly, with the warehouse as an option for analytics rather than a prerequisite.

Why customer event tracking data and profile data live in different systems

Profile data and event data have fundamentally different shapes, and most tools are built for one or the other.

A CRM stores profile data: one row per customer with columns for name, email, plan, lifecycle stage. The row gets updated when something changes. HubSpot overwrites the old value with the new one. Salesforce timestamps the change. Either way, you end up with one current state per customer.

Event data doesn't work that way. A single customer might generate hundreds of events: page views, purchases, support conversations, email opens, feature activations. Each event is its own record with a timestamp. You don't overwrite a purchase with the next purchase. You store both. The data accumulates.

This mismatch explains why tools specialize. Your analytics platform (Mixpanel, PostHog, Amplitude) is built for event streams. Your CRM is built for profile records. Neither is built for both, and the connectors between them are thin. PostHog knows the customer clicked five buttons this week. HubSpot knows their lifecycle stage. Neither tool surfaces the other's data. So customer event tracking happens in silos, and the event data never reaches the customer profile where it would actually inform a decision.

The warehouse approach bridges this by pulling both data types into one store and joining them with SQL. That works, but it creates a dependency chain: events flow from the source tool into the warehouse, get transformed by a dbt model, then get pushed back to tools via reverse ETL. Each link adds latency. The purchase that happened at 9 AM might not appear on the customer's CRM profile until the next pipeline run completes.

The question worth asking is whether you need the warehouse in the middle at all. If the event already carries the customer's email or user ID, the join key is already present in the event itself.

How customer event tracking connects to profiles through relation fields

Relation fields are the mechanism that lets a CDP link one record type to another. They work like a foreign key in a database: this event record points to that customer profile using a shared identifier.

Here's how it plays out with a concrete example. You connect Stripe as a source and configure it to sync two record types: Customers (profile data) and Charges (event data). Each Charge record has a customer_email field. You define a relation field: Charges relate to Customers via email.

When the CDP ingests a new charge, it reads the customer_email field, finds the matching customer profile, and attaches the charge as a related record. The profile now shows the customer's attributes (name, plan, lifecycle stage) alongside their charge history. No SQL join. No dbt model. The link resolves during ingestion because the event already contained the identifier.

This is what identity resolution looks like at the record-type level. Instead of resolving which anonymous sessions belong to the same person (the enterprise problem), you're resolving which events belong to which profile. When the event carries a known identifier, the resolution is deterministic. Matching on email or user_id gives you a 100% confidence link.

The same pattern applies across tools:

• Intercom conversations linked to CRM contacts via email

• PostHog events linked to customer profiles via user_id

• Mailchimp campaign activity linked to contacts via subscriber email

• Stripe subscriptions and charges linked to unified profiles via customer email

Each event type becomes a related record on the profile. Open a customer's profile page and you see their attributes at the top and their event timeline below. This is what it means to link events to customer profiles in a way that's actually useful: the support agent who opens this profile before responding to a ticket sees recent purchases, product usage, email engagement, and support history in one place.

Append-only vs. merged record types and when to use each

Not all data should be merged into a single row. This is where most sync tools get it wrong: they treat every incoming record as an update to an existing profile. That works for attributes like name, plan tier, and lifecycle stage. It falls apart for events.

Merged record types are the default behavior for profile data. When a CDP syncs a customer from Stripe and finds an existing profile with the same email in HubSpot, it merges the records. Stripe's subscription status enriches the HubSpot contact. If both tools have a value for the same field, merge rules determine which one wins.

Append-only record types handle event data differently. Configure a record type as append-only, and each record gets stored individually. The CDP doesn't try to merge ten purchase events into a single purchase profile. It stores all ten and links each one to the customer profile through the relation field.

The distinction matters for accuracy. Consider a customer who made three purchases this quarter:

If these were merged, you'd end up with one record showing the most recent values. The $49 and $99 purchases would be overwritten. With append-only, all three appear as individual records on the customer's profile. The timeline stays intact.

The practical rule: if a record represents a state (who the customer is right now), merge it. If it represents a discrete occurrence (something the customer did at a specific time), append it. Most teams need both: merged profiles enriched with attributes from across tools, plus append-only event streams that preserve the full history. The combination is what turns basic customer event tracking into an actual event data customer profile that your team can act on.

Building a behavioral data customer view without SQL or a warehouse

The warehouse approach to a customer 360 follows a specific pipeline: collect events from tools, load them into a warehouse, write SQL or dbt models to join events to customer records, then activate the joined data by pushing it back to tools. Every step requires engineering time to build and maintain.

The relation-field approach collapses that pipeline. Events go from the source tool to the CDP. The CDP resolves the link at ingestion using the identifier already present in the event. The linked profile, now enriched with event data, syncs to every destination. Three steps instead of five. Warehouse optional.

What this looks like in practice for a 20-person SaaS company:

• Stripe charges and subscription events sync as append-only records, linked to customer profiles by email. The profile shows MRR, plan tier (merged attributes), and the full charge and subscription change history (appended events).

• Intercom conversations sync as append-only records. Each conversation links to the customer profile. The support agent sees the customer's billing context alongside their conversation history.

• PostHog product events sync as append-only. Feature usage, page views, and session data attach to profiles. Your growth team can see which features a customer used this month without querying PostHog directly.

The combined profile tells a story that no individual tool can tell on its own. The customer upgraded to the Team plan last month (Stripe), filed two support tickets about the new billing (Intercom), and started using the advanced reporting feature three days after upgrading (PostHog). That narrative exists across three tools. Relation fields assemble it onto a single profile page.

I want to be clear about the limitations, though. This approach works when events carry a known identifier. Anonymous pre-login events, cross-device tracking before the user authenticates, cookie-based session stitching: those still need the full identity graph approach with probabilistic matching. If you're tracking millions of anonymous sessions, a warehouse and ML pipeline is probably the right architecture.

But most B2B SaaS teams aren't matching anonymous sessions. They're matching purchases, support tickets, and product events to customers who already logged in. The email address is right there in the event payload.

Oneprofile handles this with relation fields that resolve at ingestion time: connect your tools, define which record types are append-only, specify the relation field, and events start appearing on customer profiles on the next sync. The customer record matching happens using the same deterministic matching that powers profile unification. Warehouse optional. No SQL. No dbt. If the identifier matches, the event links.

For teams that start here and eventually need warehouse-based analytics on top, Oneprofile works alongside a warehouse without replacing it. Sync your events to the warehouse for deep analysis, and keep the relation-field approach for operational profiles that your team uses daily. The two architectures aren't mutually exclusive. Most teams just don't need to start with both.