Turn existing product usage into reviewed AE alerts

Choose a pattern the AE can explain in one sentence. For this pilot, use successful workflow execution by several existing members across several days. Do not alert on a page view, login, or a single anonymous action. Confirm with the product owner what success means in the installed event catalog and whether retries generate another event. Segment Track events have a required event name and optional properties. The specification does not supply your product-specific definition of success.[1]

Agree on the receiving team before calculating anything. Route an account with an active sales opportunity to its sales owner. Route a managed customer to its existing account team under the agreed sales and CS policy. Hold accounts with conflicting owners or an unresolved commercial entity. Exclude internal workspaces, demos, test accounts, suspended tenants, and opt-out categories defined by your internal policy. Keep usage interpretation separate from forecasting and expansion-opportunity creation.

Define a normalized observation with source_id, message_id, event_name, event_time, received_at, exported_at, processed_at, workspace_id, user_id, execution_id, execution_status, and schema_version. Store the original payload in a restricted location if your retention policy permits it. The illustrative existing event is Workflow Execution Completed with execution_status=success. execution_id and workspace_id are local contract fields, not universal Segment fields. Require a documented mapping to actual exported properties. A missing required identifier creates a held observation, not a fabricated identifier.

Publish alert_id, canonical_account_id, crm_company_id, rule_id, rule_version, window_start, window_end, distinct_executions, distinct_users, active_days, latest_event_at, evaluated_at, entitlement_observed_at, owner_id, evidence_reference, status, cooldown_until, and disposition. Use explicit statuses such as held, ready_for_review, acknowledged, dismissed, expired, and withdrawn. Keep held_reason separate from a commercial disposition. Restrict the evidence reference to an authenticated account-scoped view, and omit raw project content, IP addresses, and user email addresses from the review card.

Use event_time for the business window only after validating the source timestamp semantics. In Segment, timestamp is the corrected occurrence timestamp, receivedAt is when Segment receives a message, and originalTimestamp reflects the client invocation or supplied server timestamp. Segment does not guarantee chronological ordering by receivedAt. Processing time is when your alert job evaluates the observation. Export time is another separate timestamp. A just-processed record can describe an old action.[2]

Segment documents an offline batching caveat for Swift, Kotlin, and C# mobile libraries where calculated timestamp can reflect receipt more closely than device occurrence. Client timestamps can also be manipulated. For a chronology-dependent rule, prefer an already available authoritative server event or a source whose behavior the product team has validated. If the existing source cannot distinguish old activity from recent activity, hold that rule. Do not fix the uncertainty by adding instrumentation or treating receipt time as proven occurrence time.[2]

Create a resolver using existing workspace membership and account registry exports. Record workspace_id=ws_412, canonical_account_id=acct_208, crm_company_id=50188, mapping_version=12, valid_from, valid_to, and mapping_status=approved. Resolve the workspace-to-account relationship at the event time, then check the current commercial account before delivery. Keep subsidiaries separate unless an approved contract defines the parent rollup. Do not use a user email domain to decide which company receives activity.

Segment Group associates a user with a group, and a user can belong to multiple groups. Its common context.groupId can attribute non-group calls to an account. A latest Group trait is therefore not proof of the workspace in which a past action occurred. Use the event workspace identifier and historical membership if they already exist. If a multi-workspace user lacks event-level workspace context, hold the observation as ambiguous_workspace. Acceptance requires a user in ws_412 and ws_799 to contribute only to the workspace supported by the existing event evidence.[3][2]

Join the account to an existing authoritative entitlement snapshot, not a plan label from a historical event. If Stripe is that authority, active entitlements represent customer access to features. Stripe entitlement summary webhooks contain at most ten entitlements, and the complete list may require pagination. Feature changes on existing subscriptions create active entitlements at the next billing period. Use the already maintained, reconciled snapshot and its completeness flag. An incomplete snapshot cannot prove that a feature is absent.[4]

Keep product entitlement and employee visibility as separate gates. An entitled customer does not mean every AE may see its usage. Require an approved recipient-to-account policy at evaluation, delivery, and evidence-view access. PostgreSQL row security can restrict normal queries, but superusers, BYPASSRLS roles, and typically table owners bypass it. Test with the actual consumer role rather than an administrator. Use a local freshness policy, such as an entitlement snapshot no older than one hour. Hold alerts on stale snapshots or denied recipients, and never change product access from an alert.[6]

Set illustrative rule workflow_adoption_v1 to at least 20 distinct successful execution IDs, at least three distinct existing members, and activity on at least three UTC dates in a rolling seven-day window. Require at least one qualifying event in the last 24 hours. Define the window as event_time at or after evaluation time minus seven days and strictly before evaluation time. Publish the exact evaluation time with the counts. These values are pilot choices, not research-backed conversion predictors or vendor defaults.

Count each execution once after event dedupe, and exclude the existing bot, internal, and test classifications. If those classifications are unavailable, do not present a cleaned member count as fact. Aggregate workspace evidence only through the approved account mapping. Calculate a reason such as "24 successful executions by four members on four dates in the seven-day window." Add the current entitlement state and observation time. Acceptance tests include 19 versus 20 executions, two versus three members, a boundary-time event, and many retries of one execution. Only the case meeting every requirement becomes ready_for_review.

