Rule Engine（ルールエンジン）はGainsightの頭脳とも言える機能です。

Gainsightのアドミンの皆様にとって、Rule Engineはよくご利用いただく機能ですが、使いこなすまでに時間がかかったり、運用/管理も少々煩雑になりがちな機能でもあります。

そこで、今回はRule Engineの運用管理におけるベストプラクティスをご紹介します💫

（ルールの設定内容自体は、皆様の会社で保有しているデータの種類や、ルールの目的によって異なってきますので、細かいルールの設定内容というよりもルールを管理する上での汎用的なベストプラクティスをご紹介できればと思います。）

まずは「命名規則」編です。

シンプルな決まり事でありながら、意外と社内でルールが決まっていなかったりすることも多いようです。

ルールの命名規則を決めないまま、ルールが量産されてしまい、後からルール名を変更しようと思っても、もう手がつけられない状態に・・・😭とならないために、ぜひ今から始めておきましょう！

皆様の会社ではルールエンジンを設定する際のルール名に「命名規則」を決めていますか？

もしくは、各自で自由にルール名を設定していませんか？

ルール名に一貫性がないと、アドミンの方が何かしらルールを変更したり、不要なルールを削除したいといった場合に、ルール名からは、これが一体何のルールか判別できず、ルール詳細画面に入って、設定内容の詳細を調べないといけない😱・・・なんてことにもなってしまいますよね。

では、ルールエンジンの命名規則はどのようにしたらよいのでしょうか？

命名規則を定める目的は「一貫性があり、読みやすく、十分に理解しやすい命名ルールを標準化する」ためです。

ルールを作成する際には、常に何らかの命名規則に沿って名付けることをお勧めしています。

ルールの名前では、操作の種類とデータソースを説明することをお勧めします。

では早速、ルール名に含めた方が良い要素と、ルール名の例（英語表記・日本語表記）でご紹介します。

MDA/SFDCにデータを読み込むルール

Customer, Usage, Company, User, Company Personなどの標準オブジェクトにデータをロードすることが含まれるルールの場合。

• <<アクション名>>: <<操作内容>> - <<対象オブジェクト>>
• 例：Load to Gainsight: Load WoW Usage Data - Usage Metrics
• 例：Gainsightへのロード: 週次の使用状況データの読み込み - 使用状況指標

スコアを設定するためのルール

• <<Set Score>>: <<メジャー名>> - <<スコアカード名>>
• 例：Set Score: NPS® - Account Scorecard
• 例：スコア設定: NPS® - アカウントスコアカード

CTAを作成するためのルール

• <<CTA>>: <<理由>>
• 例：CTA: Drop-in Adoption Score
• 例：CTA: アダプションスコアの減少

Relationshipにデータを読み込むルール

• リレーションシップへのロード: <<Relationship名>> - 操作内容
• 例：Load to Relationship: Retailer - Create and Update
• 例：リレーションシップへのロード: 小売業者 - 作成と更新

Relationshipのルール

• <<リレーションシップタイプ>>: <<アクション名>> - <<操作/理由>>
• 例：Retailer: Call to Action - Detractor NPS® Score
• 例：小売業者: CTA - NPSスコア中傷者

その他のルール（機能への負荷、マイルストーン、サクセスプラン等）

• <<アクション名>>: <<機能/マイルストーン/サクセスプラン名>>
• 例：Load to Milestone: EBR completed 
• 例：マイルストーンへのロード: EBR完了

注：ルールが異なるアクションで構成されている場合や、複数のオブジェクトにデータを書き込む場合は、アクション名とターゲットオブジェクト名を「/」で区切ってください。最終的な名前が長くなる場合は、一般的な名前を付け、説明欄で詳細を説明しましょう。

では次に、Rule Engineの設定の中で複数のタスクを作成しますが、それらのタスクはどのように命名したらよいでしょうか？

タスクの名前においても、操作の種類とデータソースを説明することをお勧めします。以下は、推奨事項とその例です。

データセット

• Fetch << 基準>> <<オブジェクト名»
• 例：Fetch 120 days of data from Usage Data
• 例：使用状況データから120日分のデータを取得する
• 例：Fetch Closed Won Opportunities
• 例：受注商談のデータを取得する

マージタスク

• Merge << Dataset1 >> <<Dataset 2>> - <<結合タイプの短縮名>>
• 例：Merge Account Opportunity - EQ
• 例：アカウントと商談を結合 - EQ

• マージタスクにおける「結合タイプ (Join Type)」の短縮名

  • マージタスクで結合タイプ（Join Type）を選択しますが、全部をタスク名に入れると長くなってしまうので下記のような短縮名を利用するのがおすすめです。

    • 両方のデータセットから共通のレコードを保持する： EQ

    • 左のデータセットからすべてのレコードを保持する：LF

    • 右のデータセットからすべてのレコードを保持する：RT

    • 両方のデータセットからすべてのレコードを保持する：FL

トランスフォーメーションタスク

• <<操作タイプ/ フィルター基準>>
• 例：Calculate Weekly Usage
• 例：週次の使用状況を計算
• 例：Filter Accounts without Usage
• 例：使用量に関わらずアカウントを絞り込む

ピボットタスク

• <<Pivot Fieldname>>
• 例：Pivot Eventname
• 例：イベント名でピボット

S3データセットタスク

• S3<<Filename>>
• 例：S3 Usage_YYYY_MM_DD.csv
• 例：S3使用状況_YYYY_MM_DD.csv

注：タスクの名前は、数字から始まるものでないこと。

ルールのDescription（詳細）欄を活用しましょう！

ルールの詳細欄は空欄のままにして言いませんか？

詳細欄にはルールやオブジェクトの説明を記述することを義務付けましょう。詳細欄に説明があれば、ルールや各タスクの目的を理解するのに役立ち、ルールのロジックを把握しやすくなります（ルールの設定内容の中身をいちいち確認しなくて済みます）。

もし、ルール内で複数のアクションが実行されている場合は、詳細を明記しましょう。

予約語 (Reserved keywords) に気をつけましょう！

ルール名には、以下の文字を使用しないでください。これらの文字は、検索機能の妨げになります。
^,*,(,),[,], |,等... 

シーケンスでルールに番号を付けましょう！

特定のルールセットを特定の順序で実行する必要がある場合、実行順序を理解しやすくするために、ルールに番号を付けることをお勧めします。

例：

• Load to Gainsight: Load Events into Usage Day Agg - 1.0
• Load to Gainsight: Load Events dayagg into Usage Metrics - 2.1
• Load to Gainsight: Load Events dayagg into Usage Metrics - 2.2

以上、ご参考になりましたら幸いです😊