Autocapture vs Custom Events for B2B SaaS: What Should You Track?

Different tracking signals answer different questions

Autocapture is useful early because it collects selected interactions without a named event for each one. Its semantics often depend on DOM structure, selectors, labels, URL state, and retention. Custom semantic events require more planning but create stable product concepts. Server events are strongest when the backend owns completion. None replaces a correct identity and account model.

Use a four-layer B2B tracking model

1. Identity and account context: project, stable user, active company/workspace, membership or role, Visit, environment, and eligibility where required.
2. Pages and product structure: privacy-safe raw route, normalized page, grouped feature/page, product area, and ownership.
3. Broad behavioral evidence: selected autocapture, Visits, replay, transitions, and observed interaction.
4. Semantic outcomes: custom client/server events, persisted state, completed workflows, recurrence, and observable business outcomes.

A strong investigation can use all four: select an eligible account, confirm it reached the Reporting area, inspect the interface path, and verify that the backend generated an export. A perfect server event assigned to the wrong workspace remains misleading, so identity is the foundation.

Choose the tracking method with a practical framework

Autocapture stable controls that support exploration: navigation, selected interaction types, feature entry points, and permitted attributes. Handle free-form text, forms, rich editors, protected pages, dynamic selectors, and high-cardinality content conservatively. A “capture everything” default creates cost and privacy risk without creating reliable meaning.

Create custom events for stable customer jobs, important workflow stages, collaboration, durable object changes, and outcomes that drive adoption or retention analysis. Prefer server confirmation when the backend owns success. Keep automated actors explicit.

Separate client intent from server confirmation

A user can click Export and close the tab before generation. A worker can finish later, fail, retry, or deliver through an automated schedule. Model those as distinct facts:

report_export_requested   # client intent
report_export_generated   # authoritative server success
report_export_failed      # controlled server outcome

Use a stable event or operation ID to correlate attempts with outcomes and deduplicate ambiguous retries. Choose one canonical producer per logical event. Never fire the same “success” event independently from client and server without reconciliation.

Attach the active account/workspace at event time. One user can belong to several companies or switch contexts during a Visit. Historical events should not be reassigned from the user’s current membership. Include event-time role and eligibility when the metric depends on them, plus a system actor for scheduled jobs or webhooks.

{
  "event": "report_export_generated",
  "event_id": "evt_01J...",
  "occurred_at": "2026-08-04T09:42:18Z",
  "project_id": "project_123",
  "account_id": "account_456",
  "user_id": "user_789",
  "originating_visit_id": "visit_abc",
  "product_area": "reporting",
  "grouped_page": "report_builder",
  "role_at_event": "editor",
  "eligibility_at_event": "enabled",
  "result": "success",
  "method": "manual_export",
  "application_version": "2026.08.0",
  "environment": "production"
}

This is illustrative, not a Hymetry SDK contract. Allowlist controlled properties with an owner. Exclude unrestricted objects, emails as primary IDs, secret-bearing URLs, customer-entered names or queries, tokens, stack traces with user data, arbitrary error messages, and unbounded text. High-cardinality IDs can be necessary for identity or deduplication; uncontrolled cardinality without analytical purpose is the problem.

Preserve identity and timing explicitly

Resolve anonymous-to-known identity according to a documented rule, and test logout, account switching, impersonation, shared devices, invitations, and merged users. Keep project and environment boundaries explicit so staging traffic cannot silently enter production metrics. When a server job finishes later, preserve both the occurrence time and the ingestion time; the latter helps diagnose pipeline delay but should not replace the business timestamp.

For asynchronous workflows, record a stable correlation ID from request through outcome. Define whether retries are separate attempts or one logical operation, how late successes are attributed, and whether a scheduled or API actor can satisfy the same metric as a human. These decisions change counts even when every payload is technically valid.

Plan for fragility, retroactivity, privacy, and cost

Autocapture definitions based on selectors, text, and DOM hierarchy can drift after a redesign. Prefer stable permitted attributes such as a deliberate data-analytics-id where appropriate, but treat that as a governed interface contract. Test definitions after releases and version material semantic changes.