Deduplicate exported messages using source_id plus message_id. Segment provides messageId as a message identifier, but it does not promise that separate producer calls for the same business execution share that ID. Use the existing execution_id to prevent those calls from inflating execution counts. Quarantine different success states for the same execution until the product contract resolves them. PostgreSQL unique keys and ON CONFLICT can enforce local duplicate handling. They do not guarantee exactly-once delivery to the CRM.[2][5]

Keep one open review item per canonical_account_id and stable rule_id. Store rule_version with the evidence, not in the logical item key. A routine upgrade refreshes or explicitly supersedes the unanswered item without another notification. A genuinely different rule needs a new approved rule_id. Test an unanswered v1 item during v2 rollout and require one logical item. Resolve the current owner before delivery; hold conflicts and withdraw wrong-owner items. Start in a restricted queue. A separately approved adapter may update an existing CRM record by ID. HubSpot supports those reads and updates. Do not create opportunities, modify stages, or send outreach by default.[7]

Give the AE four dispositions: review_planned, already_known, not_actionable, and data_issue. Capture actor_id, alert_id, rule_version, disposition_at, and an optional short explanation. review_planned records a human decision without proving that a customer conversation happened. data_issue routes the evidence reference to the data owner and suppresses that account-rule item until resolution. Preserve prior evidence versions so a reviewer can understand why an alert first appeared even after later activity changes the counts.

Use a fourteen-day pilot cooldown after acknowledgement or dismissal. Keep the account-rule cooldown across routine rule-version upgrades so a deployment cannot notify everyone again. After cooldown, require fresh qualifying activity and a newly met threshold after a reset below the threshold. Do not re-alert merely because a still-active account remains above the same level. A Sales manager can approve an explicit manual reopening with a reason. Expire or withdraw unresolved items when their freshness or eligibility gates fail. Late-arriving old activity may correct evidence but must not override cooldown.

A synthetic AE card reads "Workflow adoption review. Account acct_208 recorded 24 successful executions by four members on four UTC dates. Window is October 7, 09:05 UTC inclusive to October 14, 09:05 UTC exclusive. Latest activity occurred October 14, 08:20 UTC. Evaluated October 14 at 09:05 UTC. Entitlement checked at 08:45 UTC. Rule workflow_adoption_v1." The next action is to inspect account context and choose a disposition. The card links to authorized aggregate evidence and the CRM record. It does not expose another workspace or claim that the customer wants an upgrade.

Test out_of_order_execution with an 08:20 action processed before an 08:10 action. Counts must use occurrence windows, not arrival rank. Test stale_backfill with last-week events processed today, future_clock with a timestamp beyond the agreed clock tolerance, multi_workspace_user, revoked_entitlement, duplicate_execution, owner_reassignment, and denied_evidence_access. Use a two-hour lateness allowance for pilot recalculation, but call it an operating policy rather than a completeness guarantee. Inspect the consumer queue after every case. Old backfills cannot become fresh activity, held records explain the reason, and a denied recipient cannot open evidence.

Measure resolution coverage within a fixed period using distinct source_id plus message_id observations that pass the selected rule's schema and identical non-identity eligibility filters. The numerator is the subset with approved account resolution; the denominator is that whole population. Keep identity-dependent exclusions until identity is known. Report ambiguous mapping holds and intentional exclusions separately, not as successful resolution. Show raw counts and the percentage; a zero denominator is unavailable. Measure evidence delay as processed_at minus validated event_time and transport delay as received_at minus event_time, in minutes. Preserve negative clock discrepancies. Publish each distribution with observation count and source-library mix.

Measure reviewed usefulness as review_planned dispositions divided by all explicit non-data-issue dispositions for the cohort. Report data_issue rate as data_issue dispositions divided by all completed dispositions. Measure repeat exposure as account-rule items delivered during an active cooldown divided by delivered items. The intended result is zero, not a claimed measured result. Track ownership correctness as items whose recipient matches the approved current owner divided by inspected delivered items. Keep unanswered alerts out of usefulness conclusions and report their age separately.

The product data owner approves event meanings and timestamp provenance. The security owner approves recipient access and evidence retention. RevOps approves commercial account resolution, ownership, and threshold versions. Sales management chooses a small review cohort and confirms disposition responsibilities. Run the existing export through a shadow queue before enabling any CRM output. Compare positive and negative examples with the source records and recipient views. Do not edit analytics tags, SDK calls, destination configuration, or consent collection to make the pilot pass.

On bad alerts, the GTM engineer pauses evaluation and delivery while leaving existing product collection untouched. RevOps withdraws affected review items and preserves dedupe keys, cooldowns, and feedback. The CRM administrator corrects only adapter-owned output fields. The product data owner resolves event semantics or identity problems through the normal source-data process outside this playbook. Resume after the agreed cases produce the correct consumer-visible results and access checks. Keep a dated rule approval and a list of affected account IDs so rollback does not erase the human review history.