SocialHub.AI
エンジニアリングリファレンス

予測モデルのリファレンス

Flash の予測レイヤーは ガラスの箱 です。12 個の古典的な決定論的モデルであり、ブラックボックス スコアリングはありません。すべてのモデルは純粋な TypeScript であり、構築により決定的 (固定オプティマイザーとスケジュール、ランダム初期化、サンプリングなし - 同じデータが常に同じモデルを生成するため、スコアの変更は常にデータ変更に追跡されます)、テナントごとにそのテナント自身のデータから毎晩再調整され、正直さゲートされます: 各モデルの指定された実際の履歴の最小値を下回ると、出力は NULL/不在になります - サーフェスは推測ではなく何もレンダリングしません。予測はランク付けされ、示唆されます。実行はプラットフォームの承認、上限、同意チェックよりも遅れます。

このページは、モデルごとのエンジニアリング リファレンスです。各モデルが計算する内容、そのメソッド、入力、出力とそれらが到達する場所、正直ゲート、およびモデルを消費するサーフェスなどです。ビジネス向けのストーリーについては、Predictive Intelligence 製品ページをご覧ください。すべてのモデルが背後で実行されるガバナンス レールについては、AI ガバナンス ガイド をご覧ください。

全モデル共通の4つの保証

構築による決定論的

すべてのモデルは固定のオプティマイザーとスケジュールを備えた純粋な TypeScript であり、ランダムな初期化やサンプリングはありません。同じデータからは常に同じモデルが生成されるため、スコアの変化は常にデータの変化につながります。

テナントごとに毎晩改装します

各モデルは、テナント独自のデータ、つまり独自の元帳、独自の送信、独自の注文から毎晩再調整されます。テナント間プールはありません。

正直ゲート

各モデルの指定された実際の履歴の最小値を下回ると、出力は NULL/不在になります。サーフェスは推測ではなく何もレンダリングしません。すべてのゲートはこのページにリストされています。

ランク付けして提案するが、決して実行しない

予測はランク付けされ、示唆されます。実行はプラットフォームの承認、上限、同意チェックよりも遅れます。独自にお金を動かしたり、メンバーに連絡したりするモデルはありません。

12のモデル

  1. 解約リスクと 12 か月の CLV
  2. 次回購入予定日
  3. クリック傾向
  4. 送信するのに最適な時間帯
  5. A/Bトラフィックの自動最適化
  6. ウィンバックの上昇
  7. アイテムの類似性 (アイテム-kNN)
  8. 協会規則
  9. 類似点
  10. 外れ値の不正行為検出器
  11. 保持期間 (KM + Cox)
  12. 収益見通し (Holt-Winters)

1. 解約リスクと 12 か月の CLV