“Retroactive analysis” means defining meaning over previously captured and retained evidence. It cannot recover an interaction, property, account context, outcome, or replay that was never collected or has expired. Historical UI changes can also make an old selector ambiguous. When an exploratory finding becomes an important metric, promote it to a stable semantic or server event.

Privacy applies equally to client and server payloads. Server-side does not mean safe by default. Document purpose, access, retention, deletion, and regional requirements, and involve qualified privacy/legal review for the relevant jurisdiction.

Test a retrospective definition before trusting it

1. Sample historical interactions across application versions and responsive layouts.
2. Confirm that the required element, attribute, route, and account context were actually retained for the full analysis period.
3. Compare the retrospective rule with a semantic or server-confirmed signal over an overlap window.
4. Measure false positives caused by reused selectors, labels, modals, or embedded components, and false negatives caused by sampling or capture exclusions.
5. Document the earliest trustworthy date and the versions covered.

Use the resulting metric as provisional when the overlap test is weak. Retrospective definitions are excellent for triage and hypothesis generation; they should not quietly become contractual KPIs merely because a chart can be produced.

Worked example: instrument a Reporting workflow

No single event answers reach, intent, persistence, outcome, automation, cadence, and distribution. Keep the layers connected and name the metric precisely.

Implement and govern the model

1. State the decision and measured account/user entities.
2. Normalize pages and product areas.
3. Establish privacy-safe baseline page tracking.
4. Enable autocapture selectively.
5. Define the important workflows and eligibility.
6. Add semantic client intent and server outcomes.
7. Model persistent state and recurrence where an event is insufficient.
8. Validate account context, actor, timestamps, and deduplication.
9. Test raw data and representative Visits in production-like conditions.
10. Document definitions, owners, schemas, privacy, and effective versions.
11. Monitor quality, volume, drift, and unused collection.

Validate evidence before building the dashboard

Start with a small fixture matrix: one eligible human account, one ineligible account, one automated actor, one failed operation, one retry, and one account switch. For each case, compare the intended product action with the raw page, autocapture, client, and server records. Verify event order, event-time account context, actor type, controlled property values, deduplication, and environment. Inspect a representative Visit or replay only where policy permits.

Then reconcile aggregates in both directions. Sample dashboard rows back to raw evidence, and sample known product actions forward into the analysis. Check daily volumes by producer and application version, not just the total. Alert on missing identities, sudden selector loss, unexpected enum values, unusually late events, duplicate operation IDs, client requests without outcomes, and server outcomes without a traceable request when one is expected.

Compare old and new signals in parallel

Keep a short parallel-observation period when promoting an autocaptured definition to a semantic event. Plot both signals by account, role, application version, and day; investigate systematic differences instead of forcing the totals to match.

• Expect a semantic event to be narrower when it excludes disabled controls, failed operations, or repeated clicks.
• Record the overlap dates and the reason for the final boundary before updating funnels and alerts.
• Annotate the old and new series so a definition break cannot masquerade as a product trend.

After launch, review a small set of newly qualifying and newly non-qualifying accounts. This catches selector drift, account-context loss, eligibility changes, and background automation before a quarterly decision depends on them. Retire redundant evidence only after the replacement has passed that observation window and retention requirements are understood.

Ship a definition with an effective date and a named owner. If a redesign, queue change, permission change, or new automation alters meaning, version the metric or annotate the break. Backfills need the same review as live events: state the source, transformation, deduplication rule, affected dates, and limitations. This operational record is what makes a metric reproducible after the original implementer has moved on.

Connect product structure with behavioral evidence

Hymetry connects normalized and grouped Pages with Companies, Users, and Visits. Page evidence, account context, people, and session investigation remain distinct from authoritative semantic outcomes. Teams can review the demo project or open-source implementation.

Frequently asked questions

Sources

Method note: Vendor terminology and defaults differ. Official sources support implementation behaviors, not one universal tracking standard.