PQL scoring для PLG: от product events до sales action

PQL score полезен, только если пересечение threshold что-то меняет. Слишком многие команды начинают с формулы 0–100, называют верхний квартиль hot и синхронизируют его с CRM. Sales получает новый список, но никто не объясняет, почему account туда попал и улучшает ли contact conversion.

Стройте систему в обратном порядке:

decision → success label → observation window → features → score → threshold → action

Сложность не в SQL. Сложность — не превратить удобную correlation в дорогой sales workflow.

Сначала определите decision

«Найти вероятных покупателей» недостаточно конкретно. Выберите один action:

• создать sales task для account;
• предложить assisted onboarding;
• отправить account на expansion review;
• показать in-product upgrade message;
• подавить outreach, пока account исследует продукт;
• передать blocked workflow в product research.

Error cost разный. False positive в in-product message раздражает. Неуместный sales email может повредить trust. False negative в enterprise expansion оставляет revenue без внимания.

Запишите decision contract:

Значения иллюстративны. Выбирайте их по реальному sales cycle и operating model.

Определите buying unit

В self-serve tool один user может найти ценность, принять решение и заплатить. В B2B несколько людей оценивают продукт вместе, а procurement или admin контролирует purchase.

Если покупает account, используйте account-level features:

• active members с точным определением active;
• role diversity, если её сбор разрешён;
• повторное использование core workflow несколькими members;
• collaboration внутри workspace;
• consumption относительно plan limit;
• admin или billing-page behavior;
• failures, блокирующие распространение;
• текущий contract, region и product eligibility.

Не суммируйте user scores напрямую. Десять случайных invitations не означают intent в десять раз сильнее. Используйте bounded account features и сохраняйте users и events, которые их создали.

Identity resolution требует собственных правил. Общий email domain не всегда одна компания, а free email не доказывает low value. Domains, SSO organization IDs, billing accounts, verified invitations и CRM mappings могут конфликтовать. Храните match confidence и отправляйте ambiguous accounts на resolution, а не объединяйте молча.

Найдите value signals без label leakage

Feature должна наблюдаться до decision и быть доступной в production на scoring time.

Value signals

Они показывают, что product выполнил часть core job:

• workflow завершён успешно, а не просто открыт;
• output consumed, shared, exported или revisited;
• use повторяется в разные дни;
• collaboration между members;
• integration используется в реальном workflow;
• ранее blocked task завершена.

Buying или expansion signals

Они могут показывать коммерческий timing:

• релевантный limit приближается или достигнут;
• просмотрены billing, plan или admin pages;
• teammates invited и activated;
• usage распространяется на другую team;
• предпринята попытка paid capability;
• задан procurement или security question.

Один event может означать frustration, а не intent. Повторный paywall hit может быть value, confusion или broken entitlement check. Проверяйте примеры до weighting.

Leakage, который нужно исключить

Не обучайте и не считайте по данным, вызванным outcome:

• subscription_created при prediction subscription;
• meeting, booked после контакта rep;
• CRM stage, обновлённый после qualification;
• features, доступные только paid plan;
• enrichment или notes, созданные sales action, который score должен запустить.

Не используйте и future activity в более раннем score. В каждом feature query нужен as_of timestamp.

Чистая event taxonomy — prerequisite. Если смысл event изменился между releases, version it или ограничьте analysis window.

Создайте feature table с time boundaries

Feature snapshot отражает только знания в конкретный момент. PostgreSQL-style SQL:

WITH eligible_accounts AS (
  SELECT
    a.account_id,
    a.created_at,
    a.created_at + INTERVAL '21 days' AS score_at
  FROM accounts a
  WHERE a.is_internal = false
    AND a.deleted_at IS NULL
),
features AS (
  SELECT
    a.account_id,
    a.score_at,
    COUNT(DISTINCT CASE
      WHEN e.event_name = 'workflow_completed' THEN e.user_id
    END) AS members_completing_workflow,
    COUNT(DISTINCT CASE
      WHEN e.event_name = 'workflow_completed' THEN DATE(e.occurred_at)
    END) AS active_workflow_days,
    COUNT(*) FILTER (
      WHERE e.event_name = 'teammate_activated'
    ) AS activated_teammates,
    COUNT(*) FILTER (
      WHERE e.event_name = 'plan_limit_reached'
    ) AS limit_events,
    MAX(e.occurred_at) AS last_event_at
  FROM eligible_accounts a
  LEFT JOIN events e
    ON e.account_id = a.account_id
   AND e.occurred_at >= a.created_at
   AND e.occurred_at < a.score_at
  GROUP BY a.account_id, a.score_at
)
SELECT * FROM features;

