定期キャンペーンのスケジュール設定
再発予定のセンチメントキャンペーンの設定で重要な点の一つは、従業員の返答意欲を過剰に使用せず、バランスの取れた一貫性のあるデータサンプリングを保証する最適化された頻度で従業員をターゲットにすることです。
再発予定のキャンペーンは、キャンペーンを編集ページのスケジュールタブの再度後にオプションを使用して設定されるスケジュールされたキャンペーンです。 公開後、キャンペーンは毎時間自動的にNQLクエリを再評価し、クエリが実行されるたびに従業員をターゲットとして指定します。
このページでは、正しいNQLクエリを構築し、適切なキャンペーンプロパティを設定する手順を説明します。
適切なユーザーをターゲットにする
バランスの取れたサンプルサイズを維持する
従業員が調査されるタイミングを最適化する
キャンペーンの設定
キャンペーンを作成すると、トリガーメソッドをスケジュールに設定します。
ユーザーをターゲットにするためのNQLクエリの入力
キャンペーン設定ページのスケジュールタブでターゲットクエリを入力する前に、キャンペーンを少なくとも1回保存してください。 これは、NQLクエリ検証中に「テーブルが存在しない」エラーを避けるため、システムがキャンペーンを認識することを保証します。
以下の手順では、キャンペーン用にターゲットユーザーを識別するクエリを構築する方法を説明します。
アクティブな従業員をターゲットにする
クエリを
usersテーブルで開始します。session.eventsを追加して、非アクティブなユーザーアカウントを削除し、デバイスタイプや特定のイベント属性など、usersネームスペースで利用できないフィールドに基づいて追加のフィルターを適用できるようにします。
users
| with session.events during past 30d
| where device.hardware.type in [laptop, desktop, virtual]
...特定のユーザーを除外する
最適な基準はあなたの環境とEntra-ID統合に依存します。
非人間ユーザーを除外
クエリから非人間ユーザーを除外します。 非人間ユーザーを識別し除外するための最良の方法は環境によって異なります。
...
| where user.name !in ["*localadmin*"]
| where user.name !in ["*datadog*", "*newrelic*"]
| where user.name !in ["*testing*"]
| where user.upn != null
| where user.upn in ["*@mycompany.com", "*@ext.mycompany.com"]
| where user.ad.email_address != null
...調査したくないユーザーを除外する
VIPユーザー、特定の国のユーザー、または特定の役割を持つユーザーなど、調査すべきでないユーザーを除外します。
以下の例を考慮してください:
...
| where user.name !in ["*datadog*", "*newrelic*"]
| where user.ad.distinguished_name !in ["*any_substring*", "*any_substring*"]
| where user.ad.country_code !in ["DE", "FR"]
| where user.ad.department !in ["Facility Management", "Legal"]
| where user.ad.job_title !in ["C?O", "*Director*", "VP"]
| where #custom_field_isVIP != "yes"
...集団の人数を決定する
クエリを実行してターゲットにできる従業員の総数、つまり_集団の人数_を決定します。
クエリが返すユーザーの数は、あなたの集団の人数を示し、適切なキャンペーンサンプリングと頻度を計算するのに必要不可欠です。
期間を調整する
集団の人数を決定する際、長い期間を使用して、休暇中や病欠中の従業員を含めることができます。 実際のターゲティングには、活動中で即座に対応できる従業員に焦点を当てるために、より短い期間を使用します。
デバイス上で過去7日間に少なくとも1つのアクションを実行したものにデータセットを絞り込みます。
過去 7 日間のユーザー
| 過去 7 日間の session.events も使用
...ユーザーが既にどの程度回答しているかを計算する
campaign.responsesテーブルに参加し、今年中に各ユーザーがすでにキャンペーンを受け取った回数を計算します。 campaign.nql_idを編集キャンペーンページの一般タブにあるNQL IDに調整します。
| 過去 365 日間の campaign.responses も含める
| campaign.nql_id == "YOUR_CAMPAIGN_ID"
| campaign.response.state in [targeted, answered, declined]
| compute times_targeted_past_365d = count() 可視性のためのフィールドを一覧表示
このクエリを調査として実行し、結果を確認するための情報をユーザーについてオプションで出力します。
クエリにlist句を含める場合、SIDフィールドは必須です。
| 過去365日間にターゲットにされた回数、sid、uid、名前、タイプ、upn、user.ad.full_name、user.ad.email_address、user.ad.job_title、ad.office、user.ad.department、ad.city、ad.country_code、ad.organizatitional_unit、first_seen、ad.distinguished_name を一覧表示キャンペーンの回答数で並べ替え
各従業員がキャンペーンに回答した回数で結果を並べ替えて、回答が最も少ない人々を上位に表示します。 これにより、他の誰かが2回目の調査を受ける前に、その人たちが調査を受けることができます。
| sort times_targeted_past_365d asc 結果をランダム化
結果のリストをUIDでソートして擬似ランダム化します。
UIDでのソートは、キャンペーン応答数でのソートが行われた後で、最終的に行う必要があります。
| sort uid asc 毎時間ターゲットにできるユーザー数を制限する
毎時間ターゲットにできるユーザー数を決定し、この値をクエリの最後の| limit句に含めます。
| limit <毎時間ターゲットとするユーザー数>各クエリ実行時にターゲットとするユーザー数は以下に依存します:
Step 3で計算した集団の人数。
各ユーザーを1年間にターゲットにできる回数。 後者はこのページのユーザーが再度ターゲットにされるまでの期間を設定するセクションで詳しく説明されています。
また、クエリが年間を通じて実行される回数からもたらされます。 設計上、再発予定のキャンペーンは毎時間NQLクエリを実行し、返されたユーザーをターゲットとします。つまり年間で8760回実行されます:
従業員数が10,000人以上の場合の人口サイズ
人口が10,000人を超える場合、クエリ実行ごとにターゲットとするユーザーの数を決定するために以下の式を使用します。
マージンを確保し、365日間の期間の終わりまでにターゲットにできるユーザーが枯渇しないようにするため、結果を次の小さい整数に切り下げた数をキャンペーンNQLクエリの最後にある| limit句の値として使用します。
例
人口20,000人の組織で、DEXキャンペーンを使用可能な従業員が20,000人存在し、各従業員は365日ごとに一度だけターゲットにされます。
この結果に基づいて、目標設定クエリの| limit 2とすることで、毎時間2人のユーザーをターゲットとすべきです。
従業員数が10,000人未満の場合の人口サイズ
集団が10,000人未満である場合、Nexthinkは毎時間1人のユーザーをターゲットとすることをお勧めします。 この方法により、従業員がキャンペーンを受信する頻度を最適化し、調査可能な回答者プールの枯渇を防ぐことができます。
キャンペーンが単一の従業員に送信される頻度をさらに調整する必要があります。 このページの#ユーザーが再度ターゲットにされるまでの期間を設定するセクションを参照してください。
最終的なクエリは以下の例のようになります。 コピーして、プレースホルダをデータで置き換え、センチメントキャンペーンの定義に挿入してください。
過去7日間のユーザー
| 過去7日間のsession.eventsも使用
| device.hardware.type in [laptop, desktop] の場合
| <非人間ユーザーを除外する条件>
| <特定のユーザーを除外する条件>
| 過去365日間の campaign.responses を含める
| campaign.nql_id == "<YOUR_CAMPAIGN_ID> " の場合
| campaign.response.state in [targeted, answered, declined] の場合
| compute times_targeted_past_365d = count()
| 過去365日間にターゲットにされた回数、sid、uid、名前、タイプ、upn、user.ad.full_name、user.ad.email_address、user.ad.job_title、ad.office、user.ad.department、ad.city、ad.country_code、ad.organizatitional_unit、first_seen、ad.distinguished_name を一覧表示
| sort times_targeted_past_365d asc
| sort uid asc
| limit <毎時間ターゲットにするユーザー数>ユーザーが再度ターゲットにされるまでの期間を設定する
キャンペーンを再発にするには、スケジュールタブに移動し、ターゲット従業員がキャンペーンを受信するを再度後にに設定して、希望する間隔を指定します。
従業員へのセンチメントキャンペーンの送信頻度は、集団の人数に依存します。
10,000人以上の従業員の集団サイズ
大規模な組織に対して、Nexthinkは各ユーザーを年間に1回以上はターゲットにしないことを出発点として推奨しています。 各ユーザーが1年に1回以上ターゲットされないようにするために、12ヶ月に再度の後という間隔を設定します。
10,000人未満の集団
10,000人未満の従業員を持つ小規模な組織では、持続的なデータ収集を保証するために、ユーザーのターゲット頻度を増やす必要が通常あります。 その場合は、同じユーザーを再度ターゲットにするまでの期間を計算する必要があります。 これを保つことで:
回答者が尽きることはありません。
従業員がキャンペーンをあまり頻繁に受け取らないようにします。
あなたのクエリが1時間ごとに1ユーザーをターゲットにする(ステップ 9: 各時間ごとにターゲットにできるユーザー数を制限する で説明されています)と仮定する場合、以下の式を使用して月数を計算します:
_24時間_および_30日_で_集団の人数_を割ってください(平均):
再度後にの間隔を公式から得た数以下の月数に設定します。
例:
以前に紹介された例を考えると、6000人の従業員を持つ組織が1時間ごとに1人の従業員をターゲットにします。
8.3ヶ月後には、すべての従業員がターゲットにされます。 データ収集にギャップが生じないようにするためには、再度後にの間隔を8ヶ月またはそれ以下に設定してください。
再度後にの値に基づいてターゲットに許可されたユーザー数を、NQLクエリでターゲット数に対して多くしないようにしてください:
この条件が満たされない場合、システムは年内に適格な回答者が不足する可能性があり、結果として感情データがほとんど収集されない期間が発生します。
データの中断を防ぐために、次のオプションを検討してください:
毎時間ターゲットにするユーザー数を減らす。
各ユーザーに年間でコンタクトできる回数を増やす。
すべての設定をスケジュールタブで完了したら、キャンペーンを保存および公開して、毎時間のユーザーターゲットを有効にします。
Last updated
Was this helpful?