購入者ごとに:顧客が静かに離脱した確率(churn_risk(0~100)と今後12ヶ月間の予想支出(predicted_clv_12m).

方法BG/NBD — 購入頻度とドロップアウトに関するパレートファミリーの購入パターン モデル — ガンマ-ガンマ支出モデルと組み合わせたもの。どちらも、決定論的なネルダー・ミードを介して、チームごと、夜ごとに調整されます。
入力各メンバーの購入履歴の単一ソースとしての購入台帳 (チーム独自のポイント獲得トランザクション)。テナントの台帳以外には何もありません。
成果とその着地点member_behavior_rollup 列: churn_risk (0~100、100 × (1 − P(生存))として計算) predicted_clv_12m (E[365日以内の繰り返し取引数] × E[1取引あたりの支出額]) および predictive_confidence.
正直ゲートチーム フィット ゲート: 購入者 200 人以上、リピート購入者 50 人以上、両方のフィットが収束する必要があります。ガンマ-ガンマではさらに、有限の母集団平均が必要です。そうでない場合、CLV は弱い基礎として述べられている、メンバー自身の平均支出に戻ります。メンバーゲート: 非購入者は決してスコアリングされません。購入回数が 3 回未満、または購入履歴が 2 か月未満 → NULL。
消費面プロファイルの予測アウトルック、 churn_risk および predicted_clv_12m セグメント条件、再獲得ランキング、推奨アクションカード

2. 次回購入予定日

各メンバーの次の購入がいつ予想されるか、およびその日の前後の期間はどの程度であるか。予定されている日付が過去になっている可能性があります。これはバグではなく、意図的で誠実な期限切れのシグナルです。

方法メンバー自身の購入間のギャップを表す瞬間法ガンマ ビュー。
入力チャーン/CLV と同じ収益トランザクション SSOT — メンバーが自分の購入の間に観察したギャップ。
成果とその着地点next_order_expected_at (過去のことかもしれない=期限切れ) next_order_window_days (±サンプル標準偏差、最低1日)
正直ゲート観察されたギャップが 3 つ以上、変動係数が 1.5 以下(不規則なリズムは拒否され、推測されない)、平均ギャップが 0.25 日以上 - それ以外の場合は NULL。
消費面プロフィールタイルと days_until_expected_order セグメント条件(負の値は期限切れを意味します。補充対象オーディエンスは「-14~3」です)。

3. クリック傾向

各メンバーのP(クリック|送信)を以下のように表現します。 click_propensity 0~100のスケールで評価します。

方法固定スケジュールで決定論的なフルバッチ勾配降下法によってトレーニングされた、過去 90 日間の送信にわたるチームごとの L2 正規化ロジスティック回帰。ラベルはクリックのみです。Apple MPP プリフェッチによってオープンがインフレートされるため、オープンは除外されます。リーク ガードにより、各トレーニング送信の事前クリック率機能がその送信自体の結果を確実に除外し、1 つの共有機能ビルダーがトレーニングとスコアリングの両方に対応するため、トレーニング行とスコアリング行が乖離することはありません。
入力チーム自身の過去 90 日間の送信結果。
成果とその着地点click_propensity (0~100) プラス propensity_computed_at.
正直ゲートチーム フィット ゲート: 送信数 500 件以上、クリック数 30 件以上、個別メンバー 50 人以上。メンバーゲート: 最近の送信が 3 件以上 — それ以外の場合は NULL。
消費面プロフィールタイルと click_propensity セグメント条件。

4. 送信するのに最適な時間帯

各メンバーのローカル タイムゾーンでの推奨エンゲージメント時間と、送信全体に対する視聴者レベルの推奨時間。

方法メンバーのローカル タイムゾーンでの、90 日間にわたるメンバーごとのエンゲージメント時間ヒストグラム: 非プロキシ オープンの 3 倍で重み付けされたクリック数、ボットは除外され、Apple MPP プロキシ オープンは削除されました。推奨される時間は円形平滑モードです (23 時間と 0 時間は隣接しています)。
入力メンバーの現地タイムゾーンにマッピングされた、メンバー自身のエンゲージメント イベントの 90 日間。
成果とその着地点preferred_send_hour (0~23歳、地域限定) プラス send_timing_sample視聴者推奨は、視聴者が希望する時間帯における最頻値であり、カバレッジカウントとともに報告されます。
正直ゲート資格のあるエンゲージメント履歴のないメンバーには、希望する時間はありません。自動適用が信号を検出しない場合、呼び出し側が設定した時間を維持します。送信を黙って遅らせることはありません。
消費面スケジュールステップカード、 preferred_send_hour セグメント条件を設定し、送信API経由で自動適用します(optimizeSendTime) は、推奨時間帯の次回の訪問をスケジュールします。

5. A/Bトラフィックの自動最適化

ライブ クリック パフォーマンスから、定期的なキャンペーンのテスト バリアントにわたる時間ごとの配信ウェイトの割り当て。

方法ライブごとのバリアント クリックに対する決定論的アロケーター: ラプラス平滑化事後平均 CTR が温度まで上昇し、アームごとの探索下限の 10% を超えて正規化されます。統計的な勝者を宣言することは決してありません。それは、別個の正式な A/B 評決のままです。
入力キャンペーンのバリアントごとのライブ配信とクリック数。
成果とその着地点最新の割り当ては送信時に上書きされます。設定された分割は決して変更されません。1時間ごとの再計算で、1行が追加されます。 bandit_allocations 適用された重みと人間が理解できる根拠を含む意思決定ログ。
正直ゲート定期的なキャンペーンのみ (オートメーション/ジャーニー)、キャンペーンごとにオプトイン。各アームで 100 回以上の配信が行われるまで、トラフィックは均等に分割されたままになります。シン データでは再割り当ては行われません。
消費面オプトイン済みの定期キャンペーンにおける送信時加重オーバーレイ、追記専用 bandit_allocations ログは監査の場です。

6. ウィンバックの上昇

回収エージェントは、どのリスクにさらされているメンバーを最初に働かなければなりません。リスクにさらされている価値観だけでなく、説得力を意識したランクです。

方法プログラム独自のランダム化ホールドアウト実験における 2 モデルのロジスティック上昇率: uplift(x) = P(convert | treated, x) − P(convert |holdout, x)。メンバーごとのアームは不変です。アトリビューション ウィンドウでのコンバージョン = ≥1 オーダー。
入力成熟した winback_attribution 行。機能が存在する場合は、タスクのエンキュー時のスナップショットから取得されます。存在しない場合は、現在のロールアップ(概算値)から取得されます。
成果とその着地点ワークリストのランクキーは、リスク値×アップリフトです。マイナスのアップリフト(応答不可)は最下位になり、優先度は0になります。 task.reason 完全な計算式を網羅しています。
正直ゲート成熟した処理行が 200 行以上、成熟したホールドアウト行が 50 行以上、コンバージョンが 20 回以上、両方の近似が収束する必要があります。そうでない場合、ランキングは純粋なバリュー アット リスクのままになります。
消費面SoClaw ウィンバック ワークリストの順序付け — エージェントがタスクを要求するランク付けされたキュー。

ワークリスト自体 (タスク、レバー、完了の要求) は、SoClaw Win-Back 統合ガイド に記載されています。

7. アイテムの類似性 (アイテム-kNN)

「これも購入しています」製品間の類似性。

方法コサイン正規化共起率でスコアリングされた夜間の共同購入実現状況: co_count / sqrt(buyers(A) × buyers(B)) — 正規化によって人気バイアスが補正されます。生の co_count 検証可能な証拠として、列として保持されます。
入力テナント自身の共同購入履歴 - 誰が何を一緒に購入したか。
成果とその着地点実体化された項目ペアの類似性スコア。生の共起数が各スコアとともに保存されます。
正直ゲートペアが成立するには、2 人以上の共有購入者が必要です。薄いケースやコールドケースは、カテゴリーのトップセラーに戻り、次に世界のトップセラーに戻ります。コールドメンバーにはランダムな製品が与えられるだけで何も得られません。
消費面メールによるおすすめブロック、会員ポータル、および公開版+v2のおすすめAPI。

8. 協会規則

「A の購入者は B も購入する」という形式のクロスセル ルールで、サポート、信頼、リフトを提供します。

方法毎晩マイニングされる注文レベルの製品ペア。しきい値: ≥3 ペアオーダーおよび ≥5% の信頼度。先行件ごとの上位 25 のルールが保持され、リフトごとにランク付けされます。
入力販売者自身の注文明細。
成果とその着地点catalog_association_rules サポート/信頼度/リフト値と、それらの算出元となる生データ(ペア、先行、後続のオーダー数)を含む行データ。つまり、すべての指標は手動で再計算可能です。
正直ゲート≥3 ペア順序および ≥5% の信頼度 — それ未満では、ルールは存在しません。
消費面プロファイルのクロスセル アクション カード - アクティブな購入者のみ。既に所有している製品は除外されます。

9. 類似点

ベースの各メンバーがシード オーディエンスとどの程度似ているかと、その理由をメンバーごとに内訳します。

方法シード → Rocchio セントロイド: IDF 加重タグ コサイン類似度 + Gower 正規化数値距離 (RFM、購入数、最新性)、さらにシードにデータ (値層の一致、プライマリ カテゴリの一致、チャーン見通しの近接性) がある場合のプロファイルの融合。重みは実際に存在するディメンションで再正規化されるため、プロファイル データのないシードはタグ + 数値層に正確に低下します。
入力シード メンバーのタグ、数値動作 (RFM、購入数、最新性)、およびプロファイル フィールドが、テナント独自のメンバー ベースと照合されました。
成果とその着地点メンバーごとの類似性スコアと、「なぜ似ているのか」の概要を強化するディメンションごとの内訳。
正直ゲート小さなシードには、自信のあるスコアではなく、縮小に加えて明示的な警告が表示されます。
消費面似たものを見つける視聴者の流れ。インベースのみ — 類似商品が広告プラットフォームにアップロードされることはありません。

10. 外れ値の不正行為検出器

メンバーの 30 日間のポイント アクティビティが、チーム自体のメンバー分布に対して統計的に極端な外れ値であるかどうか。

方法30 日間のポイント アクティビティにわたるチームごとの堅牢な統計 – トランザクション数の獲得、獲得ポイント、レジャーの引き換え – 機能ごとの中央値 + MAD、堅牢な z = 0.6745 × (x − 中央値) / MAD、z ≥ 6 かつ ≥10 でフラグを立ててトランザクションを獲得。
入力メンバーごとに 30 日間のチーム独自のポイント アクティビティ。
成果とその着地点会員のポイント凍結に加え、 fraud_points_hold レビュータスク。フラグはレビューのためにポイントを固定するだけで、それ自体で無効になることはありません。ペイロードが機能ごとの値/中央値/ロバストz値を含む理由はここにあります。
正直ゲートアクティブなメンバーが 50 人未満のチームは完全にスキップされます (意味のあるベースラインはありません)。 MAD = 0 のフィーチャはスキップされます。すでに凍結されたメンバーが重ねられることはありません。重複除去は月単位で行われます。
消費面ポイント不正審査ワークリスト。

この検出器が供給する凍結後判定パイプライン (保留、判定セマンティクス、管理制御) については、Points Fraud Protection ガイド に記載されています。

11. 保持期間 (KM + Cox)

月次サインアップコホートごとの維持曲線、およびどのメンバー属性が維持と相関しているか。

方法月間登録コホートごとのカプラン・マイヤー曲線;解約イベントは、90日間購入がない場合(解約期間=最終購入日+90日)と定義され、最近購入した顧客は右側打ち切り、購入経験のない顧客は除外されます。ブレスロー部分尤度法によるコックス比例ハザードモデルを用い、同じ決定論的ネルダー・ミード法で最大化します。
入力テナント自身のサインアップおよび購入履歴。
成果とその着地点コホート生存曲線とコックスハザード比は平易な文章として表示され、0.95 と 1.05 の間の比は「有意差なし」として報告され、すべてが因果関係ではなく相関関係とラベル付けされました。
正直ゲートコホートには 30 人以上のメンバーが必要です。曲線は、コホートの観察範囲を超えて外挿されることはありません。 Cox フィットの上限は 3 共変量で、30 以上のイベントが必要で、収束しない場合は null を返します。
消費面保持コホート ビューとその相関パネル。

12. 収益見通し (Holt-Winters)

正直な誤差範囲を含む 14 日間の日次収益予測。

方法毎週の季節性 m = 7 および固定定数 α = 0.3、β = 0.05、γ = 0.3 による加法三重指数平滑法 - 自己調整は意図的な非目標であり、最初の 2 つの季節から決定論的に初期化されます。
入力毎日の GMV は、認定されたメトリクスのセマンティック レイヤーを介して読み取られます (2 番目の集計はありません)。欠落日は $0 に密度が濃くなります。最初の販売前のゼロはトリミングされます。
成果とその着地点14日間の予測値(0以上を上限とする)で、バンド幅はサンプル内平均絶対1ステップ誤差×1.5(明示された基準であり、分布信頼区間ではない)。
正直ゲート28 日以上の非ゼロ履歴 — それ以外の場合は null となり、何もレンダリングされません。
消費面ダッシュボードの収益見通し。

スコアを消費する

メンバー レベルのスコアはロールアップ列として表示され、リーチの増加順に 4 つのサーフェスを通って外側に流れます。

  • ロールアップ列。 夜間の再調整により、メンバーごとのスコア (churn_risk、predicted_clv_12m、click_propensity、preferred_send_hour、next_order_expected_at …) がメンバーの動作ロールアップに書き込まれます (ゲートが満たされなかった場合は NULL)。
  • セグメント条件。 スコアをターゲットとする 6 つの予測条件: churn_risk、predicted_clv_12m、preferred_send_hour、click_propensity、days_until_expected_order、およびタグ。スコアが NULL のメンバーは決して一致しません。セグメントは正直ゲートを継承します。
  • メンバー プロフィール API / インサイト ペイロード。 同じスコアがメンバー プロフィールの読み取り画面に送信されるため、インテグレーターが読み取る内容は、プロフィール ページに表示される内容とまったく同じです。
  • MCP エージェント用。 AI エージェントは、管理された MCP サーバー上の get_member_profile を通じてスコアを読み取ります。同じデータ、同じスコープとガバナンスのもとで行われます。

これらの機能のビジネス向けのストーリーについては、「予測インテリジェンス」を参照してください。すべてのモデルが背後で動作する承認ギア、意思決定ログ、PII マスキングについては、AI ガバナンス: イントロスペクションと承認を参照してください。