初歩的な質問で申し訳ありません。
下記の黄色部分の名前は独自の名前に変更できないのでしょうか？
集計などをすると、分かりづらい名称になってしまうことがあるので、変更できればと思うのですが。
どうぞ、よろしくお願いいたします。
こんにちは。
キャプチャの黄色の部分はディメンションの値の中身そのものだと思うのですが
これを任意のものにする方法はいくつかありますが、それぞれメリデメがあります。
（１）別名をつける
（２）グループ化で別名化
（３）計算で別名を作る
（４）joinで別名を作る
（５）ブレンドで別名を作る
※（４）や（５）は今回の要望でそこまでやるほどのものに思えないので割愛します。。。
似たようなものをベースに、表頭のSegmentの英語をカナにしてみます。
★初期状態
（１）別名をつける
↓
↓
結果 ※結果は（２）以降の案でも同じなので以降割愛
～～～
（２）グループ化したものに任意の名前をつける。（1要素からグループに出来るので実質別名がつけれる）
（３）計算で別名を作る（caseとかifとか）
～～～
といった感じです。
冒頭にメリデメと書いた部分について、自分の経験に基づく主観もありますが
ちょっとポイントを書いてみます。
（１）別名をつける
【〇】
操作が簡単なので、その場限りで「さくっと見た目チェンジ」するには良い
大量データになってくるとローデータレベルで行うグループ化や計算よりも理屈上速いはず
【×】
実態ではなく出力結果に対する表示エイリアスな別名なので、計算フィールドで参照出来ない。ローデータでも当該値を確認出来ない。
その定義を他でも使いまわしたくなったときに流用出来ない。
変換する対象が多くなってくると、あのダイアログでポチポチ作業をするメンテナンス性が悪い。
元の値と1:1のエイリアスなので、2つを集約するようなことが出来ない。（ConsumerとCorporateを両方ともC&Cという値にする、とか）
（２）グループ化で別名化
【〇】
操作が（１）同様に簡単。
別名編集よりは自由度の高い設定の振り方が出来る（2:1の集約も出来る）
他ブックへもコピペで流用出来る。（作成元の同じフィールドは当然必要）
設定値の計算フィールド参照も出来る。
【×】
別名よりはマシだけど、それでも変換対象が多いとメンテナンス性は悪い。
大量変換を大量レコードに対して行うと性能ネックの懸念あり。
新たな設定値が出てくると都度追従が必要な場合があり、その点が（３）より劣る。
（３）計算で別名を作る
【〇】
自由度の高い設定の振り方が出来る。
計算定義をテキストで保存しておける。
設定値の計算フィールド参照も出来る。
変換対象が多くてもテキスト記述出来るだけメンテナンス性はマシ
【×】
IF文やCASE文くらいが書けない人には無理。
大量変換を大量レコードに対して行うと性能ネックの懸念あり。
～～～
（０）の対処法として、そもそも入力値を変えてしまうというのもありますね。
利用シーンにあわせて最適な選択をして頂ければと思います。
