検証コントロールグループに対するサンプリング

オファーの有効性を判断するために、そのオファーに割り当てるセルに対して検証コントロールグループを作成できます。 検証コントロールグループは、オファーを受信しても、ターゲットセルではこれが抑制されるように意図的に選択されている非コンタクトグループです。これは、「リフト」や、オファーを受信したターゲットセルからのレスポンスの違いを比較することを目的とします。

コントロールはセルレベルで適用されます。 フローチャート内のコンタクトプロセスで、またはターゲットセルスブレットシートからオファーをセルに割り当てる際に、各ターゲットセルのコントロールセルとして動作する1つ以上のセルを任意で指定できます。

別のセルのコントロールとしてセルを指定する方法の詳細については、『 IBM Unica Campaignユーザガイド』を参照してください。

検証コントロールグループを作成する場合、フローチャート内のサンプルプロセスに含める必要があります。

ここでは、検証コントロールグループに対してサンプルリングを行うときの2つの方法について説明します。

オーディエンスIDレベルでのサンプリング。

これは、検証コントロールグループに対するサンプリングの最善策で、Campaignでコントロールセルが使用される方法と一致しています。 この場合、コントロールセルはオファー-オーディエンスIDレベルではなく、オーディエンスIDレベルになります。 以下の制限があります。

コントロールセルのコンタクトメンバはオファーを受信しません。 あるコンタクトのオファーがフローチャートでの処理を抑制されます。 複数のフローチャート間において、同じコンタクトが常にコントロールセルで選択されるわけではないので、ある特定のコンタクトが他のフローチャートからオファーを受信することもあります。

これは、会社のすべてのコミュニケーションで抑制を受ける汎用検証コントロールグループとは違います。 汎用検証コントロールグループを使用する場合、そのグループ内で存続しているコンタクトのメンバを識別し、削除する(たとえば、汎用コントロール戦略的セグメントと突き合わせ、そのオーディエンスIDを除外することにより削除する)必要があります。 コントロールグループの詳細については、『 IBM Unica Campaignユーザガイド』を参照してください。

顧客IDレベルでのサンプリングは、すべてのオファー間で必ずしも同じ表示になりません。 たとえば、全顧客IDの10%が、複数のオファーを持つあるフローチャートで処理されるようランダムに選択される場合、コントロールセル内の誰もがオファーXを受け取る対象にならないことが起こり得ます。この場合、オファーXの分析時、コントロールセルは空になります。

オファーレベルでのサンプリング。

検証コントロールグループに対してランダムにサンプリングを行うもう一つの方法は、セルベースではなく、オファーベースで行われます。 この方法は、最初の方法より複雑な方法になりますが、特定のオファーの特定の割合が測定目的で抑制されることを保証するものです。セルレベルでは、まれにしか提供されないオファーの場合、コントロールセルにほとんど含まれないことがあります。 したがって、この方法は、オファーの提供が偏っている場合に適した方法です。

セルレベルでランダムにサンプリングする場合、統計的に似ているグループからサンプリングを行う必要があります。 たとえば、最初に、高価値、中価値、低価値へのセグメント化を行っている場合、コントロールグループのサンプリング前に、これらのセグメントをもう一度作成する必要があります。 オファーを受け取らなかった高価値顧客と、オファーを受け取った高価値顧客とを比較したり、同様に中価値顧客同士を比較する必要があります。 価値に関係なく、全顧客からランダムにサンプリングを行い、初期セグメントと比較することはよくありません。

したがって、サンプリングの前に、適切なセグメントをもう一度作成することが必要になります。 ただし、純粋なテスト目的で(たとえば、異なるオファーを割り当てるなど)、同じ集団からランダムに選択した複数のセルを作成している場合には、このことは必要ありません。