ルールエンジンの処理には様々な内容が含まれるため、一概にこれがベストプラクティスです！というのはないですが、一例をご紹介致します！データの取得

• ルールエンジンでの処理の重さは、もちろんですが処理をするデータの総量に依存します。そのため、極力データソースからのデータ取得の際に必要なデータだけに絞り込む方が良いです。
• また、データの量はレコード数だけではなく項目数にも影響されるため、最終的な項目数も実際に使うものだけに制限する方が処理が軽くなります。
• データの取得元が同じ場合は、複数回同じデータを取るのではなく、一度取得したデータをTransformでフィルタするほうが効率的に進められるようになります。

データの処理

• Transformの処理のステップ数が多い場合、その各ステップの項目数との掛け合わせで処理が重くなっていきます。そのため、すべての項目を集約して大きなテーブルを作るのではなく、アクションなどが異なる場合は細かいモジュールに分けて処理をすることもおすすめです。(並行処理できるものが増えます)
• あまりにも複雑な内容であれば、DWH側などで事前に処理をしてしまい、CTAの発火基準やスコアのしきい値など、変更が多く発生する部分だけをGainsight側で処理をすることも選択しの一つです。

データのアクション

• アクションについても、一つのアクションで全ての行を処理させようとすると、Transformなどを含めて重くなるケースがあるため、最後に全ての行をユニオンしてアクションを作るのではなく、個別に複数アクションを作成するというのも内容によっては処理が軽くなることがあります。
• あまりにも対象行数が多くなってしまうケースがあれば、ルール自体を分割してしまうことも考えられます。CTAの発行頻度の設定や、重複処理がおきてしまっても問題ないもの(スコア計算など)であればルールをクローンして、対象となるレコードをそれぞれで分ける(セグメントや顧客IDの番号など)ことで1つあたりのルールの処理を減らすこともできます。
   

上記のような内容をご検討ください！