Window закрывается до открытия label window. Разделяйте event time и warehouse ingestion time, чтобы late events не переписывали historical predictions без audit trail.

Добавьте data-quality fields: event coverage, identity confidence, late-event count и schema version. High score из неполной telemetry не должен создавать sales task.

Начните с explainable rules model

Используйте rules, которые можно объяснить product knowledge и historical examples:

SELECT
  account_id,
  score_at,
  (
    CASE WHEN members_completing_workflow >= 2 THEN 2 ELSE 0 END +
    CASE WHEN active_workflow_days >= 3 THEN 2 ELSE 0 END +
    CASE WHEN activated_teammates >= 1 THEN 1 ELSE 0 END +
    CASE WHEN limit_events >= 1 THEN 1 ELSE 0 END
  ) AS evidence_points,
  ARRAY_REMOVE(ARRAY[
    CASE WHEN members_completing_workflow >= 2 THEN 'multi_member_value' END,
    CASE WHEN active_workflow_days >= 3 THEN 'repeated_core_workflow' END,
    CASE WHEN activated_teammates >= 1 THEN 'teammate_activated' END,
    CASE WHEN limit_events >= 1 THEN 'relevant_limit_reached' END
  ], NULL) AS reasons
FROM account_feature_snapshots;

Числа — placeholders. Backtest обязателен. Не называйте шесть points «92% probability conversion». Это rule priority, а не calibrated probability.

Начните с review queue, а не automatic outreach. Sales отмечает:

• useful signal;
• wrong account или identity;
• real value, но wrong timing;
• no commercial fit;
• already in process;
• product problem, не sales opportunity.

Такой feedback часто улучшает definitions быстрее новых features.

Аккуратно задайте label

Outcome должен соответствовать action. Paid conversion может быть неверным label, если sales работает над opportunity creation; self-serve checkout может считаться success, даже если outreach не сыграл роли.

Для product-led sales подходят, например:

• sales-accepted opportunity в fixed horizon;
• verified expansion opportunity;
• qualified meeting плюс later pipeline acceptance;
• incremental paid conversion, attributable to intervention.

Храните label time и source. Freeze outcomes только после завершения horizon. Исключайте accounts, уже contacted до score_at, если модель учится для first outreach, или явно моделируйте treatment history.

Class imbalance нормален. Показывайте absolute counts вместе с precision и recall; accuracy выглядит отлично, если предсказывать «not qualified» всем.

Оценивайте через time split

Random train/test split переносит одинаковые market и product conditions в обе части. Предпочитайте:

1. train на старых closed cohorts;
2. tune на следующем cohort;
3. один раз evaluate на newest untouched cohort;
4. повторять rolling backtest.

Сравните минимум три baselines:

• eligible accounts по recent activity;
• transparent rules model;
• statistical model вроде logistic regression или gradient boosting.

Проверяйте:

• precision на числе accounts, которое sales обрабатывает;
• recall последующих successful accounts;
• calibration, если output назван probability;
• lift относительно baseline ranking;
• performance по product, market, plan, account age и acquisition source;
• stability во времени;
• missing-data и identity-resolution slices.

Не выбирайте model только по area under curve. Operating question: полезна ли top review queue при реальном capacity.

Выбирайте threshold по capacity и error cost

Универсальный «hot от 75» бессмыслен. Если sales проверяет 30 accounts в неделю, смотрите precision top 30 и expected value после contact cost. Для in-product action capacity другой, но user experience тоже имеет стоимость.

Используйте hysteresis:

