熊谷直樹 
基本的に有り物でなんとかする、良く言えば創意工夫、悪く言えば貧乏性のクマガイです。
今回はそんな私でも「これはいいぞ！」と飛びついた、私がMarketoを使い始めた頃はまだ存在しなかった機能「プログラムメンバーカスタムフィールド（舌を噛みそうなので、略してPMCF）」についてお話しさせていただきます。
本題の前に、PMCFじゃない普通のカスタムフィールドって？
Marketoでは「姓」、「名」、「メールアドレス」、「電話番号」など、どんな企業でも使いそうな項目は「標準（デフォルト）フィールド」として導入時点で必ず存在しています。しかし、ほとんどの場合、それ以外のフィールドも必要になってきます。例えば、「地区」、「登録店舗」、「性別」などです。
この「デフォルトでは用意されていないが、インスタンスごとに独自で作成できるフィールド」が「カスタムフィールド」と呼ばれ、Marketoユーザーならほぼ確実に利用していると思います。
そんなカスタムフィールドですが、欠点もあります。データベース構造をある程度理解している方ならすでにお気付きかと思いますが、Marketoのデータベースは表面的にはリレーショナルDBではなく、Excelのようなスプレッドシートのような構造をしています。これはエンジニアではないマーケターが理解しやすいという利点がある反面、使い込むほど気付いてしまう使いにくさもあります。
Marketoカスタムフィールドの「使いにくさ」って？
例えば、Marketoのフォームでアンケートを実施する場合、そのアンケート回答内容の受け皿となるフィールドが必要になります。聞き出したい項目を好きなだけ簡単に追加できる「お猿さん」などとは根本的に違います。（が、Marketo初心者は気付きにくい点です）
「特定のプログラムでのアンケート回収」という用途で作成されてしまったカスタムフィールドは、一度アンケートに答えてしまうと、次に新たなアンケートを取りたいと思ったときには「上書き」しなければなりません。
上書きを防ぐためにアンケート用のフィールドをさらに増やす！ なんてことをやり始めてしまうと、フィールドが乱立し、やがてフィールド作成上限数に達してしまうことになります。
カスタムフィールドの短所を補えるPMCF！
そこで登場するのがPMCFで、以下2つの大きなメリットがあります。
PMCFはプログラム単位でリレーショナル「っぽい」DB構造を持たせることができるようになる機能で、通常のカスタムフィールドの短所を補える素晴らしさがあります！と言っても、使った事がないと何のことやらさっぱり意味がわからないと思いますので、実際にPMCFを使ってみて、その挙動や利点を見てみましょう！
プログラムメンバーカスタムフィールドを作ろう
※カスタムフィールドの作成にはMarketo内での管理権限が必要となります
まずは管理メニューへ移動し、[フィールド管理 > 新規カスタムフィールド]を選択します。
オブジェクト（Object）で「プログラムメンバー（Program Member）」を選択しましょう。
タイプ（Type）では下記の7種類からデータ型を選択します。
- URL（Url）
- ブール値（Boolean）
- 整数（Integer）
- 文字列（String）
- 日付（Date）
- 日時（Datetime）
- 浮動小数点（Float）
PMCF作成にあたり厄介なのが、「1インスタンス内で最大20個までしか作成できない（※2021年10月ブログ執筆時点）」という点です。私自身も実際に上限まで試したことはないのですが、それが事実であれば、むやみやたらに作成できませんので、PMCFの作成には計画性が問われます。
次に重要なのが、名前（Name）とAPI名（API Name）です。
通常のフィールド、例えば「ラストネーム」のフィールドであれば姓を入れておくためのフィールドという考えになりますが、PMCFの場合、データ型は作成時点の固定で、その後どんな値を入れて使うかはプログラムごとに変えられます。つまり、「用途を限定した命名は避けた方が良い」という考えになります。
上記を踏まえ、以下に弊社ルシダスでの作成例をご紹介します。
ポイントは「PMCFであること」「データ型がわかること」「同じデータ型の何個目かわかること」というルールです。
| タイプ（Type） | 名前（Name） | API名（API Name） |
|---|---|---|
| 文字列（String） | PMCF_STR_01 | pmcfStr01 |
| 文字列（String） | PMCF_STR_02 | pmcfStr02 |
| 文字列（String） | PMCF_STR_03 | pmcfStr03 |
| 文字列（String） | PMCF_STR_04 | pmcfStr04 |
| 文字列（String） | PMCF_STR_05 | pmcfStr05 |
| 文字列（String） | PMCF_STR_06 | pmcfStr06 |
| 文字列（String） | PMCF_STR_07 | pmcfStr07 |
| 日付（Date） | PMCF_DATE_01 | pmcfDate01 |
| 日時（Datetime） | PMCF_DTIME_01 | pmcfDtime01 |
もし、さらに日付型を追加する場合は「PMCF_DATE_02」、整数型を新たに追加する場合は「PMCF_INT_01」という風になります。
これで様々なプログラムで様々な用途で使用されても差し支えなく、数が増えても統一感を保てる命名になりました。
プログラムメンバーカスタムフィールドの値を確認する方法
通常のフィールドはリードデータの詳細から確認することができますが、PMCFはリードデータの詳細からは確認できません（強いて言うと、アクティビティログ上で変更履歴は確認できます）。
プログラムの「メンバー」タブから、さらに「ビューの作成（Create View）」で「表示する列（Visible Columns）」に追加しなければなりません。私はPMCFを全て表示させるPMCF用のビューを作成し使用しています。
意外と「ビューの作成（Create View）を知らないまま使い続けていました」というMarketoユーザーもいるようですが、PMCFに関係のないところでも自分好みのビューを作成して活用すると便利です。
プログラムメンバーカスタムフィールドを使う
PMCFに値を入れる方法として代表的なものは「ローカルフォーム」です。PMCFはプログラムありきのフィールドですので、デザインスタジオに置いてある「グローバルフォーム」で使用することはできません。
ローカル（＝プログラム内に置いてある）フォームであればPMCFを入力項目として追加することが可能です。なお、PMCFはプログラムの種類は問わず、全てのプログラムで使うことができます。
Marketoフォームの特徴のひとつに、設問に使用するフィールドの元々のデータ型に関係無く、フォーム上での回答の回収方法を自由に選べることがあります。
これは前述していたPMCF作成の個人的ベストプラクティス「文字列型を7個くらい、日付型を1~2個、ついでに日時型が1個くらいあると充分かな？」という部分に関わってきます。
「文字列型」のフィールドは大体なんでも入れることができます。
ちょっと極端な例ですが、文字列型のPMCFに対して「スライダ」形式で回答を回収することができます。
「フィールドのタイプ：単数選択チェックボックス」は「ブール値型」のような回収方法です。
文字列型のPMCFであれば、単数選択チェックボックスの回答内容も「yes」もしくは「no」という文字で回収することが可能ですが、その逆、ブール値型のPMCFへ文字情報を入れることはできません。
ですので、ブール値型の代替として使うこともできる文字列型を優先して作成した方が、用途の幅が広くて実用的だと思います。
文字列型に入れた日付はあくまで「ただの文字」なので、スマートリストのフィルター条件などで使用する際に、日付（日時）型フィールドのような「過去」「未来」「期間内」といった演算子が使えません。
こちらもあくまで一例ですが、システムトークン{{system.dateTime}}などを活用すれば、「フォーム入力日時」を回収し、プログラムごとに保持しておくことも可能です。
たくさんあるMarketoフォームの中から、「最終」のフォーム入力日時であれば、１か所で上書き更新されていく通常のカスタムフィールドでもよいと思いますが、各施策（プログラム）ごとにそれぞれでフォーム入力日時を保持しておきたい場合はPMCFがまさにピッタリです。
PMCFのデメリットを挙げるとすれば、汎用性を重視して命名したフィールド名とフォーム上での設問内容の関係がわかりにくいという点です。これはやむを得ないということでグッと飲み込みましょう。
プログラムメンバーカスタムフィールドとスマートキャンペーン
PMCF機能追加以後、PMCFに関連するトリガーやフィルター、フローの種類が増えました。
トリガー「プログラムメンバデータを変更（Program Member Data is Changed）」
フィルター「プログラムメンバデータを変更済み（Program Member Data was Changed）」
フロー「プログラムメンバーの変更（Change Program Member Data）」
その他、もともとあったフィルター「プログラムのメンバー（Member of Program）」や「エンゲージメントプログラムのメンバー（Member of Engagement Program）」などの「制約の追加（Add Constraint）」にてPMCFを指定できるようになりました。
ここで注目したいのは、フロー「プログラムメンバーの変更（Change Program Member Data）」です。
先ほどPMCFに値を入れる代表的な方法は「ローカルフォーム」としていましたが、実はこのフローを使うことによってフォーム入力に関係無く、指定のプログラムのPMCFへ値を入れることができます。
これならグローバルフォーム自体にPMCFを使えなくても、そのグローバルフォームをトリガーとしたトリガーSCで使えますし、バッチSCにてPMCFに値を入れることも可能です。ローカルフォームに限定されず、PMCFを使うことができるので、できることの幅がかなり広がると思います。
最後に、ちょっとだけ不満（笑）
PMCF自体は非常に画期的で個人的には大満足な機能なのですが、ちょっとだけ不満があるので、今後のアップデートへの期待も込めて言及しておきます（笑）
演算子で「指定の語を含む/含まない」が使えない
文字列型のPMCFで使用できる演算子は、通常の文字列型フィールドと異なり「指定の語を含む/含まない（contain / not contain）」を使うことができず、部分一致の条件指定ができません。
例えば、フォーム上で複数選択チェックボックスでの回答を受け付けている場合、１つのフィールドに複数の値を回収し、「指定の語を含む」で部分一致させて様々な分岐……、ということがPMCFではできません。
フローの「選択肢（Add Choice）」で使えない
PMCFに入った値をもとにフローの選択肢で分岐させたいのに、それができません。強いて言うと「プログラムメンバーを変更済み」がありますが、プログラム名しか指定できないため、「どのPMCFで、どの値の場合」といった細かい条件指定での使い方はできません。
代替策として、PMCFと値まで指定したスマートリストアセットを別で作成しておき、「スマートリストのメンバー：リストに存在する/しない」を選択肢の条件とすることは可能です。
「制約の追加（Add constraint）」の中が圧迫される
フィルター「プログラムのメンバー」と「エンゲージメントプログラムのメンバー」の制約の追加（Add constraint）で使用できるようになりましたが、PMCFがすべてズラーっと表示されてしまうため、上限20個まで作成した時にはとんでもないことになってしまうのでは？ と思います。
プログラムメンバーカスタムフィールドでMarketoは劇的に変わる！
他にも、PMCFはメンバートークンとして使用することができます。例えば、日付型のPMCFメンバートークンを待機フローで使うなど、Marketoでできることの幅がさらにさらに広がります。
今まで諦めていたことも、「あ、それPMCFを使えばできますよ！」というご提案ができるかもしれません。PMCF未導入、作成してみたけどいまいち効果的に使えていないという方は、ぜひルシダスまでご相談ください！
執筆者プロフィール
-
高校から始めた男子新体操をきっかけに、ブレイクダンスなど身体を使ったパフォーマンスにどっぷりとハマる。
そのままフィットネス業界に入り10年弱、インストラクターや店舗の運営・管理、新店舗…［続きを読む］
最新の投稿
Marketo2023年3月17日Marketoリストインポート その前に！
Marketo2022年8月26日Marketo トラッキングリンクをもっと知る
Marketo2022年3月11日Marketo 作成日と取得日の違い
Marketo2021年10月15日プログラムメンバーカスタムフィールドは使うべき！
メルマガ登録
マーケターやマーケティングにご興味のある方へ。些細なことから「おっ」と思う注目の事柄まで、読んでお得な情報をメールで配信中！気になる方は今すぐご登録を！
