# キャンペーンの定期スケジュール化

定期的なセンチメントキャンペーンの構成における重要な側面の1つは、最適化された頻度で従業員をターゲットにすることです。これにより、従業員の回答意欲を損なうことなく、バランスの取れた一貫したデータサンプリングが行えます。

**定期的なキャンペーン**とは、[キャンペーン編集](https://docs.nexthink.com/platform/ja/user-guide/campaigns/managing-campaigns/creating-campaigns/..#accessing-campaign-edit-page)ページの**スケジュール**タブの**再度実行**オプションで設定されたキャンペーンです。 公開されると、キャンペーンは毎時間NQLクエリを自動的に再評価し、クエリが実行されるたびに従業員をターゲットにします。

このページでは、正しいNQLクエリを作成し、適切なキャンペーンプロパティを設定するプロセスを案内します。

* 適切なユーザーをターゲットにする
* サンプルサイズをバランスよく維持する
* 従業員が調査されるタイミングを最適化する

## キャンペーンの設定

[キャンペーンを作成](https://docs.nexthink.com/platform/ja/user-guide/campaigns/managing-campaigns/creating-campaigns)し、**トリガー**方法を**スケジュール**に設定します。

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-7ec0b42f65f5fb9b52f4df8ba4a54b13ecf23770%2Fimage%20(867).png?alt=media" alt=""><figcaption></figcaption></figure>

## ユーザーをターゲットにするためのNQLクエリの入力

キャンペーン構成ページの**スケジュール**タブで**ターゲティングクエリ**を入力する前に、少なくとも1回キャンペーンを保存してください。 これにより、システムがキャンペーンを認識し、NQLクエリの検証中に 「テーブルが存在しません」というエラーを回避できます。

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-eb02c7057bd6af376aebb8e2c10ea312a6a51e46%2Fimage%20(870).png?alt=media" alt=""><figcaption></figcaption></figure>

以下は、キャンペーンのターゲットユーザーを特定するためのクエリの作成手順です。

{% stepper %}
{% step %}
**アクティブな従業員をターゲットにする**

* クエリの開始を`users`テーブルにします。
* `session.events`を追加して、非アクティブなユーザーアカウントを削除し、デバイスタイプや特定のイベント属性などユーザーのネームスペースでは利用できないフィールドに基づいて追加のフィルタを適用できるようにします。

{% code overflow="wrap" lineNumbers="true" %}

```
users
| 前30日間の session.events を使用
| device.hardware.type が [laptop, desktop, virtual] に含まれる
...
```

{% endcode %}
{% endstep %}

{% step %}
**特定のユーザーを除外する**

最適な基準は、環境とEntra-ID統合に依存します。

**非人間ユーザーを除外する**

非人間ユーザーをクエリから除外します。 非人間ユーザーを特定して除外するための最適な方法は環境によって異なります。

{% code overflow="wrap" lineNumbers="true" %}

```
...
| user.name が ["*localadmin*"] に含まれない
| user.name が ["*datadog*", "*newrelic*"] に含まれない
| user.name が ["*testing*"] に含まれない
| user.upn が null ではない
| user.upn が ["*@mycompany.com", "*@ext.mycompany.com"] に含まれる
| user.ad.email_address が null ではない
...
```

{% endcode %}

**調査しないユーザーを除外する**

VIP、特定の国のユーザー、特定の役職を持つユーザーなど、調査しないべきユーザーを除外します。

以下の例を考慮してください：

{% code overflow="wrap" lineNumbers="true" %}

```
...
| user.name が ["*datadog*", "*newrelic*"] に含まれない
| user.ad.distinguished_name が ["*any_substring*", "*any_substring*"] に含まれない
| user.ad.country_code が ["DE", "FR"] に含まれない
| user.ad.department が ["Facility Management", "Legal"] に含まれない
| user.ad.job_title が ["C?O", "*Director*", "VP"] に含まれない
| #custom_field_isVIP が "yes" ではない
...
```

{% endcode %}
{% endstep %}

{% step %}
**対象人口の規模を決定する**

対象人口（ターゲットとすることができる従業員の総数）を決定するために、クエリを実行します。

{% hint style="success" %}
クエリが返すユーザーの数は、人口の規模を示し、適切なキャンペーンサンプリングと頻度を計算するための重要な指標です。
{% endhint %}
{% endstep %}

{% step %}
**時間枠を調整する**

人口の規模を決定する際には、休暇中や病欠中の従業員を含めるために期間を長めに設定します。 実際のターゲティングでは、より短い期間を使用して、タイムリーに回答できるアクティブな従業員に焦点を当てます。

デバイス上で過去7日間に少なくとも1つのアクションを行ったユーザーにデータセットを絞ります。

<pre><code><strong>過去7日間のユーザー
</strong>| セッション.イベント 過去7日間
...
</code></pre>

{% endstep %}

{% step %}
**ユーザーが既に何回応答したかを計算する**

`campaign.responses` テーブルを結合し、今年既に各ユーザーがキャンペーンを受け取った回数を計算します。 キャンペーンの **編集** ページの **一般** タブで `campaign.nql_id` をNQL IDに調整します。

```
| include campaign.responses 過去365日 
| where campaign.nql_id == "YOUR_CAMPAIGN_ID" 
| where campaign.response.state in [targeted, answered, declined] 
| compute times_targeted_past_365d = count() 
```

{% endstep %}

{% step %}
**視認性のためのフィールドを列挙**

ユーザーに関する情報を出力するオプションがあります。結果を確認するためにこのクエリを調査として実行したい場合に備えてください。

{% hint style="warning" %}
クエリに `list` 条項を含める場合、`SID` フィールドは必須です。
{% endhint %}

{% code overflow="wrap" lineNumbers="true" %}

```
| list times_targeted_past_365d, sid, uid, name, type, upn, user.ad.full_name, user.ad.email_address, user.ad.job_title, ad.office, user.ad.department, ad.city, ad.country_code, ad.organizational_unit, first_seen, ad.distinguished_name 
```

{% endcode %}
{% endstep %}

{% step %}
**キャンペーン応答の数で並べ替える**

各従業員がキャンペーンに応答した回数で結果を並べ替えて、最も応答が少ない人を目立たせます。 これにより、他の人が2回目を取得する前に調査を受け取ることが保証されます。

```
| sort times_targeted_past_365d asc 
```

{% endstep %}

{% step %}
**結果をランダム化する**

UIDで並べ替えて、結果のリストを疑似ランダム化します。

{% hint style="warning" %}
UIDによる並べ替えは、キャンペーン応答の数での並べ替えの後に最後に行う必要があります。
{% endhint %}

```
| sort uid asc 
```

{% endstep %}

{% step %}
**1時間ごとにターゲットとするユーザーの数に制限**

毎時ターゲットとできるユーザー数を決定し、この値をクエリの最後の `| limit` 条項に含めます。

```
| limit <1時間ごとにターゲットとするユーザー数>
```

各クエリ実行時にターゲットとするユーザー数は以下に依存します：

* あなたが計算した [ステップ3](#determine-the-size-of-your-population) での人口数。
* 各ユーザーを年にターゲットとできる回数。 [ユーザーを再ターゲットできるまでの期間を設定](#set-the-period-after-which-users-may-be-targeted-again) セクションで、詳細に説明されています。

または、クエリが1年間に実行される回数の結果です。 基本的に、反復キャンペーンはNQLクエリを実行し、毎時、つまり年8760回でユーザーをターゲットにします：

$$
365 ,\text{days} \times 24 ,\text{hours} = 8760
$$

**人口が10,000人以上の企業**

人口が10,000人以上の場合、各クエリ実行ごとにターゲットとするユーザー数を決定するために次の式を使用してください。

$$
\text{1時間ごとにターゲットとするユーザー数} = \frac{\text{人口} \times \text{年にターゲットとされる回数}}{8760}
$$

マージンを保持し、365日の期間が終了する前にターゲット可能なユーザーが不足することを避けるために、結果を次のより小さい整数に切り捨て、この数を| limit クエリの末尾に挿入します。

**例**

20,000人の従業員がいる組織を考え、各従業員は365日ごとに最大1回ターゲットとされることができます。

$$
\frac{20000}{8760} = 2.28
$$

結果に基づいて、ターゲットクエリの結果を `| limit 2` に制限することで、1時間に2名のユーザーをターゲットとするべきです。

**人口が10,000人未満の企業**

人口が10,000人未満の場合、ネクスシンクは毎時1ユーザーをターゲットとすることをお勧めします。 このアプローチは、キャンペーンの配信を受ける頻度の最適化に役立ち、対象となる回答者のプールが枯渇するのを防ぐものです。

1名の社員へのキャンペーン配信頻度をさらに調整することを確認してください。 このページの[#set-the-period-after-which-users-may-be-targeted-again](#set-the-period-after-which-users-may-be-targeted-again "mention") セクションを参照してください。
{% endstep %}
{% endstepper %}

最終的なクエリは以下の例のようになります。 コピーし、プレースホルダーをデータで置き換え、センチメントキャンペーン定義に挿入します。

{% code overflow="wrap" lineNumbers="true" %}

```
過去7日間のユーザー
| セッション.イベント 過去7日間
| where device.hardware.type in [laptop, desktop]
| where <非人間ユーザーを除外する条件>
| where <特定のユーザーを除外する条件> 
| include campaign.responses 過去365日 
| where campaign.nql_id == "<YOUR_CAMPAIGN_ID> " 
| where campaign.response.state in [targeted, answered, declined] 
| compute times_targeted_past_365d = count() 
| list times_targeted_past_365d, sid, uid, name, type, upn, user.ad.full_name, user.ad.email_address, user.ad.job_title, ad.office, user.ad.department, ad.city, ad.country_code, ad.organizational_unit, first_seen, ad.distinguished_name 
| sort times_targeted_past_365d asc 
| sort uid asc
| limit <毎時ターゲットのユーザー数>
```

{% endcode %}

## ユーザーを再ターゲットできるまでの期間設定

キャンペーンを繰り返す場合、スケジュールタブに移動して **ターゲット従業員がキャンペーンを受け取る** を **再度後** に設定し、希望の間隔を指定します。

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-1b7b27e902eb1b9d3525088d43db0fc6ae18d3cf%2Fimage%20(868).png?alt=media" alt=""><figcaption></figcaption></figure>

従業員にセンチメントキャンペーンを送る頻度は、人口に依存します。

#### **10,000人以上の従業員を持つ人口**

大規模組織の場合、ネクスシンクはユーザーを年に1回以上ターゲットとしないことをお勧めします。 各ユーザーが年1回以上ターゲットされないようにするために、**再度後** 間隔を12か月に設定してください。

{% hint style="info" %}
より頻繁なデータ収集は、それ自体で精度や一貫性を大幅に向上させるわけではありません。 確率論によれば、重要な要素は全体の人口に対する割合ではなく、調査する従業員のサンプルサイズです。 しかし、結果を国または部門ごとにさらにセグメント化する必要がある場合は、十分なサンプルサイズを確保するために頻度の増加をお勧めします。

ユーザーフィードバックの価値を最大化するために、従業員の回答意欲を活用して、新しい分野を探索したり、特定のトピックについてより深い洞察を得たりします。
{% endhint %}

#### **10,000人未満の従業員を持つ人口**

10,000人未満の従業員を持つ小規模な組織は、連続したデータを確保するために、ユーザーをより頻繁にターゲットとする必要があります。 その場合、同じユーザーをターゲットにできる期間を計算する必要があります。 これにより：

* 回答者が不足することを防ぎます。
* 従業員がキャンペーンをあまり頻繁に受け取らないようにします。

クエリが毎時1ユーザーをターゲットにすると仮定して、[#limit-to-the-number-of-users-that-you-can-target-each-hour](#limit-to-the-number-of-users-that-you-can-target-each-hour "mention") で説明されているように、この式を使用して月数を取得します。

* **人口**を平均月の総時間である24時間 × 30日で割ります。

$$
\frac{\text{人口}}{24 ,\text{h} \times 30 ,\text{days}}
$$

得られる数よりも低い月数に **再度後** 間隔を設定してください。

**例:**

以前に紹介した例を考慮します。6000人の従業員を有し、1時間に1人の従業員をターゲットにします。

$$
\frac{6000}{24 ,\text{h} \times 30 ,\text{days}} \approx 8.3
$$

8.3ヶ月後、すべての従業員がターゲットとなります。 収集されるデータにギャップが生じないように、**再度後** 間隔は8ヶ月以下に設定する必要があります。

{% hint style="danger" %}
システムにNQLクエリでターゲット可能なユーザー数が **再度後** 値に基づいて許可されているよりも多いユーザーをターゲットさせないことを確認してください：

$$\text{人口} \times \text{年間ターゲット回数} ;>; \text{1時間ごとにターゲットにされるユーザー数} \times 8760$$

条件が満たされない場合、システムは年末までに回答者が不足し、事実上センチメントデータが収集されない期間が発生する可能性があります。

データの中断を防ぐために、次のオプションを検討してください：

* 毎時ターゲットにされるユーザー数を減らします。
* 各ユーザーが年間に接触可能な回数を増やします。
  {% endhint %}

***

**スケジュール** タブですべての設定が完了したら、キャンペーンを保存して公開し、毎時のユーザーターゲットをアクティブ化します。