• account входит в queue выше entry threshold;
• выходит ниже более низкого exit threshold или после expiry;
• reasons изменения сохраняются;
• duplicate tasks подавляются при open opportunity;
• stale scores явно expire.

Threshold может меняться вместе с capacity. Calibrated score не нужно переписывать только ради заполнения queue.

Сделайте production pipeline наблюдаемым

Product events
  → validated event store
  → identity/account mapping
  → as-of feature snapshots
  → versioned scorer
  → eligibility and policy gate
  → review queue / in-product action
  → outcome and feedback log

Version feature definition, model, rules и threshold отдельно. Для каждого action сохраняйте:

• score и calculation time;
• model или rule version;
• top evidence reasons;
• eligibility decision;
• action created или suppressed;
• reviewer и outcome;
• source event references, где возможно.

Monitor missing features, event lag, score distribution, queue size, task delivery, identity conflicts, outcome delay и performance drift. Live PLG dashboard показывает весь funnel, а не только число hot leads.

CRM и model-provider secrets принадлежат backend infrastructure. Не вызывайте external API и не раскрывайте CRM tokens из client application. Используйте authenticated server или edge function с least-privilege credentials, input validation, retries, idempotency и PII-safe logs.

Используйте LLM только для grounded brief

Sales нужны reasons, а не mysterious number. После score LLM может суммировать approved, minimal features:

Создай factual review brief из переданных account signals.
Используй только эти fields. Не выводи company strategy, budget, role, intent,
private identity и use case. Не предлагай claims без evidence.

Верни JSON:
{
  "observed_value": [],
  "commercial_signals": [],
  "product_blockers": [],
  "questions_for_review": [],
  "source_signal_ids": []
}

При конфликте или пропуске evidence скажи об этом. Не рекомендуй contact account.
Решение принадлежит policy gate и reviewer.

ACCOUNT SIGNALS:
{approved_aggregates}

Не отправляйте raw prompts, document contents, emails и sensitive product data без разрешения data boundary. Наблюдайте latency, errors, cost и unsupported-claim rate; гайд по LLM observability показывает pattern.

Проверяйте incremental value, а не correlation

Model может предсказывать conversion, а outreach оставаться бесполезным. High-scoring accounts могли бы конвертироваться сами.

После безопасного review period проведите controlled holdout среди eligible accounts в одном score band:

• treatment получает заданный sales или in-product action;
• control остаётся на business as usual;
• assignment происходит до action;
• primary outcome и guardrails заданы заранее;
• contamination и rep overrides логируются;
• analysis следует intent to treat.

Измеряйте incremental opportunity, conversion, revenue, unsubscribe или complaint rate и user-experience guardrails. Плейбук экспериментов разбирает sample sizing и stopping rules.

Privacy, direct-marketing, profiling и sector rules зависят от юрисдикции. Проверьте, что collection, scoring, enrichment и outreach соответствуют notices, permissions, contracts, retention и suppression requirements. Минимизируйте PII и аудитируйте access.

Recalibrate при изменении системы

Не recalibrate по календарю только потому, что monthly звучит дисциплинированно. Review нужен, когда:

• меняются activation или packaging;
• сдвигаются acquisition mix или target market;
• меняются event definitions или identity mapping;
• меняется sales motion, capacity или success label;
• дрейфуют score calibration или top-queue precision;
• material group получает систематически плохие outcomes;
• слишком много tasks expire без review.

Удаляйте features с нестабильным смыслом. Храните old model versions для воспроизводимости прошлых decisions.

Самая короткая полезная версия

1. Выберите один account-level action и один success label.
2. Определите eligibility, observation и outcome windows.
3. Выберите два–три verified value/buying signals.
4. Создайте weekly human review queue с reasons.
5. Записывайте reviewer feedback и downstream outcomes.
6. Backtest только после закрытия достаточного числа outcome windows.
7. Проверьте экспериментом, создаёт ли action incremental value.

Это уже PQL system. Формула на 100 points, LLM narrative, real-time stream и ML model опциональны. Traceable evidence и лучшее решение — нет.